快来使用HTTPS吧

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

为什么使用HTTPS

HTTP 协议，本身是明文传输的，没有经过任何安全处理。那么这个时候就很容易在传输过程中被中间者窃听、篡改、冒充等风险。。

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证书需要存放在哪里呢？

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

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

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

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

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

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

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

HTTPS设计上的借鉴

对于HTTPS设计上的方案，对于我们而言，有什么可以借鉴的地方么，答案是肯定的：有。一个非常典型的方案就是RSA双向认证。

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

• 原文来自：http://blog.720ui.com/2016/security_https/
• 本文地址：https://www.linuxprobe.com/https.html ‎编辑员：岳国帅，审核员：苏西云

本文原创地址：https://www.linuxprobe.com/https.html