HTTPS 原理剖析与项目场景

最近手头有两个项目，XX导航和XX产业平台，都需要使用HTTPS协议，因此，这次对HTTPS协议做一次整理与分享。

为什么使用HTTPS

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

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

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

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

什么是HTTPS

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

HTTPS原理剖析

第一步，用户在浏览器里输入一个https网址，此时客户端发起HTTPS请求，通过TCP和服务器建立连接（443端口）。

第二步，服务器存放CA证书进行处理，注意的是采用HTTPS协议的服务器必须要有一套数字证书，这套证书其实就是一对公钥和私钥。

第三步，服务器向客户端返回证书。证书里面包含了很多信息：比如域名，申请证书的公司，公钥等。以下是一个淘宝网的CA证书。

第四步，客户端对证书进行解析。这部分工作是有客户端的TLS来完成的，首先会验证公钥是否有效，比如颁发机构，过期时间等，如果发现异常，则会弹出一个警告框，提示证书存在问题。如果证书没有问题，那么就生成一个随机数，然后用证书对该随机数进行加密。

第五步，向服务器发送证书加密后的随机数。

第六步，服务器用它的私钥进行解密，得到了客户端传过来的随机数。

第七步，服务器用客户端的随机数加密后的信息发送给客户端。

第八步，客户端用之前生成的密钥解密服务端传过来的信息。

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

HTTPS的相关场景

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

场景一，对HTTPS进行CDN加速

这种情况下，CA证书需要存放在哪里呢？

主要两个方案。

方案一：服务器（源站）提供证书给CDN厂商，包括公钥证书和私钥，CDN负责交互和内容缓存，CDN有缓存则直接响应，以HTTP或HTTPS的形式回源。这个方案，适用仅对防劫持、防篡改有需求，而愿意提供证书给CDN的源站加速。

方案二：服务器（源站）不提供证书，CDN存放公钥，服务器（源站）存放私钥。在CDN与前端浏览器进行TLS的认证和秘钥协商过程中，通过安全的信道把协商过程中的信息以HTTP或HTTPS的形式转发给源网站。此方案中，CDN不做缓存，仅以自有的加速网络，将用户的请求快速送到服务器（源站），降低公网延迟。这个方案，适用于对安全要求更高，不愿将私钥共享给CDN的源站加速。

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

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

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

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

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

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

HTTPS设计上的借鉴

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

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

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