0.3、计算机网络-HTTP Over TLS(HTTPS)

水深无声 2022-01-23 14:49 288阅读 0赞

### 文章目录 ###

*   *   *   *  前言
             *  rfc2818
             *  https:
             *  HTTP Over TLS 的细节
             *   *  客户端的行为:
                 *  服务端的行为
                 *  端口号
                 *  URI 格式
                 *  Endpoint Identification 端点定义
                 *   *  Server Identity 服务端身份
                     *  Client Identity 客户端身份
             *  TLS 的握手协议和 TCP/IP的三次握手的关系
             *  https 的风险
             *   *  中间人攻击
                 *  OpenSSL 心脏出血 漏洞
             *  参考链接

#### 前言 ####

> 体能状态先于精神状态,习惯先于决心,聚焦先于喜好.

#### rfc2818 ####

> 官方文档地址 https://www.rfc-editor.org/rfc/pdfrfc/rfc2818.txt.pdf

#### https: ####

> 当前的实践是,通过TLS层传输HTTP层.  
> 使用不同的端口提供安全服务,https协议使用 443 端口.  
> 在历史的实践中,SSL协议规定使用特殊的命名空间可以区分HTTP或者HTTPS,比如  
> HTTP使用80端口,https使用443端口,类似的,snews和ftps采取了类似的策略.  
> 传统来说,服务端返回 2XX 返回码表示连接已经被建立.  
> 3xx表示重定向

#### HTTP Over TLS 的细节 ####

##### 客户端的行为: #####

> Connection Initiation  
> ·作为HTTP的客户端也必须作为 TLS的客户端,当客户端完成TLS的握手之后,  
> 将使用TLS的 “application data” 进行第一个 HTTP 请求

> Connection Closure  
> ·关闭一个 HTTP 连接前,TLS必须发起一个closure alerts

> 客户端必须把提前到来的关闭信息认定为错误信息,因为该信息可能来自虚假身份的攻击者.  
> 客户端发现一个未完毕的结束时,需要优雅的恢复正常.  
> 客户端应该发送一个 closure alert 在关闭连接之前,当然,客户端有可能在未收到服务端的关闭消息前简单的关闭连接.

##### 服务端的行为 #####

> RFC 2616 允许客户端在任意时间关闭连接,这要求服务端可以优雅的恢复服务.特别的,服务端需要准备接受来自客户端的不完整的关闭消息,因为经常是客户端决定服务数据什么时候结束.这种场景下,服务端更倾向于从新开始一个TLS session.

##### 端口号 #####

> HTTP 服务端期望收到客户端的第一个请求是 Request-Line production.  
> TLS 服务端期望收到的第一条消息是 ClientHello.  
> 所以,一般的时间使用了分开的端口以便于区分 HTTP/TLS 协议.  
> 当 HTTP/TLS 协议被用于一个 TCP/IP 连接的时候,默认的端口号是 443.  
> HTTP/TLS 并未阻止使用另一个端口号.TLS 只是假设一个可依赖的原生连接的数据流.

##### URI 格式 #####

> HTTP/TLS 不同于 HTTP URIs,前者使用 ‘https’,后者使用‘http’

##### Endpoint Identification 端点定义 #####

> hostname:域名

###### Server Identity 服务端身份 ######

> 总体来说,HTTP/TLS 请求被通过一个 URI 生成.结果,服务端的 hostname 被客户端知道.如果hostname可被访问,服务端必须检查他是否满足服务端证书信息中的定义,这样做是为了防止中间人攻击.

> 当然,如果客户端有其他方式去认证服务端的身份,hostname 检查这步可以被省略.这种情况下,为了防止中间人攻击,应该尽可能的限制证书的可用范围.特殊情况下,或许让客户端简单的忽略服务端的身份认证是合适的,但是必须注意到这样做会将连接对主动攻击.

> 如果 DNS 名称的扩展主题名称被使用,同样需要被验证.否则,应该使用证书中主题中最常用的名字.尽管使用普通的名字存在管理,这种方式依旧被强烈反对,应该使用DNSNAME去进行证书认证,这是被鼓励的.

> 存在对应的匹配规则,如果证书提供了不知一个类型(不只一个 dNSNAME,符合条件的都应该是可以被接受的).名字中可能存在通配符 \*.比如 *.a.com 包含 foo.a.com 但是不包含 bar.foo.a.com .再比如f*.com 包含 foo.com 但是不包含bar.com.

> 某些情况下,URI使用的是 IP地址,而不是 hostname(域名),这种情况下,ip地址 subjectAltName 必须被包含在证书中,并且精确的匹配URI中的IP.

> 如果 hostname 不匹配证书中的定义,面向用户的客户端必须警告用户(用户可以选择继续浏览或者放弃)或者使用一个证书错误暂停连接.自动化的客户端必须对错误进行日志记录,以便于后期检查,并且,还需要暂停连接(以证书错误作为原因).  
> 自动化的客户端可能会提供一个配置用以免去证书检查,但是必须提供一个允许这种配置的场景.

> 需要注意的是,很多时候URI本身就来自于不被信任的来源.上面的描述并不能对来源不符合标准的URI提供免受攻击的保护.  
> 比如,URI是被通过点击 HTML 页面获得的,而这个HTML页面并没有使用HTTP/TLS,这个时候就可能被中间人更换URI.  
> 为了避免这种攻击,用户需要细心检查服务端提供的证书,以确定该证书满足他们的预期.

###### Client Identity 客户端身份 ######

> 一般来说,服务端并不知道客户端的身份应该被检测,所以服务端对客户端的检测是不可能的.如果服务端通过某种渠道知道客户端需要被检测(比如通过 HTTP或者TLS),其过程和客户单检查服务端一致.

#### TLS 的握手协议和 TCP/IP的三次握手的关系 ####

> 敲黑板,从网络分层来说,它俩就不是一个层的,TCP/IP 协议簇位于TLS协议下游,这意味着,TLS 握手协议会引起 TCP/IP 的三次握手来建立连接

#### https 的风险 ####

##### 中间人攻击 #####

> 证书是危险当证书,中间人在中间模拟客户端和服务端当交互,所有的信息都泄漏了,使用安全的证书.

##### OpenSSL 心脏出血 漏洞 #####

> OpenSSL 相当于SSL的一个实现，如果把SSL规范看成OO中的接口，那么OpenSSL则认为是接口的实现。接口规范本身是安全没问题的，但是具体实现可能会有不完善的地方，比如之前的"心脏出血"漏洞，就是OpenSSL中的一个bug.  
> OpenSSL Heartbleed模块存在一个BUG，当攻击者构造一个特殊的数据包，满足用户心跳包中无法提供足够多的数据会导致memcpy把SSLv3记录之后的数据直接输出，该漏洞导致攻击者可以远程读取存在漏洞版本的openssl服务器内存中长大64K的数据。  
> OpenSSL已经对这一漏洞进行了修补，OpenSSL默认禁用了SSLv2协议，并移除了SSLv2协议的EXPORT系列加密算法。OpenSSL强烈建议，用户停止使用SSLv2协议。

*  OpenSSL心脏出血漏洞受影响版本  
    OpenSSL 1.0.2-beta  
    OpenSSL 1.0.1 - OpenSSL 1.0.1f
 *  不受影响版本：  
    OpenSSL 1.0.1g is NOT vulnerable  
    OpenSSL 1.0.0 branch is NOT vulnerable  
    OpenSSL 0.9.8 branch is NOT vulnerable

#### 参考链接 ####

> \[1\]、https://www.rfc-editor.org/rfc/pdfrfc/rfc2818.txt.pdf