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

前言

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

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