HTTPS 是 HTTP 的安全版，在 HTTP 下增加了 SSL 层，对传输的数据进行了加密，使得通信更加的安全。但是，因为 HTTPS 需要建立更多的通信，并且数据在传输的过程中需要进行加密、解密，所以网站访问速度要比 HTTP 慢。
以前我对于 HTTPS 的了解仅限于此，知其然不知其所以然。前段时间在工作中需要部署 HTTPS，趁着这次机会更加全面的了解了 HTTPS，现通过这篇博客谈谈我对于 HTTPS 的一点理解。
加密算法
HTTPS 协议下传输的数据都进行了加密，因此在了解 HTTPS 之前需要先了解一下加密算法。
加密算法有很多，主要可以分为对称加密算法、非对称加密算法。对称加密通过加密算法和密钥对原始数据进行加密得到密文，如果想要获得原始数据，则需要使用加密时使用的密钥及算法的逆算法对密文进行解密，在对称加密算法只使用一个密钥，如：DES 算法；非对称机密与对称加密不同之处在于，非对称加密过程中需要使用两个密钥，这两个密钥被称为公钥和私钥，公钥加密后的数据只能使用私钥解密，而私钥加密后的数据只能使用公钥解密，较之对称加密具有更高的安全性，如：RSA 算法。
除了对称加密和非对称加密之外，还有一类加密算法叫做 Hash 算法。
哈希算法将任意长度的二进制值映射为较短的固定长度的二进制值，这个小的二进制值称为哈希值。哈希值是一段数据唯一且极其紧凑的数值表示形式。如果散列一段明文而且哪怕只更改该段落的一个字母，随后的哈希都将产生不同的值。要找到散列为同一个值的两个不同的输入，在计算上是不可能的，所以数据的哈希值可以检验数据的完整性。一般用于快速查找和加密算法。
Hash 算法 是不可逆算法，不可逆指无法（并不是完全没有办法，只是难度很高）根据密文得到原始数据。同时，即使原始数据发生一点变化，通过 Hash 算法得到的 Hash 值也将不同，因此 Hash 算法通常用来生成信息摘要或签名，如：MD5 算法。
HTTPS 的原理
我们都知道 HTTP 协议是明文传递数据的，这就导致了在数据传递的过程中如果被第三方截获，那么通信内容对于第三方就是完全透明的。因此，如果要保证通信的安全，最先想到的就是对传输的数据进行加密，这样即使被第三方截获，他也无法得知通信的原始内容。
根据上文提到的加密算法，如果要加密数据，可以使用对称加密或者非对称加密。对称加密和非对称加密的区别在于，对称加密中加密和解密使用的是相同的密钥，而非对称加密中使用的是公钥和私钥，因此 非对称加密要比对称加密更加安全，不过在执行效率上，对称加密比非对称加密的效率要高得多，尤其是在数据较大时，如果使用非对称加密会很慢。因此，对于数据的加密，应该使用对称加密。但是，使用对称加密时却存在一个问题，那就是 通信双方无法安全的进行密钥交换，因为在密钥的传输过程中，有可能密钥会被第三方所截获，一旦密钥被截获，那么传输的密文就可以被第三方解密出来，丧失安全性。因此对称加密的密钥不能通过明文传输，必须也要经过加密。
那么应该如何加密对称加密时使用的密钥呢？如果仍然使用对称加密，那么就进入到了一个死循环状态，此时，就轮到非对称加密登场了。非对称加密解决了对称加密中的密钥传输问题，它使用了两个密钥，其中公钥通常用来分发，而私钥则自己保留。在建立安全通信时，由通信的一方（以下称为“甲方”）生成公钥和私钥，然后将公钥传输给另一方（以下称为“乙方”），其中公钥采用明文传输的方式。乙方在收到甲方传递过来的公钥后，生成对称加密的密钥，然后用公钥进行加密并将加密后的密文返回给甲方。甲方在收到包含对称加密密钥的密文后，使用自己保留的私钥进行解密即可获得密钥。此后，双方就能使用对称加密的密钥进行安全的通信了。
在上述过程中，即使包含对称加密密钥的密文被第三方截获，第三方因为没有私钥，所以无法解密密文获取对称加密的密钥。这一过程看似没有问题，实则不然。在甲方传递公钥给乙方的过程中，如果第三方截获了公钥，并自己生成了新的公钥和私钥，然后把自己的公钥传递给乙方，乙方在收到第三方的公钥后（乙方不知情，他以为公钥是甲方给他的），生成对称加密的密钥，然后用公钥加密，并返回给甲方，这一过程又被第三方所截获，因为公钥是自己的，所以第三方可以用自己的私钥解密并获取对称加密的密钥。接着，第三方用之前截获的甲方的公钥，对对称加密的密钥进行加密并返回给甲方，因为公钥是甲方的，所以甲方可以成功用自己的私钥解密并获得密钥。这样，在甲乙双方不知情的情况下，第三方已经成功的获取到了双方通信时所使用的密钥了，如下图所示。那么问题来了，乙方在收到公钥后，如何确保这个公钥是甲方给他的呢？
这个问题就好比是有一天一个人跑过来和你说他是马云，他出来玩没带钱，如果你给他 100 块钱打车回家，他回去后给你 1 个亿。遇到这种情况，你如何能知道他就是马云呢？身份证拿出来看看！这基本是脱口而出的回答。那么要解决上述问题，甲方在发送公钥给乙方时，就还需要把自己的身份证给乙方看看。那甲方这个身份证如何来的呢？如何能确保身份证是不是真的呢？从现实生活中，我们可以得出答案。人民币由中国银行发行，所有人都承认人民币是有效地，并且人民币有特殊的制造工艺，具备防伪标识。
至此，显然只通过甲乙双方是无法建立安全通信的，需要一个第三方的权威机构介入，这个权威机构被称为 CA（Certificate Authority），在甲方申请后，CA 机构给甲方颁发“身份证”，甲方在发送公钥时连同自己的“身份证”一起发送给乙方，乙方通过核实“身份证”来确认公钥是否来自甲方。那么乙方如何核实“身份证”，并且如何确保“身份证”不会被伪造呢？这就需要一种只有 CA 能产出，并且所有乙方都能识别的机制，而非对称加密正好就满足这种一对多的机制。CA 机构通过自己的私钥对“身份证”进行加密生成密文，其中“身份证”被称为 数字证书，而密文则被称为 数字签名，然后将签名附加到证书中（签在底部），最后将经过签名后的证书颁发给甲方。于是，甲方在发送公钥时，连同证书一起发送给乙方，乙方在收到后，使用 CA 机构的公钥解密签名，对比签名的内容和证书内容是否相同即可验证甲方身份。那么问题又来了，乙方如何知道 CA 机构的公钥呢？显然如果继续通过网络传输的方式获取，这个问题可能永远都无法解决，而考虑到这样的权威机构可能只需要一个就够了，完全可以让乙方一开始就保留着该公钥，例如：浏览器内置 CA 机构的公钥。通过这样的机制，甲乙两方就能建立安全的通信了。具体关于 CA 证书的介绍以及它是如何证明公钥没有被篡改的，见我另外一篇博客。
HTTPS 通信过程
前面在了解了 HTTPS 的原理之后，再来说说 HTTPS 的具体通信过程，HTTPS 通信的过程基本就是原理中提到的几个步骤，具体如下：
- 客户端向服务端 Say Hello，包含支持的 SSL 协议版本、加密算法、密钥长度等信息。
- 服务端响应客户端信息发送 Server Hello 报文，报文中包含确定的加密算法、密钥长度等信息。
- 服务端发送证书给客户端。
- 最后服务器发送 Server Hello Done 报文通知客户端，最初阶段的SSL握手协商部分结束。
- 客户端收到证书后，验证证书的有效性。如果证书无效，在浏览器上会提示；如果验证有效，发送 Client Key Exchange 报文给服务端，报文中包含被称为 Pre-master secret 的随机码，该随机码通过服务端证书中的公钥进行加密。
- 接着客户端继续发送 Change Cipher Spec 报文。该报文会提示服务器，在此报文之后的通信会使用 Pre-master secret 密钥加密。
- 客户端发送 Finished 报文。该报文包含连接至今全部报文的整体校验值。如果服务器能解密出来，则握手成功。
- 服务端收到 Finished 报文并成功解密后，同样发送 Change Cipher Spec 报文和 Finished 报文给客户端。
- 成功建立安全连接，进行 HTTP 通信，底层通过 SSL 加密。
- 通信结束，发送报文关闭连接。