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