HTTPS 互联网世界的安全基础

近一年公司在努力推动全站的 HTTPS 化，做为负责应用系统的咱们，在配合这个趋势的过程当中，顺便也就想去搞清楚 HTTP 后面的这个 S 究竟是个什么含义？有什么做用？带来了哪些影响？毕竟之前也就只是模糊的知道大概是更安全，但到底怎么变得更安全的，实际上整个细节和流程并无掌握的特别清晰。

因此这篇关于 HTTPS 的技术总结文章，主要提供一个关于 HTTPS 中的 S 一个总体的认识。从其产生的历史背景、设计目标提及，到分析其协议设计结构、交互流程是如何实现其目标。最后结合咱们本身的案例分析下其中带来的影响。

下面咱们就先从其诞生之初提及吧。

历史

S 表明 Secure，因此 HTTPS 天然就是更安全的 HTTP 的意思。互联网诞生之初 SSL（Secure Sockets Layer 安全套接层）是由 Netscape 这家最先的浏览器公司设计的，主要是用于 Web 的安全传输的协议，这种协议在早期 Web 上得到了普遍的应用。后来被 IETF 标准化造成了 TLS（Transport Layer Security 传输层安全）标准，其历史以下：

• 1994: SSL1.0，由于存在严重的安全漏洞，未发布。
• 1995: SSL2.0，这个版本因为设计缺陷，很快被发现有严重漏洞，被废弃。
• 1996: SSL3.0，从新设计并开始流行，SSL 前三个版本都是由 Netscape 设计实现。
• 1999: TLS1.0，IETF 将 SSL 标准化，即 RFC 2246。
• 2006: TLS1.1，做为 RFC 4346 发布。
• 2008: TLS1.2，做为 RFC 5246 发布 。
• 2015: TLS1.3，尚在制定中，处于草案阶段。

如上，如今互联网世界使用最普遍的应该是 TLS1.2 标准。

目标

SSL/TLS 最初的设计目标就是为了实现下面三个目的：

• 保密：第三方没法窃听。
• 完整：没法篡改。
• 认证：防止身份冒充。

互联网是一个开放的环境，十分复杂。网上两端通讯的双方彼此都不知道谁是谁，双方如何信任、信息如何保密，如何不被篡改，这是十分复杂的问题。并且互联网自己就像有生命通常在不断进化，如何设计一个协议来应对将来可能的变化，于是这使得 SSL/TLS 协议的设计十分复杂。

结构

咱们知道整个互联网构建于 TCP/IP 协议栈基础之上，在描述协议设计细节以前，咱们先看看 SSL/TLS 协议处于该分层协议栈结构中的位置，其分层结构位置参考以下：

交互

SSL/TLS 协议设计之初就考虑了互联网和安全算法生命周期的演变，因此设计了一个算法协商握手流程，容许将来随着新安全算法的诞生能够灵活的加入到协议中，这就是典型的软件可扩展性设计的范例。下面是协议握手流程：

握手的目的简单归纳就是：通讯双方协商出一套会话密钥，而后基于此密钥经过对称加密方式来安全通讯。

Client Hello

握手交互流程，首先由 Client 端发起 ClientHello 请求。在这个请求中 Client 端向 Server 端提供以下信息：

• SSL version : 本身支持的最高协议版本，好比 TLS1.2。
• Ciphers : 支持的加密套件，好比： RSA 非对称加密算法，AES 对称加密算法。
• Random number: Client 端随机数，将会用来生成会话密钥。

Server Hello

Server 收到 ClientHello 请求后须要回应一系列内容，从 ServerHello 到 ServerHelloDone，有些服务端的实现是每条单独发送，有些服务端实现是合并到一块儿发送。

ServerHello
根据 Client 端的请求信息确认使用的协议版本和加密套件（Cipher Suite），和客户端一致，并生成一个 Server 端随机数，用来生成会话密钥。

Certificate
Server 端用于证实自身身份的凭证，一种由专门的数字证书认证机构（Certificate Authority 简称 CA）经过很是严格的审核以后颁发的电子证书，由 Client 端去认证 Server 端的合法身份。

ServerKeyExchange
可选的，补充生成会话密钥的信息。对于前面协商的有些加密算法若 Certificate 未提供足够的信息或就没有 Certificate 那么须要发送该消息。进一步的细节咱们就不深刻了，能够查看参考[1]。

CertificateRequest
可选的，Server 端须要认证 Client 端身份的请求时发送。好比，银行提供的各种 U 盾，其实就是一种 Client 证书，通常在线使用专业版网银时才须要。

ServerHelloDone
表示 Server 响应结束。

Client Finished

Client 收到 Server 回应后，首先验证 Server 的证书。若是证书不是可信机构颁布、或者证书中的域名与实际域名不一致、或者证书已通过期，就会向访问者显示一个警告，由其选择是否还要继续通讯。若是证书没有问题，Client 会继续回应 Server，包括以下内容：

Certificate
Client 端响应 Server 的 CertificateRequest 请求。

ClientKeyExchange
Client 再生成一个随机数，又称 premaster secret 用于生成会话密钥的信息，并把这个随机数传递给 Server 用于 Server 生成相同的会话密钥。

CertificateVerify
用于对客户端证书提供证实，对于特定的证书须要可选发送。

ChangeCipherSpec
用于告知 Server，Client 已经切换到以前协商好的加密套件（Cipher Suite）的状态，准备使用以前协商好的加密套件和会话密钥加密数据并传输了。

Finished
Client 会使用以前协商好的加密套件和会话密钥加密一段 Finished 的数据传送给 Server，此数据是为了在正式传输应用数据以前对刚刚握手创建起来的加解密通道进行验证。

Server Finished

Server 在接收到客户端传过来的 premaster secret 数据以后，也会使用跟 Client 一样的方式生成会话密钥。一切就绪后，服务端回应以下内容：

NewSessionTicket
表示新建了一个会话票据，传递给 Client。若链接意外中断 Client 须要重建会话时，能够复用该票据，加速握手过程。

ChangeCipherSpec
告知 Client 已经切换到协商过的加密套件状态，准备使用加密套件和会话密钥加密数据并传输了。

Finished
Server 会使用以前协商好的加密套件和会话密钥加密一段 Finished 的数据传送给 Client，此数据是为了在正式传输应用数据以前对刚刚握手创建起来的加解密通道进行验证。

至此，整个握手阶段所有结束。接下来 Client 和 Server 进入使用会话密钥的加密通讯过程。

认证

前面说起证书验证部分属于 SSL/TLS 协议中比较复杂的部分，咱们单独用一节分析下。证书是由 CA 签发的，因此要验证证书的有效性须要去 CA 的服务器，流程以下。

在线证书状态验证采用了 OCSP（Online Certificate Status Protocol 在线证书状态协议）协议去验证。但若是按上面这个方式，那 HTTPS 就慢死了，不实用，因此有了 OCSP stapling 方式，其流程以下：

Server 端会按期去 CA 同步一份通过 CA 认证签名的证书状态检查结果并伴随 ClientHello 响应返回给 Client 端。由于这个结果是 CA 本身经过数字签名，Server 也没法伪造或篡改，所以 Client 能够信任这个结果，以达到减小没必要要的步骤提高性能的效果。

另外，证书根据其认证类型可分为三类：

Domain Validation
DV 证书用于验证一个或多个域名的全部权，无需递交纸质文件，仅验证域名管理权，无需人工验证申请单位真实身份。

Organization Validation
OV 证书用于验证此域名由特定组织或单位所拥有的域名。申请此类证书，经过证书颁发机构审查网站企业身份和域名全部权以证实申请单位是一个合法存在的真实实体，CA 机构将在人工核实后签发证书。

Extended Validation
EV 证书是目前最高信任级别的证书。经过极其严格甚至苛刻审查网站企业身份和域名全部权，确保网站身份的真实可靠。

咱们常常经过浏览器访问一些安全级别比较高的网站时，都是基于 HTTPS 协议，这时浏览器会显示一个绿色的「锁型」标记，让咱们心理感到放心，好比下图所示几个例子：

招行

支付宝

GitHub

上面三个图，分别来自招商银行、支付宝和 GitHub，看出它们的证书和加密套件的区别没？其中招行和 GitHub 都是采用的 EV 证书，因此浏览器地址栏显示了企业名称，而支付宝采用的是 OV 证书所以没有。另外招行的 TLS 协议是 1.0 版本，这是一个有已知安全漏洞的版本，浏览器提示了过期的链接安全设置。而支付宝采用的加密套件被提示属于过期的（强度不是最高的，但没有已知的安全漏洞），GitHub 采用的则应该是目前最推荐的安全加密算法套件：TLS1.2（协议版本） + ECDHE_RSA（密钥协商交换） + AES_128_GCM（对称加密）。

另外，SSL/TLS 协议中比较复杂的部分是关于加密套件的，这块基本属于密码学背后的数学原理部分。通常码农基本搞不懂（我也搞不懂），对于咱们来讲大概只须要搞清楚对称加密、非对称加密、HASH 算法的区别和时间开销。在选择密码套件时知道哪类是哪类，跟上主流的选择就好了。

案例

讲完 SSL/TLS 的基本原理和交互流程，就以我所在的 IM 项目为例，这里同时涉及 HTTP + S 和 TCP + S。HTTP 属于全公司一块儿加 S，那就加在统一的负载均衡层，也就是 HAProxy 那里，对总体应用无影响（参见下面部署结构图）。而 IM 客户端应用也能够间接经过 HTTPS 前置请求得到对服务端的认证，而后选择接入服务器创建 TCP 长链接。TCP 长链接实际只须要作加密保护，再也不须要二次认证。

一开始，咱们是在本身的接入应用中，基于 JDK 的 SSL 库实现的 TCP + S，可是发如今高并发压力下发现性能衰退的厉害，后来便改为了使用 Nginx 前置接入的方式。对比性能测试以下所示：

能够看出引入 SSL 后确实带来了一些性能开销，不过总体不大。

总结

至此，咱们基本把 HTTPS 涉及的 SSL/TLS 相关的内容总体而粗浅的探讨了一番，至于更细节的一些内容，你们如有兴趣能够去看 RFC 和下面的一些参考资料。

参考

[1] byronhe TLS协议分析与现代加密通讯协议设计. 2015.09
[2] Baidu 全站HTTPS时代的号角：大型网站的HTTPS实践系列. 2015.04
[3] seanlook SSL/TLS原理详解. 2015.1
[4] 阮一峰 SSL/TLS协议运行机制的概述. 2014.2
[5] MaxCDN What is OCSP Stapling?

...

呼～～～，终于写完了，写技术文章真得好花时间啊。

---

写点文字，画点画儿。
微信公众号「瞬息之间」，碰见了不妨就关注看看。