《图解HTTP》（下）

学习笔记。

第7章 确保Web安全的HTTPS

7.1 HTTP的缺点

1. 通信使用明文（不加密），内容可能被窃听
2. 不验证通信方的身份，因此有可能遭遇伪装
3. 无法证明报文的完整性，所以有可能已遭篡改

泄密、伪装、篡改。

---

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

• HTTP本身不具有加密功能，即，HTTP报文默认使用明文来进行发送。
• TCP/IP是可以被窃听的网络，因为包的转发会经过多个设备。
• SSL和TLS可以建立安全通信线路。
• 可以对报文内容进行加密。
  

  ---

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

无论谁发出来的请求都会返回响应，所以会存在隐患：

• Web服务器伪装；
• 客户端伪装；
• 无法判断请求来自何方，出自谁手；
• 无意义的请求也会照单全收，无法阻止海量请求下的DoS攻击。

通过SSL的证书机制可以起到验明身份的作用。

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

中间人攻击

---

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

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

---

7.2.2 HTTPS是身披SSL外壳的HTTP

• 通常HTTP和TCP直接通信，使用SSL之后，变为先和SSL进行通信，再和TCP进行通信了。
• SSL是独立的协议，所以不光是HTTP协议，其它运行在应用层的协议都可以和HTTP配合使用。
  

  ---

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

一、对称加密的困境

密钥分为对称密钥和非对称密钥。对称密钥是指加密与解密共用一套密钥，非对称密钥则是公钥加密私钥解密，私钥加密公钥解密。
用对称密钥加密时，需要把密钥也发给对方，如果密钥被窃听，那么信息就会泄露。

二、使用两把密钥的非对称加密

非对称加密很好的解决了上述问题。
在这种加密方式中，公钥是对外公开的，任何人都可以获得，而私钥要严格保密。发送报文的一方使用接收方的公钥对报文进行加密，接收方收到后再用自己的私钥进行解密。这种方式不需要发送用来解密的私钥，因此不用担心私钥被攻击者截获。

能否根据密文和公钥还原原始报文？

这么做是异常困难的。解密过程是对离散对数进行求值，这并非轻而易举。退一步讲，如果能对一个非常大的整数做到快速因式分解，那么密码破解还是存在希望的。但就目前的技术来看是不现实的。

非对称加密

三、HTTPS采用混合加密机制

HTTPS同时采用了对称加密和非对称加密。

为什么不全部采用更加安全的非对称加密呢?

因为非对称加密处理起来非常复杂，所以全部采用非对称加密的话会导致通信效率很低。所以先采用通过非对称加密的方式传递对称加密用的对称密钥，确保对称密钥不被攻击者截获，之后再采用对称加密的方式进行通信。

混合加密

---

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

目前为止还存在一个问题，如果对方要给我发送信息，首先要知道我的公钥，因此我就要把我的公钥发送给他，这个过程就会存在风险——公钥可能被攻击者截获。如果是单纯的截获没有什么大不了，公钥本来就是公开的，你随便看，正如上文所言，单靠公钥和密文还原原始报文异常困难，攻击者拿着公钥也没有用。但问题是，蔫儿的坏攻击者可以替换掉公钥，让发送方用错误的公钥加密，那么接收方就无法用自己的私钥解密，就是要捣蛋不让你好好通信。或者说，攻击者可以用自己的公钥进行替换，这样发送方就会用此公钥进行加密，然后攻击者再次截获发送方的报文，用自己的私钥解密，还原报文内容并进行篡改，随后用之前截获的接收方的公钥进行加密，再转发给接收方，实现一个“偷梁换柱”，谁也不会察觉。
为了解决上述问题，就引入了证书机制。
证书通常是由值得信赖的第三方机构颁发，随公钥一起发出，以证明公钥的安全性。