一、HTTPS出现的原因
TIP一项新技术的产生一定是为了解决某些问题，
HTTPS的产生就是为了解决HTTP具有的以下安全性问题：
- 使用明文进行通信，内容可能会被窃听
- 不验证通信双方的身份，容易进行身份伪造
- 无法证明报文的完整性，报文有可能遭到篡改
首先，需要明确的是，HTTPS并不是一种新的协议，而是让HTTP和
SSL(Secure Sockets Layer)通信，再由SSL和TCP通信，也就是说HTTPS使用了隧道通信。通过使用SSL，HTTPS具有了加密，认证和完整性保护的特点，这篇文章主要对这三个特点进行概述。
二、加密
TIP 首先，需要先了解下 对称加密 和 非对称加密 两种加密方式，然后才能说明
HTTPS所使用的加密机制 如果对加密这部分感兴趣，请自行深入了解，本文只作概述。
参考文章: 彻底搞懂HTTPS的加密原理
对称加密(Symmetric-Key Encryption)
TIP简单来说，对称加密就是使用同一个密钥完成加密和解密的操作。
优点：
- 运算速度快，传输效率较高
缺点：
- 无法安全的将密钥传输给通信方
非对称加密
TIP 非对称加密也可称为公开密钥加密(Public-Key Encryption)，加密和解密使用不同的密钥。
通常一个称为公钥，一个称为私钥。其中，公开密钥所有人都可获得，通信发送方获得接收方的公开密钥之后，就可以使用公钥对数据进行加密，接收方收到通信内容使用私钥解密。
并不是只有称为公钥的才可以加密，私钥也可以进行加密。只不过 使用公钥加密的必须用对应的私钥解密，同样，使用私钥加密只能使用对应公钥解密。
优点：可以更安全地将公开密钥传输给通信发送方
缺点：运算速度较慢
HTTPS采用的加密机制
TIP 上面我们提到，对称加密的传输效率高，但是无法保证密钥在传输过程中的安全性。而非对称加密，虽然可以保证传输的安全性，但是传输效率较低。
因此，
HTTPS采用了混合加密方式(非对称 + 对称 加密)：
- 使用非对称加密方式，传输对称加密需要的的密钥(Secret Key)，从而确保传输的安全性
- 获取到密钥之后，再通过对称加密的方式进行通信，从而保证效率
大致流程：
- 某网站拥有用于非对称加密的公钥A，私钥A’
- 浏览器向网站服务器发起请求，服务器把公钥A明文传输给浏览器
- 浏览器随机生成一个用于对称加密的密钥X，用公钥A加密后传给服务器
- 服务器拿到后用私钥A’进行解密，得到密钥X
- 这样通信双方都拥有密钥X了，且别人无法知道它，之后双方就通过密钥X对数据进行加密通信
Q & A
1. 为什么不直接使用对称加密？
TIP 如果通信双方都各自持有同一个密钥，且没有别人知道，这两方的通信安全当然是可以被保证的（除非密钥被破解）。
然而最大的问题就是这个密钥怎么让传输的双方知晓，同时不被别人知道。如果由服务器生成一个密钥并传输给浏览器，那在这个传输过程中密钥被别人劫持到手了怎么办？之后他就能用密钥解开双方传输的任何内容了，所以这么做当然不行。
2. 直接使用非对称加密可以吗？
TIP 鉴于非对称加密的机制，我们可能会有这种思路：服务器先把公钥以明文方式传输给浏览器，之后浏览器向服务器传数据前都先用这个公钥加密好再传，这条数据的安全似乎可以保障了！因为只有服务器有相应的私钥能解开公钥加密的数据。
然而反过来由服务器到浏览器的这条路怎么保障安全？如果服务器用它的私钥加密数据传给浏览器，那么浏览器用公钥可以解密它，而这个公钥是一开始通过明文传输给浏览器的，若这个公钥被中间人劫持到了，那他也能用该公钥解密服务器传来的信息了。所以目前似乎只能保证由浏览器向服务器传输数据的安全性
通过一组公钥私钥，可以保证单个方向传输的安全性，那用两组公钥私钥，就能保证双向传输都安全了，只不过这种方案非常耗时，性能很差。
三、认证
中间人攻击
TIP 上文提到，
https采用了混合加密方式，但仅通过以上步骤，还是存在安全隐患，比如中间人攻击:
如果在数据传输过程中，中间人劫持到了数据，此时他的确无法得到浏览器生成的密钥X，这个密钥本身被公钥A加密了，只有服务器才有私钥A’解开它，然而中间人却完全不需要拿到私钥A’就能干坏事了。比如：
- 某网站有用于非对称加密的公钥A、私钥A’。
- 浏览器向网站服务器请求，服务器把公钥A明文给传输浏览器。
- 中间人劫持到公钥A，保存下来，把数据包中的公钥A替换成自己伪造的公钥B（它当然也拥有公钥B对应的私钥B’）。
- 浏览器生成一个用于对称加密的密钥X，用公钥B（浏览器无法得知公钥被替换了）加密后传给服务器。
- 中间人劫持后用私钥B’解密得到密钥X，再用公钥A加密后传给服务器。
- 服务器拿到后用私钥A’解密得到密钥X。
存在这种安全隐患的根本原因是浏览器无法确认收到的公钥是不是网站自己的。那么如何证明浏览器收到的公钥一定是该网站的公钥，而不是伪造的？如果网站也能拥有类似“身份证”的东西，问题就可以解决
于是，CA机构应运而生，它所颁发的“身份证”就是 数字证书
数字证书
TIP 网站在使用
HTTPS前，需要向CA机构申领一份数字证书，数字证书里含有证书持有者信息、公钥信息等。服务器把证书传输给浏览器，浏览器从证书里获取公钥就行了，证书就如身份证，证明“该公钥对应该网站”
WARNING 然后，我们又发现了新问题： 在证书传输过程中，如何确保它没有被篡改？
再次类比“身份证”，身份证拥有一些防伪技术，所以通常情况下没法随意伪造，如果证书也有防伪技术问题就解决了，于是，数字签名出现了
数字签名
TIP数字签名的制作过程：
- CA机构拥有非对称加密的私钥和公钥。
- CA机构对证书明文数据T进行hash。
- 对hash后的值用私钥加密，得到数字签名S。
明文和数字签名共同组成了数字证书，这样一份数字证书就可以颁发给网站了。 那浏览器拿到服务器传来的数字证书后，如何验证它是不是真的？（有没有被篡改、掉包）
浏览器验证过程：
- 拿到证书，得到明文T，签名S。
- 用CA机构的公钥对S解密（由于是浏览器信任的机构，所以浏览器保有它的公钥。详情见下文），得到S’。
- 用证书里指明的hash算法对明文T进行hash得到T’。
- 显然通过以上步骤，T’应当等于S‘，除非明文或签名被篡改。所以此时比较S’是否等于T’，等于则表明证书可信。
Q & A
1. 中间人有可能篡改证书吗？
TIP 假设中间人对证书中的数据进行了篡改，由于他没有CA机构的私钥，所以他无法得到篡改后的签名。浏览器得到该证书后会发现原文和签名解密后的值不一致，则说明证书不可信，从而终止信息的传输
2. 证书有可能被整个掉包吗？
TIP 证书里包含了网站A的信息，包括域名，浏览器把证书里的域名与自己请求的域名比对一下就知道有没有被掉包了
3. 为什么制作数字签名时需要hash一次？
TIP 前面我们已经说了非对称加密效率较差，证书信息一般较长，比较耗时。而hash后得到的是固定长度的信息（比如用md5算法hash后可以得到固定的128位的值），这样加解密就快很多。
4. 怎么证明CA机构的公钥是可信的？
TIP CA机构的公钥是否也可以用数字证书来证明？没错，操作系统、浏览器本身会预装一些它们信任的根证书，如果其中会有CA机构的根证书，这样就可以拿到它对应的可信公钥了。
实际上证书之间的认证也可以不止一层，可以A信任B，B信任C，以此类推，我们把它叫做
信任链或数字证书链。也就是一连串的数字证书，由根证书为起点，透过层层信任，使终端实体证书的持有者可以获得转授的信任，以证明身份。
对称加密虽然性能好但有密钥泄漏的风险，非对称加密（2组公钥+2私钥双向传输）安全但性能低下，因此考虑用非对称加密来传输对称加密所需的密钥，然后进行对称加密，但是为了防止非对称过程产生的中间人攻击，需要对服务器公钥和服务器身份进行配对的数字认证，然后引入了CA数字签名+数字证书验证的方式
5. 每次进行HTTPS请求时都必须在SSL/TLS层进行握手传输密钥吗？
TIP 服务器会为每个浏览器（或客户端软件）维护一个session ID，在TLS握手阶段传给浏览器，浏览器生成好密钥传给服务器后，服务器会把该密钥存到相应的session ID下，之后浏览器每次请求都会携带session ID，服务器会根据session ID找到相应的密钥并进行解密加密操作，这样就不必要每次重新制作、传输密钥了
四、完整性保护
TIP SSL 提供报文摘要功能来进行完整性保护。
HTTP 也提供了 MD5 报文摘要功能，但不是安全的。例如报文内容被篡改之后，同时重新计算 MD5 的值，通信接收方是无法意识到发生了篡改。
HTTPS 的报文摘要功能之所以安全，是因为它结合了加密和认证这两个操作。试想一下，加密之后的报文，遭到篡改之后，也很难重新计算报文摘要，因为无法轻易获取明文