HTTPS核心机制拆解
目录
引言
HTTPS和HTTP的区别
常见加密方式
数据摘要
数字证书与数据签名
HTTPS请求过程
结语
引言
HTTPS是什么？是一个应用层协议，在HTTP协议的基础上引入了一层加密层。为什么需要HTTPS？答案是显而易见的，要加密，当然就是为了安全。因为HTTP协议是明文传输的，明文数据会经过路由器、WiFi热点、通信服务运营商、代理服务器等多个物理节点，如果信息在传输过程中被劫持，传输的内容就完全暴露了，进而导致隐私泄漏，而且劫持者还可以篡改传输的信息而不被双方察觉，这就是中间人攻击，所以为了避免上述情况发生，HTTPS也就应运而生了。
简单介绍一下TLS。
TLS（传输层安全协议）是现代网络通信中应用最广泛的安全协议，主要用于实现以下目标：
- 数据加密：建立安全通道保护传输数据
- 身份验证：通过数字证书验证通信方身份
- 数据完整性：防止传输过程被篡改
HTTPS和HTTP的区别
HTTPS和HTTP的区别就在于——HTTPS有加密层，而HTTP没有。如果还要说一点区别的话，HTTP的默认端口号是80，HTTPS的默认端口号是443。至于其他的，比如报文结构等就是完全继承HTTP那套了。
常见加密方式
在继续深入HTTPS的加密机制前，我们首先需要了解一些必备的知识，以便于更好的理解加密的机制。
常见的加密方式有两种，一种是对称加密，另一种是非对称加密。
1）对称加密：一个密钥，加密和解密的密钥是相同的。特点是，计算量小，加密解密速度快，效率高。
2）非对称加密：一对密钥，公钥（public key）和私钥（private key）。
● 公钥加密，私钥解密，也可以反过来，私钥加密，公钥解密。
● 公钥任何人都可以持有，但是私钥坚决不能泄漏。
● 特点是，算法强度复杂，加密解密速度很慢。
似乎对称加密就足以满足我们所需的安全性了，而且效率高，为什么还要有非对称加密？对称加密，通信双方持有相同的密钥，不仅可以通过密钥加密数据后发送给对方， 还可以用同一个密钥来对方发来的数据进行解密，似乎已经很完美了，其实不然！要使用对称加密，首先要解决的问题是如何将密钥安全的传递给对方。在不加密的情况下，直接以明文的方式将密钥传给对方，这是很危险的，因为如果被中间人劫持，中间人也有同一份密钥后，接下来双方的通信对他来说将是透明的，因为中间人劫持数据后，通过手中持有的密钥可以对数据进行解密，就知道双方都在聊些什么了，敏感信息的泄露几乎是必然的。
好巧不巧，非对称加密可以做到安全的交换密钥。
服务器有公钥S与对应的私钥S'，客户端有对称密钥C。
客户端向服务器发送请求获取公钥S ---> 对称密钥C通过S加密发送给服务器，因为只有服务器持有对应的密钥S'，所以只有服务器能解密 ---> 服务器通过密钥S'解密，获取对称密钥C ---> 由于对称密钥C只有客户端和服务器持有，所以后续通信只用对称密钥加密即可安全通信。 这个方案就真的无懈可击了吗？并不是的，仍有欠缺。
中间人持有非对称加密的公钥M，私钥M' ---> 客户端向服务器发送请求获取公钥S ---> 服务器明文传送公钥S给客户端 ---> 中间人劫持数据报，获取公钥S，然后将自己的公钥M发送给客户端（客户端目前是没办法察觉到公钥被替换的）---> 客户端通过M加密对称密钥C发给服务器 ---> 中间人劫持，通过M'解密得到对称密钥C，然后通过前面拿到的S对对称密钥C加密后传给服务器 ---> 服务器通过S'解密拿到对称密钥C（双方都没有察觉到任何问题）---> 通过对称密钥C加密进行正常通信，由于中间人也有对称密钥C，所以他在劫持报文后可以解密查看里面的内容。
所以，如果能保证服务器的公钥S能安全的传给客户端，那么就可以保证后续通信的安全。 如何保证公钥S安全的送到客户端？用私钥S'对其进行加密吗？如果是这样的话，客户端拿到数据也无法解密呀！我们梳理一下这个逻辑：服务器通过私钥S'加密，将公钥S传给客户端 ---> 客户端收到数据后，需要通过公钥S解密才能获取被密钥S'加密后的公钥S。这很显然是有问题的，如果客户端一开始就有服务器的公钥S的话，还需要多此一举让服务器传过去吗？
事已至此，不得不引入第三方——CA机构。
数据摘要
在引入第三方机构CA之前，先谈谈数据摘要。
数据摘要就是通过散列函数对数据进行运算，然后得到一段长度固定的字符串，也就是数据摘要，它具有唯一性。不同的文本，哪怕只有一个标点符号不同，得到的数据摘要都会大相径庭，不会一样。因此，数据摘要被形象的称为数据指纹，它就像人的指纹一样，每个人的都不一样。
数据摘要通常用来进行数据比对，同一个文本，经过同一个散列函数运算，得到的摘要是一样的。
数字证书与数据签名
服务器在使用HTTPS之前，需要向CA（Certificate Authority，证书认证机构）申请一份数字证书，包含申请者的信息、公钥、域名等。所谓的CA，就是比较权威的、可信任的第三方机构。其作用就好比某宝，消费者在某宝上购物时，钱首先是到某宝的账户上，由它暂时保管，消费者确定收货以后，某宝便会把钱给到商家。为了完成这个交易，很重要的一点就是——信任第三方机构某宝。CA机构签发的证书就好比身份证，证明服务端公钥的权威性。
通过CA机构的密钥对明文信息的摘要进行加密，提取指纹，这一动作就叫做数据签名。
CA公钥内置于浏览器中，客户端收到证书后，通过CA内置的公钥对签名要进行解密，得到数据摘要 ---> 客户端对明文数据通过相同的散列函数形成摘要 ---> 比对两份指纹是否一致 ---> 如果一致，数据没有被篡改，即服务器的公钥S没有被替换过，是可信的，这样就可以保证服务器的公钥S安全的送到客户端。
可能会有这样的疑问——CA的公钥任何人都可以拿到，这样，中间人就可以对签名进行解密，拿到数据摘要，修改摘要和明文，怎么保证服务器公钥S的安全?
1）修改明文，不修改摘要 ---> 明文形成的摘要和签名中的摘要不一致，客户端在验证证书的时候可以察觉到，进而提醒用户。
2）修改摘要，不修改明文 ---> 同第一种情况。
3）既修改明文，又修改摘要
更具体的说，就是中间人在修改明文后，形成摘要，替换掉签名中的摘要。然后在对摘要加密。但是，中间人并没有CA机构的私钥，所以他只能用自己的密钥来加密，然后客户端无论如何都是用CA机构的公钥来对签名解密，这就导致解密失败，客户端就可以察觉到数据被篡改了，进而提醒用户。
4）中间人替换掉整个证书
因为中间人没有CA机构的密钥，所以无法制作假的证书。但是，他可以向CA机构申请真的证书。客户端就可以通过内置的CA机构公钥来对签名进行解密，结果发现两份摘要确实是一致的。但是别忘了，证书中是有域名的，而且域名具有唯一性，客户端可以发现域名不对而察觉。
综上，中间人只要敢修改，客户端就能够察觉到，进而提醒用户，避免中间人盗取用户信息。
HTTPS请求过程
下面通过完整的https请求来说明一下TLS握手的过程。
浏览器从URL中提取协议名和域名，通过域名解析系统DNS将域名转换为IP地址，因为是https请求，所以浏览器知道默认的端口号443。然后经过三次握手于服务器建立TCP连接，如果是http请求，后续就可以发送http报文了，https还需要在TCP连接上确保安全。
结语
为了确保安全，HTTPS使用了对称加密+非对称加密+证书认证的组合方案。
HTTPS工作过程中涉及到三组密钥：
1）CA的非对称密钥，私钥用于形成签名，公钥内置在浏览器中。
2）服务器的非对称密钥，公钥包含于证书中，私钥自己持有，以便解密经过服务器公钥加密后的客户端数据，得到对称密钥。
3）用于加密http报文的对称密钥，由服务器的公钥加密后，发送给服务器，进而让服务器解密拿到对称密钥。
感谢支持！