HTTPS入门, 图解SSL从回车到握手

对于WEB应用启用https很多人有个误区，会认为全站https挺慢了整个WEB应用的速度，本文作者@蓝小灰通过浅显的表达和实例对SSL/TLS从访问到握手到成功建立通信的整个过程以及其中对于性能和效率影响作了详细的阐述，本文经@蓝小灰授权转载：HTTPs入门, 图解SSL从回车到握手，以下是原文

Multithumb found errors on this page:

There was a problem loading image 'https://pic7.zhimg.com/v2-6b00585f27b65122cc3e5081a4df6e7a_b.jpg'

v2 d9ccfe7a6bd42af62130dbe50b9990e8 r

大家在网络冲浪时，在访问一些涉及金融/支付/登录/后台等敏感业务时，会发现这些网站都会重定向到 https:// 的 URL ，例如：

地址为绿色，表示安全且可信任;
地址为红色，则表示虽然开启了加密，但网站身份未验证，无法保证不被中间人嗅探.

从我们在地址栏敲下 https:// 网站那一刹那，到内容显示到我们面前，中间经过了哪些过程了? 浏览器根据什么来判断，当前网站网址是安全的还是未验证的? 这篇文章可帮助你了解到这些。考虑到个人知识所限，难免有遗漏或错误之处，如你有发现，请在下面留言指出（原文知乎专栏中）。

图示：

讲解：

1、Client-hello 阶段

浏览器中完成地址输入后，解析域名获得 IP Host 地址，浏览器会与此 Host 的443(默认，如果指定其他端口则会连接此端口) 尝试连接，也就是 TLS 握手协议的 Client-hello，上图的第一步。
浏览器会将"支持的加密组件"/"尝试连接到Host头"等信息发送给服务器，并会附上一份随机生成的 session ticket1。

2、Server-hello 阶段

服务器收到浏览器发送来的 TLS 握手请求后，存储浏览器发送的session ticket2，然后根据发送来的 host 寻找对于的服务器证书，然后会将服务器证书，服务器与浏览器妥协(均支持)的加密套件方法，和一份随机生成的 session ticket 返回给浏览器.

3、Cipher-spec 阶段

浏览器收到服务器返回的证书后，会验证证书有效性。验证步骤大概如下：

验证证书有效期(起止时间)
验证证书域名(与浏览器地址栏中域名是否匹配)
验证证书吊销状态(CRL+OCSP)， [见本文后"吊销检查"章节]。
验证证书颁发机构，如果颁发机构是中间证书，在验证中间证书的有效期/颁发机构/吊销状态。一直验证到最后一层证书，如果最后一层证书是在操作系统或浏览器内置，那么就是可信的，否则就是自签名。[见本文后"签发者"章节]

以上验证步骤，需要全部通过，否则就会显示警告。

若检查通过，随机生成一份 session ticket 3 (这是浏览器生成的第二份 ticket)，通过返回证书中的公钥，用协商的"秘钥交换算法"加密，返回给服务器。

同时浏览器用 session ticket 1(浏) & session ticket 2(服) & session ticket 3(浏) 组合成 session key。

服务器收到 Ciper-spec 后，用配置的私钥，解密出 session ticket3，用 session ticket 1(浏) & session ticket 2(服) & session ticket 3(浏) 组合成 session key。

此处不难得知，服务器与浏览器交换的最终秘钥， session key全等且未泄露(session ticket 1 和 session ticket 2可以抓包，但session ticket 3是无法窃听的)。

为什么session ticket 3无法窃听？

有个 webtrust 组织，专门负责备案世界上各国商业与政府官方 CA 机构的公钥证书。如果审计通过，其他浏览器及操作系统/客户端才允许加入信任列表。否则是不允许加入的。如果中间人拦截了 session ticket 3 的响应密文，没有私钥，中间攻击人是解密不了的。而要想拿到私钥，攻击人可以做到，就是在客户端和服务器中间搭建代理，替换掉 SSL 证书，以实现服务器返回证书时候中间替换自己的，从而在中间拦截服务器和客户端两头的通信。

但是如果这样做，浏览器和客户端会显示非信任的颁发者，如下图 chrome 和 curl 命令行下分别警告：

4、内容传输阶段

至此， TLS 连接建立完成，在连接销毁前，浏览器与服务器彼此数据均通过 session key 来进行对称加密。

通过上述过程，其实是别有用心的，因为非对称加密非常消耗 CPU。所以只有在协商秘钥时候使用非对称加密，而应用层数据交换就用协商成功的秘钥作为私钥对称加密传输(服务器响应的加密返回，客户端提交的也加密提交)。

吊销检查：

目前写进国际标准的吊销状态检查协议有两种：1.CRL， 2。OCSP

CRL 是一份全量的文件，记录了被此 CRL 限制的证书中所有被吊销证书的序列号。通过匹配当前证书序列号，与 CRL 中序列号，来判断。

有点绕，反正就说，所有打上了这个 URL 的 CRL 的证书，只要其中一个被吊销，那么下次 CRL 更新时，均会查询匹配到。
那么可不可以认为一个中间颁发机构颁发的证书的 CRL 列表只有一个? 不可以! 因为数量可能太多，厂商完全可以将同一个中间证书颁发的最终证书，分不同批打不同的 CRL。

而 OCSP 是 TCP 服务，通过请求证书序列号，服务器告知当前序列号是否在被吊销名单。

有的证书内置了 CRL+OCSP，有点只内置了 OCSP，还有的早起证书只内置了 CRL，但只内置 CRL 的证书是不被新型浏览器信任了。

请思考：

问：吊销状态检查，是同步的还是异步的?

答案：同步的。

如果异步检查，有可能会导致浏览器发送数据给了未验证的主机后，过了一段时间才检查出来证书已吊销。所以，必须同步。

签发者：

证书的签发者，通过以下步骤获得

1、服务器证书，如果包含了证书链，浏览器会尝试匹配(根据当前证书的"签发者公钥"匹配链中的后续证书的"公钥")，如果匹配失败，走2。

2、中如果有声明签发者 URL，浏览器尝试下载。并通过公钥匹配(同1)，如果匹配失败，走3

3、操作系统或客户端浏览器内置证书公钥匹配，如果匹配失败，则返回ERR_CERT_AUTORITY_INVALID。

4、附加项：如果任何一级证书，被声明了 oID，则会被浏览器显示成 EV(绿色地址栏带上公司名称)。

题外话：

问：HTTPS 是否会拖慢性能？

答案：看具体部署的情况。

浏览器在加密 session ticket3时，和服务器在接受浏览器返回 session ticket3时，是非对称加密中可能出现耗时的步骤。但这个步骤顶多几毫秒，并且现代化浏览器和 NGINX 已经支持 session 复用，造成的性能损耗几乎可以忽略不计。

而真正可能拖慢性能的，只可能是在吊销检查步骤中。

因为上面说了，吊销状态检查只能是同步的，那么受到 CA 厂商的部署限制，极可能会将 CRL 服务器和 OCSP 服务器部署在遥远的小机房，带宽/链路都是极差的，这种， DNS 解析和连接 CRL/OCSP 服务器均需要耗时，此过程的损耗，是一大批在知乎的所谓专家所言的加密解密过程损耗的数十倍到数百倍。

问：怎么规避吊销状态带来的损耗？

答案：仁者见仁，智者见智。这里给出两个建议

1、踩上大厂的顺风车。如百度阿里腾讯和苹果微软操作系统各种常见网站和软体的服务器/代码签名证书，均有 CRL 和 OCSP，而 CRL 是操作系统层复用的，只要在 TTL 时间内，操作系统检查过对应 CA 的 CRL，那么 CRL 均可避免二次下载，用户访问就可实现加速。OCSP 也至少可以搭上一个免去 DNS 解析的红利。例如 Symantec/GeoTrust/GlobalSign。

2、买国内 CA 的证书。我指的是真正自己在浏览器根证书的 CA 啊，不包括仅仅是中间证书分销商，也不包括前面被除名然后变成分销商的WoSign。

问：12306的证书部署，除了 CA 不受信任外，还有那些错误?

答：除了 CA 不受信任，还存在问题：

1、没有吊销状态声明，根据最新的 webtrust 标准，没有声明吊销状态的证书不受信任。

2、签名算法用了过期的 SHA-1。

文章来源：https://zhuanlan.zhihu.com/p/25587986

技术支持

图示：