服务端指南 | HTTPS 项目实战指南

本文将重点介绍关于 HTTPS 的几个实战指南。

原文地址：服务端指南 | HTTPS 项目实战指南
博客地址：blog.720ui.com/

本文将重点介绍关于 HTTPS 的几个实战指南。

1. HTTPS 使用剖析
2. HTTPS 项目场景
3. HTTPS 设计上的借鉴
4. HTTPS 降级攻击

HTTPS 使用剖析与项目场景

HTTP 协议没有加密机制，能够经过 SSL 或 TLS 加密 HTTP 的通讯内容。所以，HTTPS 是 HTTP 的安全版，在 HTTP 协议中加入 SSL 层，它由两部分组成：HTTP 与 SSL。其中，SSL 是独立于 HTTP 的协议，它不只能够适用于 HTTP 协议，还能够配合 WebSocket 等协议一块儿使用。

为何使用 HTTPS

HTTP 协议没有加密机制，通讯内容是明文传输的，没有通过任何安全处理。然而，互联网的任何角落均可能存在通讯内容在传输过程当中被中间者窃听、篡改、冒充等风险。其中，任何角落指的是用户的通讯内容在浏览器和服务器中间传输必需要通过的节点，好比 WIFI 热点，路由器，防火墙，反向代理，缓存服务器等。所以，HTTP 协议通讯存在的威胁不言而喻，中间者能够窃听隐私，使用户的敏感信息泄露；篡改网页，例如中间者向页面插入广告内容，甚至有的中间者进行流量劫持，例若有的时候会发现域名没有输错，结果却跳转到了一个钓鱼网站，由于这个网站被中间者劫持了。

所以，为了解决窃听、篡改、冒充等风险，HTTPS 的价值就体现出来了，HTTPS 能够进行通讯内容加密，使第三方没法窃听。HTTPS 能够进行身份认证，一旦通讯内容被篡改，通讯双方会马上发现。此外，HTTPS 能够保证通讯内容的完整性，防止通讯内容冒充或者篡改。

SSL 与 TLS

HTTP 协议能够经过 SSL 或 TLS 加密 HTTP 的通讯内容。其中，SSL 最初由网景通讯公司率先倡导与开发，最新版本是 SSL 3.0。目前，由 IETF 主导与管理。IETF 以 SSL 3.0 为基准，在 SSL 3.0 协议规范之上又制定了 TLS 1.0、 TLS 1.1 和 TLS 1.2。

HTTPS 原理剖析

为了更好地理解 HTTPS，先来观察一下 HTTPS 的通讯步骤。

第一步，用户在浏览器里输入一个支持 HTTPS 协议的网址，例如 blog.720ui.com，此时会发起一个 HTTPS 请求，经过 TCP 和服务器创建链接，其中使用 443 端口。

第二步，服务器向客户端发送证书，其中包括域名，申请证书的公司，证书的公钥等信息。

第三步，客户端经过 SSL 或 TLS 对证书进行解析，验证公钥是否有效，例如验证颁发机构与验证过时时间等信息，若是发现证书异常，则会弹出一个警告框，提示证书存在问题。若是证书没有问题，那么就生成一个密钥，而后向服务器发送证书公钥加密后的密钥。

第四步，服务器用证书私钥进行解密，得到客户端传过来的密钥。

第五步，服务器用客户端的密钥加密后的信息发送给客户端。

第六步，客户端用密钥解密服务端传过来的信息，验证服务端传过来的信息是否能够用密钥进行解密。

第七步，客户端用密钥加密请求内容，而后将通讯内容发送给服务端。

第六步，服务端用密钥解密请求内容，并进行业务处理后用密钥加密响应内容，而后将通讯内容发送给客户端。

在以上流程中，HTTPS 协议将对称加密算法与非对称加密算法的优点相结合。使用对称加密算法对通讯内容进行快速加密，从而弥补了非对称加密算法处理速度慢的问题，并保证通讯内容的机密性。同时，使用非对称加密算法将对称加密算法的密钥进行加密，保证对称加密算法的密钥的安全交换。所以，HTTPS 协议先经过非对称加密算法进行密钥的安全交换，并在创建通讯链接后，使用对称加密算法进行通讯，保证通讯内容的机密性。

HTTPS 项目场景

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

对 HTTPS 协议的通讯内容进行 CDN 加速

对 HTTPS 协议的通讯内容进行 CDN 加速主要两个方案。

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

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

对 HTTPS 的域名经过 CNAME 绑定到另一个 HTTPS 域名上

对 HTTPS 的域名经过 CNAME 绑定到另一个 HTTPS 域名上，这个状况下，须要两个证书，由于每一个证书跟本身的域名进行绑定，即便它们都在同一个服务器上，也不能使用同一个证书。

两台服务器的证书问题

由于安全问题，CA 证书部署在一台服务器上面，可是业务系统部署在另一台服务器上面，这种状况就比较难办。此时，须要借助 Nginx 进行反向代理，回源到具体的服务器。

HTTPS 设计上的借鉴

对称加密算法能够将敏感的信息在通讯过程当中经过 DES 或 AES 进行加密传输，而后在客户端和服务端直接进行解密。可是，将密钥编码在代码中存在安全隐患，由于密钥可能会泄漏。所以，更安全的作法是将密钥保存在数据库中，由服务端的接口下发密钥，在使用时由客户端获取密钥并加载进内存，而且经过非对称加密算法保证密钥在通讯过程当中的安全交换。实际上，这个通讯流程能够借鉴 HTTPS 协议的流程，将对称加密算法与非对称加密算法的优点相结合。其中，使用对称加密算法对通讯内容进行快速加密，从而弥补了非对称加密算法处理速度慢的问题，并保证通讯内容的机密性。同时，使用非对称加密算法将对称加密算法的密钥进行加密，保证对称加密算法的密钥的安全交换。

这里，介绍一个文件加密与解密的真实案例。需求场景是为了防止平台资源被第三方抓取，所以须要对平台的资源进行加密，而且只能用于平台的客户端使用。为了更好地理解整个通讯流程，先来观察一下加密的通讯步骤。

第一步，客户端 SDK 使用 RSA 加密算法，生成一对公私钥，或者称之为加密密钥与解密密钥。

第二步，客户端 SDK 向服务端请求 AES 密钥，由于密钥保存在服务器的数据库中，由服务端的接口下发密钥。其中，请求参数包括资源 ID 与 RSA 加密算法的公钥。

第三步，服务端使用客户端 SDK请求参数中的资源 ID，生成一个 AES 密钥，并保存到数据库中。

第四步，服务端使用客户端 SDK请求参数中的 RSA 加密算法的公钥，加密AES 密钥。

第五步，服务器发送给客户端 SDK加密后的 AES 密钥。

第六步，客户端 SDK 使用RSA 加密算法的私钥解密，获取到真正的 AES 密钥。

第七步，客户端 SDK 使用真正的 AES 密钥对资源文件进行加密。

理解了资源文件的加密的通讯流程，再来观察一下解密的通讯步骤。

与资源文件的加密的通讯流程相似，客户端 SDK 使用 RSA 加密算法，生成一对公私钥，客户端 SDK 向服务端请求 AES 密钥，服务端使用客户端 SDK请求参数中的资源 ID 查询 AES 密钥，服务端使用客户端 SDK请求参数中的 RSA 加密算法的公钥，加密AES 密钥，而且服务器发送给客户端 SDK加密后的 AES 密钥，客户端 SDK 使用RSA 加密算法的私钥解密，获取到真正的 AES 密钥，最后，客户端 SDK 使用真正的 AES 密钥对资源文件进行解密。

HTTPS 降级攻击的场景剖析与解决之道

HTTPS 必定安全么

HTTP 协议没有加密机制，通讯内容是明文传输的，没有通过任何安全处理。所以，为了解决窃听、篡改、冒充等风险，采用 HTTPS 协议。HTTPS 能够进行通讯内容加密，使第三方没法窃听。HTTPS 能够进行身份认证，一旦通讯内容被篡改，通讯双方会马上发现。此外，HTTPS 能够保证通讯内容的完整性，防止通讯内容冒充或者篡改。那么，使用了 HTTPS 就能确保通讯内容的安全传输吗？理论上，是这样的，可是事实上，现实却不是如此，由于设计与实现 SSL/TLS 协议出现了漏洞，致使攻击者一样能够攻击一些旧版本的 SSL/TLS 协议。这其中就包括 SSL 3.0。

什么是 HTTPS 降级攻击

由于浏览器的兼容性问题，当浏览器进行 HTTPS 链接失败的时候，将会尝试使用旧的协议版本，因而加密协议由更加安全的协议，好比 TLS 1.2 降级成 SSL 3.0。所以，在 HTTPS 降级攻击中，攻击者利用旧版本的 SSL/TLS 协议的漏洞，其中包括 SSL 3.0 的漏洞，而后攻击者获取安全链接当中某些能够降级成 SSL 3.0 的加密后的明文的通讯内容进行攻击。

注意的是，若是服务器支持 SSL 3.0 协议，同时，攻击者又能做为中间人控制浏览器发起漏洞版本的 HTTPS 请求，此时，虽然攻击者窃听到加密的通讯内容，但加密的协议存在漏洞，能够进行降级攻击，解密这些加密的通讯内容能够获取有价值的信息，例如用户的隐私数据。

HTTPS 降级攻击的解决之道

目前，解决 HTTPS 降级攻击的惟一方法是禁用 SSL 3.0 协议，并防止 TLS 1.2 协议、 TLS 1.1 协议与 TLS 1.0 协议降级到 SSL 3.0 协议。其中，禁用 SSL 3.0 协议的策略有不少，这里主要介绍下 Nginx 如何防止 TLS 1.2 协议、 TLS 1.1 协议与 TLS 1.0 协议降级到 SSL 3.0 协议如下版本，从而防止 HTTPS 降级攻击。

Nginx 原先的配置，以下所示。此时，若是 Nginx 原先的配置没有额外的配置，那么在 Nginx 中隐性默认是 SSLv3 TLSv1 TLSv1.1 TLSv1.2。

ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2;复制代码

Nginx 禁用 SSL 3.0 协议，并防止 TLS 1.2 协议、 TLS 1.1 协议与 TLS 1.0 协议降级到 SSL 3.0 协议的配置很是简单，只须要屏蔽 SSLv3 参数便可，以下所示。

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;复制代码

总结下，HTTPS 能确保通讯内容的安全传输吗？答案是不必定，由于设计与实现 SSL/TLS 协议出现了漏洞，致使攻击者一样能够攻击一些旧版本的 SSL/TLS 协议，其中就包括 SSL 3.0，可能会被攻击者进行 HTTPS 的降级攻击。所以，SSL 3.0 协议并不安全，为了防止 HTTPS 的降级攻击，须要禁用 SSL 3.0 协议，确保TLS 1.2 协议、 TLS 1.1 协议与 TLS 1.0 协议降级到 SSL 3.0 协议如下版本。

（完）

更多精彩文章，尽在「服务端思惟」微信公众号！