《图解HTTP》（七）-确保 Web 安全的 HTTPS

在 HTTP 协议中有可能存在信息窃听或身份伪装等安全问题。使用HTTPS 通信机制可以有效地防止这些问题。

7.1 HTTP 的缺点

      HTTP 主要有这些不足，例举如下。
      通信使用明文（不加密），内容可能会被窃听
      不验证通信方的身份，因此有可能遭遇伪装
      无法证明报文的完整性，所以有可能已遭篡改

    7.1.1 通信使用明文可能会被窃听

     通信的加密
     一种方式就是将通信加密。HTTP 协议中没有加密机制，但可以通过和 SSL（Secure Socket Layer，安全套接层）或TLS（Transport Layer Security，安全层传输协议）的组合使用，加密 HTTP 的通信内容。

     用 SSL建立安全通信线路之后，就可以在这条线路上进行 HTTP通信了。与 SSL组合使用的 HTTP 被称为 HTTPS（HTTP
Secure，超文本传输安全协议）或 HTTP over SSL。

     内容的加密
     还有一种将参与通信的内容本身加密的方式。由于 HTTP 协议中没有加密机制，那么就对 HTTP 协议传输的内容本身加密。即把
     HTTP 报文里所含的内容进行加密处理。
     在这种情况下，客户端需要对 HTTP 报文进行加密处理后再发送请求。
     诚然，为了做到有效的内容加密，前提是要求客户端和服务器同时具备加密和解密机制。主要应用在 Web 服务中。有一点必须
引起注意，由于该方式不同于 SSL或 TLS 将整个通信线路加密处理，所以内容仍有被篡改的风险。稍后我们会加以说明。

   7.1.2 不验证通信方的身份就可能遭遇伪装

     HTTP 协议中的请求和响应不会对通信方进行确认。也就是说存在“服务器是否就是发送请求中 URI 真正指定的主机，返回的响应是否真的返回到实际提出请求的客户端”等类似问题。

   7.1.3 无法证明报文完整性，可能已遭篡改

     所谓完整性是指信息的准确度。若无法证明其完整性，通常也就意味着无法判断信息是否准确。

     由于 HTTP 协议无法证明通信的报文完整性，因此，在请求或响应送出之后直到对方接收之前的这段时间内，即使请求或响应的内容遭到篡改，也没有办法获悉。
换句话说，没有任何办法确认，发出的请求 / 响应和接收到的请求 / 响应是前后相同的。

 

7.2 HTTP+ 加密 + 认证 + 完整性保护=HTTPS

     7.2.1 HTTP 加上加密处理和认证以及完整性保护后即是HTTPS

      经常会在 Web 的登录页面和购物结算界面等使用 HTTPS 通信。使用HTTPS 通信时，不再用 http://，而是改用 https://。另外，当浏览器访问 HTTPS 通信有效的 Web 网站时，浏览器的地址栏内会出现一个带锁的标记。

    7.2.2 HTTPS 是身披 SSL 外壳的 HTTP

       HTTPS 并非是应用层的一种新协议。只是 HTTP 通信接口部分用SSL（Secure Socket Layer）和 TLS（Transport Layer Security）协议代替而已。
       通常，HTTP 直接和 TCP 通信。当使用 SSL时，则演变成先和 SSL通信，再由 SSL和 TCP 通信了。简言之，所谓 HTTPS，其实就是身披SSL协议这层外壳的 HTTP。

       在采用 SSL后，HTTP 就拥有了 HTTPS 的加密、证书和完整性保护这些功能。

      SSL是独立于 HTTP 的协议，所以不光是 HTTP 协议，其他运行在应用层的 SMTP 和 Telnet 等协议均可配合 SSL协议使用。可以说 SSL是当今世界上应用最为广泛的网络安全技术。

    7.2.3 相互交换密钥的公开密钥加密技术

      SSL采用一种叫做公开密钥加密（Public-key cryptography）的加密处理方式。

     共享密钥加密的困境

     加密和解密同用一个密钥的方式称为共享密钥加密（Common keycrypto system），也被叫做对称密钥加密。

     HTTPS 采用混合加密机制

     HTTPS 采用共享密钥加密和公开密钥加密两者并用的混合加密机制。若密钥能够实现安全交换，那么有可能会考虑仅使用公开密钥加密来通信。

    7.2.4 证明公开密钥正确性的证书

     数字证书认证机构处于客户端与服务器双方都可信赖的第三方机构的立场上。

   7.2.5 HTTPS 的安全通信机制

    HTTPS 的通信步骤：

    步骤 1：

    客户端通过发送 Client Hello 报文开始 SSL通信。报文中包含客户端支持的 SSL的指定版本、加密组件（Cipher Suite）列表（所使用的加密算法及密钥长度等）。
    步骤 2：

    服务器可进行 SSL通信时，会以 Server Hello 报文作为应答。和客户端一样，在报文中包含 SSL版本以及加密组件。服务器的加密组件内容是从接收到的客户端加密组件内筛选出来的。

    步骤 3：

    之后服务器发送 Certificate 报文。报文中包含公开密钥证书。
    步骤 4：

    最后服务器发送 Server Hello Done 报文通知客户端，最初阶段的 SSL握手协商部分结束。

    步骤 5：

    SSL第一次握手结束之后，客户端以 Client Key Exchange 报文作为回应。报文中包含通信加密中使用的一种被称为 Pre-mastersecret 的随机密码串。该报文已用步骤 3 中的公开密钥进行加密。

    步骤 6：

    接着客户端继续发送 Change Cipher Spec 报文。该报文会提示服务器，在此报文之后的通信会采用 Pre-master secret 密钥加密。

    步骤 7：

    客户端发送 Finished 报文。该报文包含连接至今全部报文的整体校验值。这次握手协商是否能够成功，要以服务器是否能够正确解密该报文作为判定标准。

    步骤 8：

     服务器同样发送 Change Cipher Spec 报文。
     步骤 9：

     服务器同样发送 Finished 报文。

     步骤 10：

     服务器和客户端的 Finished 报文交换完毕之后，SSL连接就算建立完成。当然，通信会受到 SSL的保护。从此处开始进行应用层协议的通信，即发送 HTTP 请求。

     步骤 11：

     应用层协议通信，即发送 HTTP 响应。

    步骤 12：

     最后由客户端断开连接。断开连接时，发送 close_notify 报文。上图做了一些省略，这步之后再发送 TCP FIN 报文来关闭与 TCP的通信。