共计 2871 个字符，预计需要花费 8 分钟才能阅读完成。
起源：segmentfault.com/a/1190000023936425
1. HTTP 协定
在议论 HTTPS 协定之前，先来回顾一下 HTTP 协定的概念。
1.1 HTTP 协定介绍
HTTP 协定是一种基于文本的传输协定，它位于 OSI 网络模型中的 应用层。
HTTP 协定是通过客户端和服务器的申请应答来进行通信，目前协定由之前的 RFC 2616 拆分成立六个独自的协定阐明（RFC 7230、RFC 7231、RFC 7232、RFC 7233、RFC 7234、RFC 7235），通信报文如下：
- 申请
POST http://www.baidu.com HTTP/1.1
Host: www.baidu.com
Connection: keep-alive
Content-Length: 7
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36
wd=HTTP- 响应
HTTP/1.1 200 OK
Connection: Keep-Alive
Content-Encoding: gzip
Content-Type: text/html;charset=utf-8
Date: Thu, 14 Feb 2019 07:23:49 GMT
Transfer-Encoding: chunked
<html>...</html>1.2 HTTP 中间人攻打
HTTP 协定应用起来的确十分的不便，然而它存在一个致命的毛病：不平安。
咱们晓得 HTTP 协定中的报文都是以明文的形式进行传输，不做任何加密，这样会导致什么问题呢？上面来举个例子：
- 小明在 JAVA 贴吧发帖，内容为
我爱 JAVA：
- 被中间人进行攻打，内容批改为
我爱 PHP
- 小明被群嘲(手动狗头)
能够看到在 HTTP 传输过程中，中间人能看到并且批改 HTTP 通信中所有的申请和响应内容，所以应用 HTTP 是十分的不平安的。
1.3 避免中间人攻打
这个时候可能就有人想到了，既然内容是明文那我应用 对称加密 的形式将报文加密这样中间人不就看不到明文了吗，于是如下革新：
- 单方约定加密形式
- 应用 AES 加密报文
这样看似中间人获取不到明文信息了，但其实在通信过程中还是会以明文的形式裸露加密形式和秘钥，如果第一次通信被拦挡到了，那么秘钥就会泄露给中间人，中间人依然能够解密后续的通信：
那么对于这种状况，咱们必定就会思考能不能将秘钥进行加密不让中间人看到呢？答案是有的，采纳 非对称加密，咱们能够通过 RSA 算法来实现。
在约定加密形式的时候由服务器生成一对 公私钥 ，服务器将 公钥 返回给客户端，客户端本地生成一串秘钥 (AES_KEY) 用于 对称加密 ，并通过服务器发送的 公钥 进行加密失去 (AES_KEY_SECRET)，之后返回给服务端，服务端通过 私钥 将客户端发送的 AES_KEY_SECRET 进行解密失去 AEK_KEY, 最初客户端和服务器通过AEK_KEY 进行报文的加密通信，革新如下：
能够看到这种状况下中间人是窃取不到用于 AES 加密 的秘钥，所以对于后续的通信是必定无奈进行解密了，那么这样做就是相对平安了吗？
所谓道高一尺魔高一丈，中间人为了对应这种加密办法又想出了一个新的破解计划，既然拿不到 AES_KEY，那我就把本人模仿成一个客户端和服务器端的结合体，在 用户 -> 中间人 的过程中中间人模仿服务器的行为，这样能够拿到用户申请的明文，在 中间人 -> 服务器 的过程中中间人模仿客户端行为，这样能够拿到服务器响应的明文，以此来进行中间人攻打：
这一次通信再次被中间人截获，中间人本人也伪造了一对公私钥，并将公钥发送给用户以此来窃取客户端生成的 AES_KEY，在拿到AES_KEY 之后就能轻松的进行解密了。
中间人这样随心所欲，就没有方法制裁下吗，当然有啊，接下来咱们看看 HTTPS 是怎么解决通信平安问题的。
2. HTTPS 协定
2.1 HTTPS 简介
HTTPS 其实是 SSL+HTTP 的简称, 当然当初 SSL 根本曾经被 TLS 取代了，不过接下来咱们还是对立以 SSL 作为简称，SSL协定其实不止是利用在 HTTP 协定上，还在利用在各种应用层协定上，例如：FTP、WebSocket。
其实 SSL 协定大抵就和上一节 非对称加密 的性质一样，握手的过程中次要也是为了替换秘钥，而后再通信过程中应用 对称加密 进行通信，大略流程如下：
这里我只是画了个示意图，其实真正的 SSL 握手会比这个简单的多，然而性质还是差不多，而且咱们这里须要关注的重点在于 HTTPS 是如何避免中间人攻打的。
通过上图能够察看到，服务器是通过 SSL 证书来传递 公钥 ，客户端会对 SSL 证书进行验证，其中证书认证体系就是确保SSL 平安的要害，接下来咱们就来解说下CA 认证体系，看看它是如何避免中间人攻打的。
2.2 CA 认证体系
上一节咱们看到客户端须要对服务器返回的 SSL 证书进行校验，那么客户端是如何校验服务器 SSL 证书的安全性呢。
- 权威认证机构
在 CA 认证体系中，所有的证书都是由权威机构来颁发，而权威机构的 CA 证书都是曾经在操作系统中内置的，咱们把这些证书称之为CA 根证书：
- 签发证书
咱们的应用服务器如果想要应用 SSL 的话，须要通过权威认证机构来签发 CA 证书，咱们将服务器生成的公钥和站点相干信息发送给CA 签发机构，再由CA 签发机构 通过服务器发送的相干信息用 CA 签发机构 进行加签，由此失去咱们应用服务器的证书，证书会对应的生成证书内容的 签名 ，并将该 签名 应用 CA 签发机构 的私钥进行加密失去 证书指纹，并且与下级证书生成关系链。
这里咱们把百度的证书下载下来看看：
能够看到百度是受信于 GlobalSign G2，同样的GlobalSign G2 是受信于 GlobalSign R1，当客户端(浏览器) 做证书校验时，会一级一级的向上做查看，直到最初的 根证书 ，如果没有问题阐明 服务器证书 是能够被信赖的。
- 如何验证服务器证书
那么客户端 (浏览器) 又是如何对 服务器证书 做校验的呢，首先会通过层级关系找到下级证书，通过下级证书里的 公钥 来对服务器的 证书指纹 进行解密失去 签名 (sign1)，再通过签名算法算出服务器证书的 签名 (sign2)，通过比照sign1 和sign2，如果相等就阐明证书是没有被 篡改 也不是 伪造 的。
这里乏味的是，证书校验用的 RSA 是通过私钥加密证书签名，公钥解密来奇妙的验证证书有效性。
这样通过证书的认证体系，咱们就能够防止了中间人窃取 AES_KEY 从而发动拦挡和批改 HTTP 通信的报文。
总结
首先先通过对 HTTP 中间人攻打的来理解到 HTTP 为什么是不平安的，而后再从平安攻防的技术演变始终到 HTTPS 的原理概括，心愿能让大家对 HTTPS 有个更粗浅的理解。
近期热文举荐：
1.1,000+ 道 Java 面试题及答案整顿(2022 最新版)
2. 劲爆！Java 协程要来了。。。
3.Spring Boot 2.x 教程，太全了！
4. 别再写满屏的爆爆爆炸类了，试试装璜器模式，这才是优雅的形式！！
5.《Java 开发手册（嵩山版）》最新公布，速速下载！
感觉不错，别忘了顺手点赞 + 转发哦！