面试官：说说 HTTPS 是如何保证传输安全的？

ゝ一纸荒年。 2022-08-28 05:50 194阅读 0赞

## **1. HTTP 协议** ##

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

### 1.1 HTTP 协议介绍 ###

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

![dbb8ec329c26504632b274872a5ba38d.png][]

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 协议中的报文都是以明文的方式进行传输，不做任何加密，这样会导致什么问题呢？下面来举个例子：

1.  小明在 JAVA 贴吧发帖，内容为 `我爱JAVA`：

![30aca22af534a0a449b1cb687b269775.png][]

1.  被中间人进行攻击，内容修改为 `我爱PHP`

![07e1e89634e3d78f6005de1073fe5da4.png][]

1.  小明被群嘲(手动狗头)

可以看到在 HTTP 传输过程中，中间人能看到并且修改 HTTP 通讯中所有的请求和响应内容，所以使用 HTTP 是非常的不安全的。

推荐：[Java进阶视频资源][Java]

## **2. HTTPS 协议** ##

### 2.1 HTTPS 简介 ###

HTTPS 其实是`SSL+HTTP`的简称,当然现在`SSL`基本已经被`TLS`取代了，不过接下来我们还是统一以`SSL`作为简称，`SSL`协议其实不止是应用在`HTTP`协议上，还在应用在各种应用层协议上，例如：`FTP`、`WebSocket`。

其实`SSL`协议大致就和上一节`非对称加密`的性质一样，握手的过程中主要也是为了交换秘钥，然后再通讯过程中使用`对称加密`进行通讯，大概流程如下：

![c17247d25546c56e19ca69e02ec545a5.png][]

这里我只是画了个示意图，其实真正的 SSL 握手会比这个复杂的多，但是性质还是差不多，而且我们这里需要关注的重点在于 HTTPS 是如何防止中间人攻击的。

通过上图可以观察到，服务器是通过 SSL 证书来传递`公钥`，客户端会对 SSL 证书进行验证，其中证书认证体系就是确保`SSL`安全的关键，接下来我们就来讲解下`CA 认证体系`，看看它是如何防止中间人攻击的。

### 2.2 CA 认证体系 ###

上一节我们看到客户端需要对服务器返回的 SSL 证书进行校验，那么客户端是如何校验服务器 SSL 证书的安全性呢。

*  权威认证机构

在 CA 认证体系中，所有的证书都是由权威机构来颁发，而权威机构的 CA 证书都是已经在操作系统中内置的，我们把这些证书称之为`CA根证书`：

![a95e2adc16386db1d17c98f3fc4fcd4d.png][]

*  签发证书

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

这里我们把百度的证书下载下来看看：

![2900ee8106ac882a77a8f532b2bae415.png][]

![d174d565b289a1700708331e1af99eb1.png][]

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

*  如何验证服务器证书

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

![1985cef3343722bc06dd28382128d5e3.png][]

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

这样通过证书的认证体系，我们就可以避免了中间人窃取`AES_KEY`从而发起拦截和修改 HTTP 通讯的报文。

## **总结** ##

首先先通过对 HTTP 中间人攻击的来了解到 HTTP 为什么是不安全的，然后再从安全攻防的技术演变一直到 HTTPS 的原理概括，希望能让大家对 HTTPS 有个更深刻的了解。

> \*感谢阅读，希望对你有所帮助 :) \*
> 
> 来源：segmentfault.com/a/1190000023936425

[dbb8ec329c26504632b274872a5ba38d.png]: /images/20220828/226975113fbd43a8bd8c78404d5fd4c0.png
[30aca22af534a0a449b1cb687b269775.png]: /images/20220828/73b3667fc80a49209765050dd724c25c.png
[07e1e89634e3d78f6005de1073fe5da4.png]: /images/20220828/9298fb4d71534896befa53611382a143.png
[Java]: https://blog.csdn.net/m0_37834446/article/details/90727860
[3e4b84bcad5d41e2989db9cf07dfb831.png]: /images/20220828/d00734b738f740648f91b3135326c076.png
[4d5d25b7a687243f784d4368ea24a6e0.png]: /images/20220828/3ebb5b2d9e5c4b5c81c07c483d5c768f.png
[30a731b8ab8736260a1cff2092fe95b2.png]: /images/20220828/a5e17d5f9f964a12bb94e8864c282e78.png
[6c6f56ec59afb93cdd441521fefdd35f.png]: /images/20220828/96de7e7360194fce8f36ce333f9e6c0f.png
[5505a828939eb7ba935145067a7ee133.png]: /images/20220828/5918f97ecd7647b59bdd164bdbbe3a6c.png
[c17247d25546c56e19ca69e02ec545a5.png]: /images/20220828/6efc3e3894e647319df4446ab6fe1a36.png
[a95e2adc16386db1d17c98f3fc4fcd4d.png]: /images/20220828/6db7eb49c44747b682911e13d50b396f.png
[2900ee8106ac882a77a8f532b2bae415.png]: /images/20220828/0543db5bccbb4098b6568a7135f5064e.png
[d174d565b289a1700708331e1af99eb1.png]: /images/20220828/5af480c940a5481aafb1f33492da1de6.png
[1985cef3343722bc06dd28382128d5e3.png]: /images/20220828/90161b91fbb84d368c5105c2fbd9e85d.png