1. HTTP 协议
在谈论 HTTPS 协议以前，先来回顾一下 HTTP 协议的概念。html
1.1 HTTP 协议介绍
HTTP 协议是一种基于文本的传输协议，它位于 OSI 网络模型中的应用层。web
HTTP 协议是经过客户端和服务器的请求应答来进行通信，目前协议由以前的 RFC 2616 拆分红立六个单独的协议说明（RFC 7230、RFC 723一、RFC 723二、RFC 723三、RFC 723四、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 算法来实现。app
在约定加密方式的时候由服务器生成一对公私钥，服务器将公钥返回给客户端，客户端本地生成一串秘钥(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 有个更深入的了解。
本文分享自微信公众号 - Java旅途（Javatrip）。
若有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一块儿分享。