确保 Web 安全的 HTTPS

1 HTTP 的缺点

• 缺点： - 通信使用明文（不加密），内容可能会被窃听- 不验证通信方的身份，因此有可能遭遇伪装 - 无法确定请求发送至目标的 Web 服务器是否是按真实意图返回响应的那台服务器。有可能是已伪装的 Web 服务器。- 无法确定响应返回到的客户端是否是按真实意图接收响应的那个客户端。有可能是已伪装的客户端。- 无法确定正在通信的对方是否具备访问权限。因为某些 Web 服务器上保存着重要的信息，只想发给特定用户通信的权限。- 无法判定请求是来自何方、出自谁手。- 即使是无意义的请求也会照单全收。无法阻止海量请求下的 DoS 攻击（Denial of Service，拒绝服务攻击）。- 无法证明报文的完整性，所以有可能已遭篡改 - 虽然有使用 HTTP 协议确定报文完整性的方法，但事实上并不便 捷、可靠。其中常用的是 MD5 和 SHA-1 等散列值校验的方法， 以及用来确认文件的数字签名方法。（需要用户本人亲自检查）

web浏览器，客户端和应用可能自身会有脆弱性或安全漏洞

2 HTTPS

• 定义：HTTPS 是身披 SSL 外壳的 HTTP。HTTPS 并非是应用层的一种新协议。只是 HTTP 通信接口部分用 SSL（Secure Socket Layer）和 TLS（Transport Layer Security）协议代替而已。

3 密钥加密技术

3.1 共享密钥加密

• 定义：加密和解密同用一个密钥的方式称为共享密钥加密(Common key crypto system)，也被叫做对称密钥加密。
• 问题：以共享密钥方式加密时必须将密钥也发给对方。在互联网上转发密钥时，如果通信被监听那么密钥就可会落入攻击者之手，同时也就失去了加密的意义。

3.2 公开密钥加密

• 定义：公开密钥加密使用一对非对称的密钥。一把叫做私有密钥 (private key)用于解密，另一把叫做公开密钥(public key)用于加密。
• 解决问题：使用公开密钥加密方式，发送密文的一方使用对方的公开密钥进行加密处理，对方收到被加密的信息后，再使用自己的私有密钥进行解密。利用这种方式，不需要发送用来解密的私有密钥，也不必担心密钥被攻击者窃听而盗走。
• 存依然在的问题：无法证明公开密钥本身就是货真价实的公开密钥。或许在公开密钥传输途中，真正的公开密钥已经被攻击者替换掉了。
• 证书：为了解决上述问题，可以使用由数字证书认证机构(CA，Certificate Authority)和其相关机关颁发的公开密钥证书。
• 证书机构的业务流程：- 字证书认证机构处于客户端与服务器双方都可信赖的第三方机构的立场上。- 首先，服务器的运营人员向数字证书认证机构提出公开密钥的申请。- 数字证书认证机构在判明提出申请者的身份之后，会对已申请的公开密钥做数字签名，然后将这个已签名的公开密钥放入公钥证书后绑定在一起。
• 证书证明的机制：接到证书的客户端可使用数字证书认证机构的公开密钥，对那张证书上的数字签名进行验证，一旦验证通过，客户端便可明确两件事:一，认证服务器的公开密钥的是真实有效的数字证书认证机构。二，服务器的公开密钥是值得信赖的。> 此处认证机关的公开密钥必须安全地转交给客户端。使用通信方式时，如何安全转交是一件很困难的事，因此，多数浏览器开发商发布版本时，会事先在内部植入常用认证机关的公开密钥。

3.3 HTTPS的密钥加密

• 定义：HTTPS 采用混合加密机制，公开密钥加密与共享密钥加密相比，其处 理速度要慢。所以应充分利用两者各自的优势，将多种方法组合起来用于通信。在交换密钥环节使用公开密钥加密方式，之后的建立通信交换报文阶段则使用共享密钥加密方式。

4 HTTPS 的安全通信机制

• 流程： - 步骤 1: 客户端通过发送 Client Hello 报文开始 SSL 通信。报文中包 含客户端支持的 SSL 的指定版本、加密组件(Cipher Suite)列表(所 使用的加密算法及密钥长度等)。- 步骤 2: 服务器可进行 SSL 通信时，会以 Server Hello 报文作为应 154答。和客户端一样，在报文中包含 SSL 版本以及加密件。服务器的 加密组件内容是从接收到的客户端加密组件内筛选出来的。- 步骤 3: 之后服务器发送 Certificate 报文。报文中包含公开密钥证 书。- 步骤 4: 最后服务器发送 Server Hello Done 报文通知客户端，最初阶段的 SSL 握手协商部分结束。- 步骤 5: SSL 第一次握手结束之后，客户端以 Client Key Exchange 报 文作为回应。报文中包含通信加密中使用的一种被称为 Pre-master secret 的随机密码串。该报文已用步骤 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 的通信。

• Pre-master key：pre-master key的主要目的是作为生成最终master key的基础。master key的生成涉及到一个密钥派生函数（KDF），该函数使用pre-master key和双方共享的随机数来生成master key。
• Master key：master key用于生成实际加密通信数据的一系列对称密钥，这些对称密钥包括加密密钥、MAC（消息认证码）密钥和IV（初始化向量）。master key在SSL/TLS会话期间一直保持不变，并且在会话结束后被丢弃。
• MAC（消息认证码）密钥：用于验证数据完整性和防止篡改的密钥。在每条消息被发送之前，发送方会使用这个密钥和消息内容生成一个MAC，并将其附加到消息上。接收方收到消息后，会使用相同的密钥重新计算并验证MAC，以确保消息在传输过程中未被篡改。
• HTTPS的劣势：SSL 的慢分两种。一种是指通信慢。另一种是指由于大量消耗CPU 及内存等资源，导致处理速度变慢。 - 和使用 HTTP 相比，网络负载可能会变慢 2 到 100 倍。除去和 TCP 连接、发送 HTTP 请求 • 响应以外，还必须进行 SSL 通信，因此整体上处理通信量不可避免会增加。- 另一点是 SSL 必须进行加密处理。在服务器和客户端都需要进行 加密和解密的运算处理。因此从结果上讲，比起 HTTP 会更多地消耗服务器和客户端的硬件资源，导致负载增强。