HTTPS 原理剖析

小灰灰 2020-05-02 16:17 846阅读 0赞

## HTTPS 原理剖析

## 为什么使用 HTTPS

HTTP 协议，本身是明文传输的，没有经过任何安全处理。那么这个时候就很容易在传输过程中被中间者窃听、篡改、冒充等风险。这里提到的中间者主要指一些网络节点，是用户数据在浏览器和服务器中间传输必须要经过的节点，比如 WIFI 热点，路由器，防火墙，反向代理，缓存服务器等。

HTTP 协议，中间者可以窃听隐私，使用户的敏感数据暴露无遗；篡改网页，例如往页面插的广告内容，甚至进行流量劫持，比如有的时候你会发现域名没输错，结果却跑到了一个钓鱼网站上，因为被它劫持了。

为了解决这三大风险，HTTPS 的价值就体现出来了。

- 内容加密，第三方无法窃听。
- 身份认证，一旦被篡改，通信双方会立刻发现。
- 数据完整性。防止内容冒充或者篡改。

## 什么是 HTTPS

HTTPS，简单的理解 HTTP 的安全版，即 HTTP 下加入 SSL 层，由两部分组成：HTTP + SSL / TLS。

## HTTPS 原理剖析

![](/images/1588436218861.png)

- 用户在浏览器里输入一个 https 网址，此时客户端发起 HTTPS 请求，通过 TCP 和服务器建立连接（443端口）。
- 服务器存放 CA 证书进行处理，注意的是采用 HTTPS 协议的服务器必须要有一套数字证书，这套证书其实就是一对公钥和私钥。
- 服务器向客户端返回证书。证书里面包含了很多信息：比如域名，申请证书的公司，公钥等。以下是一个淘宝网的 CA 证书。

![](/images/1588436200988.png)

![](/images/1588436145511.png)

- 客户端对证书进行解析。这部分工作是有客户端的 TLS 来完成的，首先会验证公钥是否有效，比如颁发机构，过期时间等，如果发现异常，则会弹出一个警告框，提示证书存在问题。如果证书没有问题，那么就生成一个随机数，然后用证书对该随机数进行加密。
- 向服务器发送证书加密后的随机数。
- 服务器用它的私钥进行解密，得到了客户端传过来的随机数。
- 服务器用客户端的随机数加密后的信息发送给客户端。
- 客户端用之前生成的密钥解密服务端传过来的信息。

以上就是整个 HTTPS 的交互过程，大家是不是对整个流程有了比较大致的了解了呢。

## HTTPS 的相关场景

真实业务场景是复杂的，这里，整理 3 个项目中遇到的比较复杂的应用场景。

## 场景一，对 HTTPS 进行 CDN 加速

这种情况下，CA 证书需要存放在哪里呢？主要两个方案：

- 服务器（源站）提供证书给 CDN 厂商，包括公钥证书和私钥，CDN 负责交互和内容缓存，CDN 有缓存则直接响应，以 HTTP 或 HTTPS 的形式回源。这个方案，适用仅对防劫持、防篡改有需求，而愿意提供证书给 CDN 的源站加速。
- 服务器（源站）不提供证书，CDN 存放公钥，服务器（源站）存放私钥。在 CDN 与前端浏览器进行 TLS 的认证和秘钥协商过程中，通过安全的信道把协商过程中的信息以 HTTP 或 HTTPS 的形式转发给源网站。此方案中，CDN 不做缓存，仅以自有的加速网络，将用户的请求快速送到服务器（源站），降低公网延迟。这个方案，适用于对安全要求更高，不愿将私钥共享给 CDN 的源站加速。

## 场景二，对HTTPS 的域名通过 CNAME 绑定到另外一个 HTTPS 域名上

这个情况下，我们需要一个证书还是两个证书呢？

我们的方案是，两个证书。因为每个证书跟自己的域名进行绑定，即使它们都在同一个服务器上，也不能使用同一个证书。

## 场景三，两台服务器的证书问题

因为安全问题，CA 证书在一台服务器上，而服务部署在另外一台服务器上。这种情况就比较难办。

![](/images/1588436068091.png)

此时，需要借助 Nginx 进行反向代理，回源到具体的服务器。

## HTTPS 设计上的借鉴

对于 HTTPS 设计上的方案，对于我们而言，有什么可以借鉴的地方么？

答案是肯定的：有。一个非常典型的方案就是 RSA 双向认证。

RSA 双向认证，顾名思义，就是用对方的公钥加密是为了保密，这个只有对方用私钥能解密。用自己的私钥加密是为了防抵赖，能用我的公钥解开，说明这是我发来的。例如，支付宝的支付接口就是非常典型的RSA双向认证的安全方案。此外，我们之前的教育资源、敏感验证码出于安全性考虑都借鉴了这个方案。