前言
很久没写过这种纯理论的文章了，但是实际工作中有时候又确实是会用到这些理论知识，所以综合自己的了解和资料，整理一篇文章来记录一下Https的原理细节，方面日后自己回顾，也希望对各位读者有所帮助。
说在前面
我们知道，我们可以通过http协议来访问我们的web服务，这也是十分常见的访问方式，但我们会发现通过http协议访问的服务，我们会在浏览器看到类似下图的提示：
浏览器提示访问的连接不安全
这是因为在Http协议下，用户从浏览器端/客户端提交过来的数据都是明文传输的，在数据从浏览器到服务器传输的各个网络节点中，恶意的中间人可以通过直接拦截请求的方式截取到你的请求，看到你发送过去的明文数据。这里需要注意，对于服务端响应的数据也是一样的，大家的数据都是以明文的方式在互联网中“裸奔”。
中间人可以截取到明文数据
毫无疑问，http协议在安全性上存在着重大的隐患，所以对于正式上线的应用或者对安全性要求较高的网站来说，使用更加安全的https协议是更好的选择。那https到底比http协议安全在哪里呢？具体见下文讲解
一、Https简要介绍
HTTPS （全称：Hypertext Transfer Protocol Secure），简单来说就是在HTTP协议的基础上，加了一层处理加密信息的模块（引入了SSL/TLS协议进行加密处理），当服务端和客户端建立连接后，二者间的信息传输都会通过 TLS 进行加密，所以传输的数据都是加密后的数据。
二、Https怎么进行消息的加密
（一）对称加密：用于信息加密
对称加密的特性是，可以使用相同的秘钥对明文进行加密得到密文，也可以通过密文反向解密为明文。相信各位读者很容易就能想到，既然我们发送的信息是明文传输的，那只要客户端和服务端约定好一个秘钥，双方每次发送的信息都使用这个秘钥进行加解密，那么即使中间人通过手段截取到了发送的数据包，也无法知道服务端到底发送了什么数据给客户端。
中间人截取到的数据是加密过的数据
单纯的对称加密无法完全解决问题
虽然上文的对称加密似乎已经完美的解决了明文加解密问题，但是对称加密的使用前提是，通信的双方都知道用于对称加解密的秘钥是什么，在实际操作中，我们不可能说客户端生成一个秘钥后，复制到u盘中再拷贝到服务端的上面。就比如说我现在希望和百度建立https通信，但是我的秘钥在我本地，我无法直接告知百度我接下来使用的秘钥到底是什么？因为假使秘钥是通过http传输的，那么中间人只要截取到秘钥，对称加密的作用就形同虚设。而事实上，通过物理告知秘钥也不太现实。
中间人可以截取用于加密的秘钥
这个时候我们就需要用非对称性算法来解决我们的问题了
（二）非对称加密：用于秘钥加密
非对称加密的特性是，公钥私钥机制。简单来说就是，公钥谁都可以看，而私钥只有我自己有。那么只要我们知道服务端的公钥，在发送本地的秘钥时先使用公钥进行加密，再发送给服务端就行。这样即使中间人拦截到我们的秘钥，也会因为缺少服务端的私钥而无法反向破译出接下来用于加解密的秘钥。
image.png
为什么不只使用非对称性算法
到了这里，秘钥的传输问题也得到了解决，那么是不是就万事大吉了呢？
很遗憾，并不是！在分析还可能存在的问题之前，我们先来讲一下另外一个问题，我们有没有可能单纯使用非对称加密来解决通信的加密问题呢？
在技术上当然是可行的，服务端和客户端都生成各自的公钥和私钥，然后把公钥交给对方，接下来所有的信息都通过对方的公钥进行加密，那么即使中间人拿到了数据也会因为没有双方的私钥而无计可施。那既然非对称算法这么好，为什么还需要使用对称算法呢？直接单纯用非对称性算法不是更香吗？
答案是对称算法的性能要比非对称算法高很多，如果每次通信都是用非对称性算法来进行数据加解密的话，会浪费很多额外的性能在数据处理上，很明显，使用非对称加密算法来进行对称算法秘钥的加解密，再使用对称算法来处理通信的实际数据，是最经济的方式。
（三）万恶的中间人攻击
上文提到，使用非对称算法可以解决秘钥传输的问题，避免让中间人获取到我们后面通信的秘钥。但实际上还是不能完全解决通信安全问题，因为非对称算法的应用前提是服务端要把自己的公钥告知给客户端，那么在这个公钥告知的过程中中间人就又有可以操作的空间了。中间人可以拦截服务端发过去的公钥修改成自己的公钥，甚至是把自己伪装成服务端！
中间人伪装为服务器
仔细想想，这种漏洞存在的根本原因是什么？客户端无法知道服务端发送过来的公钥是否是真实的，没有被篡改过的
如何解决中间人攻击问题
引入具有公信力的第三方公证机构，既然服务端无法自证清白，那服务端还能相信谁呢？为了解决公钥的信任问题，业内提出了让知名机构来给服务端公钥背书的方案。让这个知名机构证明这个‘公钥’确实是我的公钥，接收方拿到公钥后去知名机构那里比对一下就行了，这个知名机构通常被叫做 CA(全称为Certificate Authority) 。
这里可能有读者会问，难道CA就不会有中间人的问题吗？中间人难道就不能在网络上伪装为CA吗？
这个问题人家当然了考虑过，事实上CA 证书是已经预先存储好在你的电脑里面的，因此不存在中间人攻击，除非你的电脑是被恶意设计过的。
当然了，实际应用中我们的操作系统安装的证书不可能预先将所有网站的公钥进行收录，那么对于新开的网站或者是没被收录的网站来说，他们要怎么获得CA的认可呢？
答案是中介。预安装在我们操作系统中的证书是根证书，根证书当然不能像预言家一样提前把未来我们都会访问的服务器公钥进行收录和认证，根证书会预先设置好信任的中间CA，而这些中间CA则会和具体的各个服务端对接公钥的认证。 说白了就是CA也做成代理商的方式，CA根证书信任CA代理商，CA代理商和服务端达成认证，只要代理商认可服务端的公钥，那么CA根证书就也一样认可。
证书信任链
简书的CA认证链
下面我们来仔细聊一下有CA参与的认证流程吧
1、服务方 S 向第三方机构CA提交公钥、组织信息、个人信息(域名)等信息并申请认证；
2、CA 通过线上、线下等多种手段验证申请者提供信息的真实性，如组织是否存在、企业是否合法，是否拥有域名的所有权等；
3、如信息审核通过，CA 会向申请者签发认证文件-证书。
证书包含以下信息：申请者公钥、申请者的组织信息和个人信息、签发机构 CA 的信息、有效时间、证书序列号等信息的明文，同时包含一个签名；
签名的产生算法：首先，使用散列函数计算公开的明文信息的信息摘要，然后，采用 CA 的私钥对信息摘要进行加密，密文即签名；
4、客户端 C 向服务器 S 发出请求时，S 返回证书文件；
5、客户端 C 读取证书中的相关的明文信息，采用相同的散列函数计算得到信息摘要，然后，利用对应 CA 的公钥解密签名数据，对比证书的信息摘要，如果一致，则可以确认证书的合法性，即公钥合法；
6、客户端然后验证证书相关的域名信息、有效时间等信息；
7、客户端会内置信任 CA 的证书信息(包含公钥)，如果CA不被信任，则找不到对应 CA 的证书，证书也会被判定非法。
此处需要注意，如果中间人想要伪装成服务端的话，那么他在第5步的时候就会被卡住，因为一旦中间人使用自己签发数字证书的话，就会因为证书签名无法被CA公钥正常解密，或者是因为解密后的hash摘要和客户端自己算出的hash摘要不同而被识别出来。
PS：但到这里其实也只能证明Https可以保证客户端和服务端之间的通信保密上是安全的，似乎无法解决中间人在会话建立过程中对信息的篡改问题，其实这个问题SSL协议也已经一并解决了
SSL采用了完整性保护机制来防止信息被篡改。具体来说，ssl协议会对每个传输的数据块进行哈希计算，并将哈希值附加到数据块上。当数据块到达接收方时，接收方会重新计算数据块的哈希值，并与发送方提供的哈希值进行比较。如果两个哈希值不匹配，就说明数据在传输过程中被篡改了。通过这种方式，HTTPS能够及时发现并防止数据被篡改。
参考文章：
面试题之 HTTPS 为什么是安全的？ https://juejin.cn/post/7077550129229594632
HTTPS 的故事 https://zhuanlan.zhihu.com/p/33043251
拯救不安全的HTTP — HTTPS https://segmentfault.com/a/1190000044696383
网友评论