面试官：为何HTTPS是安全的

关注前端瓶子君，回复“ 交流 ”

加入咱们一块儿学习，每天进步html

来源：r6a.cn/efZ2

1. HTTP 协议

在谈论 HTTPS 协议以前，先来回顾一下 HTTP 协议的概念。

1.1 HTTP 协议介绍

HTTP 协议是一种基于文本的传输协议，它位于 OSI 网络模型中的 应用层 。

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 算法来实现。

在约定加密方式的时候由服务器生成一对 公私钥 ，服务器将 公钥 返回给客户端，客户端本地生成一串秘钥( 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根证书：web
签发证书面试

咱们的应用服务器若是想要使用 SSL 的话，须要经过权威认证机构来签发CA证书，咱们将服务器生成的公钥和站点相关信息发送给CA签发机构，再由CA签发机构经过服务器发送的相关信息用CA签发机构进行加签，由此获得咱们应用服务器的证书，证书会对应的生成证书内容的签名，并将该签名使用CA签发机构的私钥进行加密获得证书指纹，而且与上级证书生成关系链。算法

这里咱们把百度的证书下载下来看看：浏览器

能够看到百度是受信于 GlobalSign G2 ，一样的 GlobalSign G2 是受信于 GlobalSign R1 ，当客户端(浏览器)作证书校验时，会一级一级的向上作检查，直到最后的 根证书 ，若是没有问题说明 服务器证书 是能够被信任的。

如何验证服务器证书安全

那么客户端(浏览器)又是如何对服务器证书作校验的呢，首先会经过层级关系找到上级证书，经过上级证书里的公钥来对服务器的证书指纹进行解密获得签名(sign1)，再经过签名算法算出服务器证书的签名(sign2)，经过对比sign1和sign2，若是相等就说明证书是没有被篡改也不是伪造的。服务器

这里有趣的是，证书校验用的 RSA 是经过私钥加密证书签名，公钥解密来巧妙的验证证书有效性。

这样经过证书的认证体系，咱们就能够避免了中间人窃取 AES_KEY 从而发起拦截和修改 HTTP 通信的报文。

总结

首先先经过对 HTTP 中间人攻击的来了解到 HTTP 为何是不安全的，而后再从安全攻防的技术演变一直到 HTTPS 的原理归纳，但愿能让你们对 HTTPS 有个更深入的了解。

最后

欢迎关注「前端瓶子君」，回复「交流」加入前端交流群！

欢迎关注「前端瓶子君」，回复「算法」自动加入，从0到1构建完整的数据结构与算法体系！

另外，每周还有手写源码题，瓶子君也会解答哟！

》》面试官也在看的算法资料《《

“在看和转发” 就是最大的支持

本文分享自微信公众号 - 前端瓶子君（pinzi_com）。
若有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一块儿分享。微信