RFC2818--HTTPS/TLS 翻译

rfc2818原文原文连接

翻译

RFC818文档中对HTTPS的描述如下：

连接初始化--

运行HTTP的客户端也是运行TLS的客户端。这个客户端需要在合适的端口向服务器发送一个连接请求，然后发送TLS clienthello 来开始一个TLS握手。当TLS握手结束后，客户端会发起首个HTTP请求。所有的HTTP数据必须以TLS “applicationdata”的形式发送。正常的HTTP行为，包含保持连接的行为，也要这么做。（以TLS “application data“的形式发送）。

 

文档中还描述了HTTPS连接关闭时客户端和服务器端的行为、端口号、URI的格式，端系统认证（包含服务器的认证、客户端的认证）

 

连接的关闭—

TLS 提供了安全连接关闭的机制。当一个有效的关闭提醒被收到之后，可以如下来实现—这条连接上将不会有进一步的信息被接收。TLS的实现要求，在关闭连接之前连接双方必须要交换关闭提醒（closure alerts）。在TLS的实现中，一方可以在发送了关闭提醒之后直接关闭连接而不等待对方的关闭提醒发送，从而产生一个“不完全关闭“。应当注意，这样实现可以重用session（连接）。这样实现要求用户程序知道自己所需的信息已经全被收到（典型的如，通过检查HTTP消息的边界）。

在rfc2246中特别指出，任何在关闭连接之前没有收到有效关闭提醒（valid closure alert）的实现方式，禁止重用连接。提前关闭不会对已经传输的数据产生安全问题，但是意味着随后的数据也许会被截断。因为TLS是不检查HTTP请求/应答报文的边界的。所以检查HTTP数据是在在一个报文段之内被截断还是在报文段之间被截断是很重要的（通常是通过content-length头部来检查）。

       客户端行为—

       因为HTTP使用连接关闭来标志服务器端数据的传输结束，所以客户端必须将任何连接提前关闭看成是错误并且认为已收到的数据是被截断的、不完整的。然而在有些情况下，HTTP洗液允许客户端检查是否发生了截断，容忍传输完成情况下的连接提前关闭的错误。

       两种情况要特别注意：

       HTTP响应报文没有Content-Length 头部。在这种情况下(容忍提前关闭连接的错误)，数据长度有连接中断来决定，此时如果攻击者发来消息，客户端并不知道。

       包含有效长度的HTTP响应响应报文在所有数据被读进之前送到且关闭连接。无法区分是服务器计算错误还是连接被劫持中断。

对于上面的rule有个例外。当遇到了提前终止连接，客户端应当将其看成所有请求已经发送，且接收了尽可能多的数据。

       客户端检查一个不完整的关闭，并应该优雅地（gracefully）恢复。它要重新开始被意外中断的对话。

       客户端必须在关闭连接之前发送一个关闭提醒。不准备接收更多的数据的客户端可以选择不等待服务端发送关闭提醒，而是可以直接关闭连接。从而产生一个不完整的关闭（客户端关闭了连接，而服务端依旧单方面维护着连接）。

       服务器端行为—

       RFC2616允许HTTP客户端在任何时候关闭连接，要求服务器端优雅地（gracefully）恢复连接。特别地，服务器端应该准备遇到客户端意外的终端（客户端不等待服务端发关闭提醒就关闭连接）。客户端可以决定服务器什么时候终止数据传输。服务器端应当时刻准备恢复被客户端意外关闭的的对话（连接）。

       实现的note：在HTTP实现中并不使用持续连接，服务端应当能够通过关闭连接来提示数据的终止。当发送content-length，客户端也许已经发送了关闭提醒且关闭了连接。

       服务器必须要在关闭连接之前提起和客户端交换关闭提醒。服务端也可以（MAY）在发完关闭提醒之后关闭连接，从而在客户端留下了单方面的连接。

 

端口号—

HTTP服务器期望收到来自客户端的首个数据是Request-Line production。然而，TLS 服务器（HTTPS 服务器）期望收到来自客户端的首个数据是ClientHello。从概念上说，常见的做法是将HTTPS/TLS运行在不同的端口上，以便于区分不同的协议。当HTTPS/TLS 被运行在TCP/IP连接上，默认端口好是443. 当然，HTTPS/TLS也可以运行在其他的端口号上。TLS只是假设在此端口上有一个可靠的面向连接的数据流。

URI Format—

HTTPS/TLS 和HTTPSURIs不同之处在于将HTTP的URI中的http改成了https

端系统的认证—

       服务器的认证—

       HTTPS/TLS请求通过解引用URI来产生。因此，客户端是知道服务器的hostname的。如果客户端知道服务器的hostname，客户端必须在服务器的证书信息里面检查当前获得的服务器的身份，来防止中间人攻击。

       如果客户端有想要访问的服务器有额外的信息，检查hostname的工作可以忽略（例如，访问的服务器的地址和hostname是动态变化的，但是客户端知道服务器早晚会提供证书的）。在这种情况下，缩小可接受证书的范围是很重要的，以此防止中间人攻击。特殊情况下，客户端可以忽略服务器身份，但是这样做会让连接面临被攻击的风险。

       如果hostname和证书中的身份信息不匹配，客户端需要通知客户是否继续或者关闭连接返回一个badcertificates error。默认处理的客户端需要将错误记录在audit 日志上并应该关掉连接返回错误。

       注意到，很多情况下URI本身来自不可信的来源，以上的检查无法提供避免攻击的保护。如网页中的连接会被替换为不使用HTTPS/TLS，点击时会受到中间人的攻击。

       客户端认证—

       典型情况，服务器对客户端的身份信息没有额外的要求，所以检验身份是不必要的。