勒索病毒无耻？你一定没见过运营商的嘴脸！技术人必备生存技能

[[192336]]

近日，席卷全球的勒索病毒再次被发现新的变种，新的病毒将利用Windows操作系统中的漏洞，通过加密后的重命名文件来感染计算机，这让已经平息的风波再起一丝波澜。

[[192337]]

人们纷纷指责勒索者的无耻行为，竟然利用操作系统漏洞搜刮上百万美元，但是这些在「中国特色」的网络安全环境下，也是小巫见大巫了，因为那些运营商层出不穷的各种劫持给所有的用户和开发者都上了生动的一课。

[[192338]]

用户每天被来自各种广告联盟漫天的牛皮癣广告和运营商话费余额查询所包围。不仅如此，随着公司流量不断的被劫持导流到其他地方，搞得很多公司连苦心经营的市场蛋糕都没办法安心的吃。

终于大部分公司坐不住了，开始对运营商进行了声讨和口诛笔伐。

当然这些病没有用的，所以拥有业务上拥有 HTTPS 和 HTTP DNS 解决方案，也就顺理成章的成了技术公司在伟大防火墙内生存的必备技能之一。

另一方面，从安全角度讲，互联网上通过明文传输数据本身就是一件高风险的事情，什么数据泄露、中间人攻击、用户被盗号、被竞争对手背后捅刀子 App 下载被劫持…..也是屡见不鲜。

[[192339]]

既然 HTTPS 可以一劳永逸的解决上述问题，而为什么大家之前不尽快的用起来?

问题在于：考虑到 HTTPS 要比 HTTP 更加消耗服务器资源，而且相比于 HTTP 建立连接握手时需要消耗的大量时间影响用户端的体验，使得很多人望而却步，尤其是在移动网络下。

当然，还有 SSL 证书的成本也要算进去。

在 Web 领域，传输延迟(Transmission Latency)是 Web 性能的重要指标之一，低延迟意味着更流畅的页面加载以及更快的 API 响应速度。而一个完整的 HTTPS 链接的建立大概需要以下四步：

第一步：DNS 查询

浏览器在建立链接之前，需要将域名转换为互联网 IP 地址。一般默认是由你的 ISP DNS提供解析。ISP 通常都会有缓存的，一般来说花费在这部分的时间很少。

第二步：TCP 握手( 1 RTT)

和服务器建立 TCP 连接，客户端向服务器发送 SYN 包，服务端返回确认的 ACK 包，这会花费一个往返(1 RTT)

第三步：TLS 握手 (2 RTT)

该部分客户端会和服务器交换密钥，同时设置加密链接，对于 TLS 1.2 或者更早的版本，这步需要 2 个 RTT

第四步：建立 HTTP 连接(1 RTT)

一旦 TLS 连接建立，浏览器就会通过该连接发送加密过的 HTTP 请求。

我们假设 DNS 的查询时间忽略不计，那么从开始到建立一个完整的 HTTPS 连接大概一共需要 4 个 RTT。

[[192340]]

几天前，OpenSSL 官方宣布即将发布的新版本 (OpenSSL 1.1.1) 将会提供 TLS 1.3 的支持，而且还会和之前的 1.1.0 版本完全兼容，这当然是个好消息。如果说 HTTP/2 是当前互联网 Web 发展的讨论热点之一，那么下一个热点应该就是 TLS 1.3 了。

那么 TLS 1.3 以及 0-RTT 是能减少延迟吗?先来看一下 TLS 1.2 是如何工作的。

TLS 1.2 建立新连接

1. 在一次新的握手流程中，Client Hello 总是客户端发送的第一条消息，该消息包含客户端的功能和首选项，与此同时客户端也会将本身支持的所有密码套件(Cipher Suite)列表发送过去
2. Server Hello 将服务器选择的连接参数传送回客户端，同时将证书链发送过去，进行服务器的密钥交换
3. 进行客户端部分的密钥交换，此时握手已经完成，加密连接已经可以使用
4. 客户端建立 HTTP 连接

TLS 1.2 会话恢复

会话恢复：

在一次完整协商的连接断开时，客户端和服务器都会将会话的安全参数保留一段时间。希望使用会话恢复的服务器会为会话指定唯一的标识，称为会话 ID。

1. 希望恢复会话的客户端将相应的会话 ID 放入 ClientHello 消息中，提交给服务器
2. 服务器如果愿意恢复会话，将相同的会话 ID 放入 Server Hello 消息返回，使用之前协商的主密钥生成一套新密钥，切换到加密模式，发送完成信息
3. 客户端收到会话已恢复的消息，也进行相同的操作

终于进入重头戏，TLS 1.3 如何建立连接呢?

1. 在一次新的握手流程中，客户端不仅会发送 Client Hello 同时也会将支持的密码套件以及客户端密钥发送给服务端，相比于上个版本 TLS1.2，该步骤已经节约了一个 RTT
2. 服务端发送 Server Hello ，服务端密钥和证书
3. 客户端接收服务端发过来的信息，使用服务端密钥，同时检查证书完整性，此时加密连接已经建立可以发送 HTTP 请求，整个过程仅仅一个 RTT

TLS 1.3 0-RTT 会话恢复

TLS 1.2 中通过 1 个 RTT 即可完成会话恢复，那么 TLS 1.3 是如何做到 0 RTT 连接的?

当一个支持 TLS 1.3 的客户端连接到同样支持 TLS 1.3 的服务器时， 客户端会将收到服务器发送过来的 Ticket 通过相关计算，一起组成新的 预共享密钥，PSK (PreSharedKey)。客户端会将该 PSK 缓存在本地，在会话恢复时在 Client Hello 上带上 PSK 扩展，同时通过之前客户端发送的完成(finished)计算出恢复密钥 (Resumption Secret)通过该密钥加密数据发送给服务器。服务器会从会话 Ticket 中算出 PSK，使用它来解密刚才发过来的加密数据。

至此完成了该 0-RTT 会话恢复的过程。

以上简单描述了 TLS 1.3 建立连接的大致流程，也解释了为什么 TLS 1.3 相比于之前的 TLS 1.2 会有更出色的性能表现。

当然 TLS 1.3 还有非常非常多的细节以及安全特性，优点以及缺点(去除静态 RSA 和 DH 密钥协商、禁止 RC4、有副作用的 0-RTT 握手存在重放攻击，不支持前向保密…..)，限于篇幅并没有更深入的去探讨。

总结

TLS 1.3 将是 Web 性能以及安全的一个新的里程碑，随之 TLS1.3 带来的 0-RTT 握手，淡化了大家之前对使用 HTTPS 性能上的隐忧。于此同时，在未来随着 HTTP/2 的不断普及，强制性使用 HTTPS 成为了一种必然。