HTTPS原理

一.背景

HTTP协议以明文方式发送内容，不提供任何方式的数据加密，如果攻击者截取了传输报文，就可以直接读懂其中的信息，因此HTTP协议不适合传输一些敏感信息，比如信用卡号、密码等。
为了解决数据传输的安全问题，诞生了SSL(安全套接字层)/TLS协议，依靠数字证书来验证服务器客户端的身份并未数据通信进行加密，位于TCP/IP协议与各个应用层协议之间做安全性处理。
随之诞生了HTTPS，即HTTP+SSL/TLS，其端口号使用443。

二.原理

SSL/TLS协议的基本思路是采用非对称加密的思想，也就是说，客户端先向服务器端索要公钥，然后用公钥加密信息，服务器收到密文后，用自己的私钥解密，这样可以防止拦截方获取明文数据，因为私钥只有服务器自己知道。
然而这就会有几个问题：

1. 如何保证向服务器端索要的公钥的正确性，即不被篡改？
   这个就用到了我们上面说到的CA数字证书了，由CA颁布的数字证书来确保公钥的正确性，只要数字证书是合法的，那么就认为其公钥是正确的。
2. 非对称加密的开销很大，如何减少耗时？
   上面说过，非对称加密比对称加密的耗时要长很多，每次数据传递如果使用非对称加密的话开销会很大，于是，SSL/TLS协议决定在握手阶段客户端和服务端通过非对称加密的方式获取同一把会话密钥，然后在本次会话之内，所有的通信内容都是使用同一把会话密钥，即每次数据加密使用的是对称加密；这样开销就会很少，因为非对称加密只是用于在握手阶段加密产生一把会话密钥，而每次通信的加密使用的是对称密钥。

三.设计

由上可知，SSL/TLS协议在握手阶段会使用非对称加密方式产生一把会话密钥，下面就来看看具体的握手过程是如何设计的：

1. 客户端首先向服务器发起一个请求，并携带过去一个客户端生成的随机数以及支持的加密算法类型，稍后用于生成会话密钥。
2. 服务端收到请求后，产生握手阶段第二个随机数，并且连同自己在CA上申请的数字证书和确认使用的加密算法类型，一起返回给客户端。
3. 客户端拿到数字证书后进行合法性、日期有效性、是否为目标服务器的证书等认证，认证通过后使用证书公钥解密证书并取出服务器的公钥，随后生成握手阶段第三个随机数，使用协商好的算法类型将三个随机数生成一个会话密钥，并用服务器公钥加密第三个随机数，传递给服务器。
4. 服务器拿到第三个加了密的随机数后，用自己的私钥解开，将三个随机数按照约定好的加密算法生成和客户端相同的一把会话密钥，最后通知客户端握手阶段结束。
5. 第2步中如果服务器需要认证客户端身份(可选)，可以请求客户端上传数字证书，第3步客户端的请求中就会携带自己的数字证书，第4步开始服务器就会先认证客户端的身份是否合法。
6. 之所以要使用三个随机数来生成会话密钥的原因，简单来讲就是三个伪随机结合在一起就接近真随机，不容易被猜出。
7. 握手阶段接受后，双方就有了同一把会话密钥，且身份认证过了，在此后的通信中，数据就使用同一把会话密钥来加密解密，即对称加密，由于会话密钥使用非对称加密生成，所以可以保证这把会话密钥不易泄露。

以上握手过程可以简单理解为下图

使用同一把会话密钥进行数据加密可以简单理解为下图

四.特点

1. 实现了身份认证和数据，确保了安全性和数据完整性，比http更安全可用
2. 是现有架构下最安全的解决方案，大大增加了攻击者的成本
3. HTTPS握手阶段费时较多，增加成本
4. CA数字证书需要费用，安全性越高费用越高，也增加成本
5. 并不是完全安全，一些掌握CA证书机构信息的或者加密算法信息的中间人一样可以进攻，且对DDos、DNS劫持等没有防护作用