TLS之上的HTTP

1.介绍

HTTP[RFC2616]最初是在INTERNET上不用密码的应用。但随着HTTP的敏感性应用日益增长，对安全性的要求也随之增长。SSL及其后继TLS[RFC2246]提供了面向通道的安全性。本文介绍怎样在TLS之上应用HTTP。

相关术语

在本文中的关键字“必须”，“必须不”，“要求”，“应该”，“不该该”和“可能”的解释见[RFC2119]。

2. TLS之上的HTTP

从概念上讲，HTTP/TLS很是简单。简单地在TLS上应用HTTP，如同在TCP上应用HTTP同样。

2.1 初始化链接

做为HTTP客户的代理同时也应做为TLS的客户。它应该向服务器的适当端口发起一个链接，而后发送TLS ClientHello来开始TLS握手。当TLS握手完成，客户能够初始化第一个HTTP请求。全部的HTTP数据必须做为TLS的“应用数据”发送。正常的HTTP行为，包括保持链接，应当被遵照。

2.2 关闭链接

TLS提供了安全关闭链接的机制。当收到一个有效的关闭警告时，实现上必须保证在这个链接上再也不接收任何数据。TLS的实如今关闭链接以前必须发起交换关闭请求。TLS实现可能在发送关闭请求后，不等待对方发送关闭请求即关闭该链接，产生一个“不彻底的关闭”。注意：这样的实现可能选择重用该对话。这只应在应用了解（典型的是经过检测HTTP的消息边界）它已收到全部它关心的数据的状况下进行。

如[RFC2246]中所定义的，任何未接收一个有效的关闭警告（一个“未成熟关闭”）即接到一个链接关闭必须不重用该对话。注意：一个未成熟请求并不质疑数据已被安全地接收，而仅意味着接下来数据可能被截掉。因为TLS并不知道HTTP的请求/响应边界，为了解数据截断是发生在消息内仍是在消息之间，有必要检查HTTP数据自己（即Content-Length头）。

2.2.1 客户行为

因为HTTP使用链接关闭表示服务器数据的终止，客户端实现上对任何未成熟的关闭要做为错误对待，对收到的数据认为有可能被截断。在某些状况下HTTP协议容许客户知道截断是否发生，这样若是客户收到了完整的应答，则在遵循“严出松入[RFC1958]”的原则下可容忍这类错误，常常数据截断不体如今HTTP协议数据中；有两种状况特别值得注意：

一个无Content-Length头的HTTP响应。在这种状况下数据长度由链接关闭请求通知，咱们没法区分由服务器产生的未成熟关闭请求及由网络攻击者伪造的关闭请求。

一个带有有效Content-Length头的HTTP响应在全部数据被读取完以前关闭。因为TLS并不提供面向文档的保护，因此没法知道是服务器对Content-Length计算错误仍是攻击者已截断链接。

以上规则有一个例外。当客户遇到一个未成熟关闭时，客户把全部已接收到的数据同Content-Length头指定的同样多的请求视为已完成。

客户检测到一个未完成关闭时应予以有序恢复，它可能恢复一个以这种方式关闭的TLS对话。

客户在关闭链接前必须发送关闭警告。未准备接收任何数据的客户可能选择不等待服务器的关闭警告而直接关闭链接，这样在服务器端产生一个不彻底的关闭。

2.2.2 服务器行为

RFC2616容许HTTP客户在任什么时候候关闭链接，并要求服务器有序地恢复它。特别是，服务器应准备接收来自客户的不彻底关闭，由于客户每每可以判断服务器数据的结束。服务器应乐于恢复以这种方式关闭的TLS对话。

实现上注意：在不使用永久链接的HTTP实现中，服务器通常指望能经过关闭链接通知数据的结束。可是，当Content-Length被使用时，客户可能早已发送了关闭警告并断开了链接。

服务器必须在关闭链接前试图发起同客户交换关闭警告。服务器可能在发送关闭警告后关闭链接，从而造成了客户端的不彻底关闭。

2.3端口号

HTTP服务器指望最早从客户收到的数据是Request-Line production。TLS服务器指望最早收到的数据是ClientHello。所以，通常作法是在一个单独的端口上运行HTTP/TLS，以区分是在使用哪一种协议。当在TCP/IP链接上运行HTTP/TLS时，缺省端口是443。这并不排除HTTP/TLS运行在其它传输上。TLS只假设有可靠的、面向链接的数据流。

2.4 URI格式

HTTP/TLS和HTTP的URI不一样，使用协议描述符https而不是http。使用HTTP/TLS的一个URI例子是：

https://www.example.com/~smith/home.html

3 端标识

3.1 服务器身份

一般，解析一个URI产生HTTP/TLS请求。结果客户获得服务器的主机名。若主机名可用，为防止有人在中间攻击，客户必须把它同服务器证书信息中的服务器的身份号比较检查。

若客户有相关服务器标志的外部信息，主机名检查能够忽略。（例如：客户可能链接到一个主机名和IP地址都是动态的服务器上，但客户了解服务器的证书信息。）在这种状况下，为防止有人攻击，尽量缩小可接受证书的范围就很重要。在特殊状况下，客户简单地忽略服务器的身份是能够的，但必须意识到链接对攻击是彻底敞开的。

若dNSName类型的subjectAltName扩展存在，则必须被用做身份标识。不然，在证书的Subject字段中必须使用Common Name字段。虽然使用Common Name是一般的作法，但不受同意，而Certification Authorities被鼓励使用dNSName。

使用[RFC2459]中的匹配规则进行匹配。若在证书中给定类型的身份标识超过一个（也就是，超过一个dNSName和集合中的相匹配），名字能够包括通配符＊表示和单个域名或其中的一段相匹配。例如：＊.a.com和foo.a.com匹配但和bar.foo.a.com不匹配。f＊.com和foo.com匹配但和bar.com不匹配。

在某些状况下，URI定义的不是主机名而是IP地址。在这种状况下，证书中必须有iPAddress subjectAltName字段且必须精确匹配在URI中的IP地址。

若主机名和证书中的标识不相符，面向用户的客户端必须或者通知用户(客户端能够给用户机会来继续链接)或终止链接并报证书错。自动客户端必须将错误记录在适当的审计日志中(如有的话)并应该终止链接(带一证书错)。自动客户端能够提供选项禁止这种检查，但必须提供选项使能它。

注意，在不少状况下URI自己是从不可信任的源获得的。以上描述的检查并未提供对危害源的攻击的保护。例如，若URI是从一个未采用HTTP/TLS的HTML页面获得的，某我的可能已在中间已替换了URI。为防止这种攻击，用户应仔细检查服务器提供的证书是不是指望的。

3.2 客户标识

典型状况下，服务器并不知道客户的标识是什么也就没法检查(除非有合适的CA证书)。若服务器知道的话(一般是在HTTP和TLS以外的源获得的)，它应该象上面描述的那样检查。

文档下载    《RFC2818-TLS之上的HTTP.doc》

原创文章，转载请注明： 转载自成长的企鹅

本文连接地址： TLS之上的HTTP

关于我：成长的企鹅简介