当今互联网世界安全形势严峻，内容篡改、流量劫持、个人隐私信息泄露等事件层出不穷。为让广大用户可以更安全的使用互联网服务，加密流量的应用越来越广泛，其地位也日益重要。在互联网领域，使用多的流量加密技术就是HTTPS。如今互联网正在经历从明文（HTTP）到加密（HTTPS）的转变。

HTTPS使互联网环境更安全的同时，也带来了很多额外挑战，例如：加密运算消耗更多的CPU资源，这意味着服务器端需要增加更多的硬件（一般而言，HTTPS的硬件成本是同性能HTTP服务的3倍以上）；而在移动客户端，如手机、平板电脑等环境中，这则意味着消耗更多电池电量。此外，HTTPS在握手阶段引入额外RTT，加上加解密运算的额外时间开销，增加了HTTP请求的时延，极大的影响了用户体验。

为应对上述挑战，HTTPS尚需功能升级，白山研发团队率先进行尝试，新增：TLS1.3协议、RSA多素数支持、ChaCha20算法支持及HTTPS可视化运营等特性，具体如下图：

一、TLS 1.3协议——更低时延、更安全

TLS 1.3协议依循极简主义的设计哲学，祛除并修复了旧版本中的坏味道，将密钥交换、对称加解密、压缩等环节中可能存在的安全隐患剔除出该版本，包括：

• TLS 1.3协议中选取的密钥交换算法均支持前向安全性，废除了RSA秘钥交换和静态DH密钥交换等不支持前向安全性的算法；
• DSA证书作为历史遗留产物，尚未被大规模使用过，加之安全性较差，故在TLS 1.3协议中被废弃；
• 禁用自定义的DH组参数，防止受到Key Recovery Attack攻击；
• 禁用CBC模式，经实践证明这种对称加密模式尚存在安全隐患；
• 禁用RC4流加密算法： 2013年，英国皇家哈洛威学院的研究人员发现一种针对TLS的攻击，可从RC4算法加密的密文中恢复出少量明文；
• 禁用SHA1摘要算法：2017年初Google与荷兰研究机构CWI Amsterdam共同宣布已破解SHA1；
• 禁用出口密码套件： 2000年美国放宽密码出口管制，随后出现的FREAK和LogJam攻击，可以通过中间人将加密套件降级成出口套件，进而将数据破解；
• 禁用TLS压缩：TLS压缩存在安全漏洞，攻击者通过漏洞可以实行会话劫持并发动进一步攻击；
• 加密握手消息： TLS1.3协议规定在ServerHello消息后的握手信息需要加密。TLS1.2及之前版本的协议中各种扩展信息在ServerHello中以明文方式发送，在新版本中可在加密之后封装到EncryptedExtension消息中，在ServerHello消息后发送，增加数据安全性。

HTTPS提高网络安全的同时也增加了额外的性能消耗，如：额外的SSL握手交互过程，数据加解密对CPU的消耗等。TLS 1.3在提高效率方面进行了大量改进，特别是对SSL握手过程重新设计，将握手的交互延时从2-RTT降低为1-RTT甚至是0-RTT。在网络环境较差或节点距离较远的情况下，这种优化可节省几百毫秒的时间。这几百毫秒就能决定用户下一步的行为是继续浏览还是关闭。性能提升包括：

• 1-RTT握手机制：以ECDHE密钥交换过程为例，握手过程如下。将客户端发送ECDH临时公钥的过程提前至ClientHello ，同时删除ChangeCipherSpec协议简化握手过程，使次握手只需要一个RTT。

• 0-RTT握手机制：为使TLS协议性能得到极致提升，TLS 1.3提出了0-RTT的握手机制。对于用户近访问过的网站，可在次交互时就向服务器发送加密数据。具体实现过程如下：客户端和服务端通过TLS session复用或外部输入的方式共享PSK，这种情况下允许客户端在次交互的ClientHello消息中包含使用PSK加密的应用数据。

为展现更加直观的效果，白山搭建了支持TLS 1.3协议的服务器。

对应当前主流浏览器支持的draft-18的服务器：https://tls13.baishancloud.com/

对应新的draft-21版本的服务器：https://tls13.baishancloud.com:44344

二、RSA多素数——更快、更稳定

简单来说，多素数RSA是指在生成RSA密钥的时候，在计算固定长度（比如2048位或者4096位）的模数（modulus）的时候，选择多于2个素数并进行相乘得到终期望长度的modulus。也就是说，n = pq 这种标准RSA的计算方式n = pq ，在多素数RSA中，会变成 n = r1r2r3r4r5… 的形式。这也是多素数（multi-prime RSA）这个名字的由来。

这样做的好处是可以大幅提高RSA私钥计算性能（降低握手时间，减轻服务器压力），具体数据见下图：

由上可知，多素数RSA具备三个特点：

• 素数个数越多，单个RSA私钥运算所需时间越短，整体性能越高，其中： 
  
  • 3素数相对标准RSA提高25%
  • 5素数提高230%
  • 8素数提高310%
  • 15素数提高近400%
• 素数个数越多，RSA密钥生成时间越短
• 素数个数越多，安全强度越差，私钥被破解的可能性越高

多素数RSA大优势在于作为一种不需要使用硬件加速卡的低成本方案，可以在某些安全性要求不高的场景下发挥作用。例如：静态图片对安全强度的要求不如动态数据大，可考虑采用多素数RSA方案。

当前OpenSSL对多素数RSA并不支持，白山基于RFC 8017在OpenSSL中实现多素数RSA功能，并将其开源，开源代码位于：https://github.com/openssl/openssl/pull/4241 目前正向OpenSSL官方合并代码，有望纳入OpenSSL 1.1.1版本的发布。

三、ChaCha20算法——更省电

ChaCha20是Google大力推广的一种对称加密算法，用于解决不支持AES硬件加速指令的Android设备的HTTPS性能问题。Google在其Chrome浏览器中增加了对这一算法的支持，同时还支持Poly1305摘要算法，形成了ChaCha20-Poly1305组合，并在2015年和2016年将这组算法标准化，形成RFC 7539和RFC 7905两篇RFC文档。

在对称加密领域，自从AES算法从性能上超越并取代3DES算法，成为NIST指定的加密算法后，再未出现其他广泛使用并且兼顾性能和安全的对称加密算法。这带来了以下几个问题：

1. 未来如果AES被发现存在问题，人们将不得不退而使用老旧的3DES算法，因此业界需要一个备选算法；
2. 在不支持AES硬件加速指令的设备上，AES算法的性能不具备明显优势（尤其是和某些流加密算法相比）；
3. AES如果实现的不正确，可能存在缓存碰撞时序攻击（AES Cache-Collision Timing Attack）。

而ChaCha20可以较好的解决上述问题。

ChaCha20是一种流加密算法，实现较为简单，并且比纯软件实现的AES性能更好。

性能对比

上图是在不使用AES硬件加速的情况下，对AES和ChaCha20进行的性能对比测试。其中ChaCha20性能是GCM模式AES256的5倍左右。

将ChaCha20同已经濒临灭绝的RC4算法进行了对比，同为流加密算法，ChaCha20的性能达到了RC4的2倍之多。单位时间内运算次数的提高，表示单次操作所需的指令周期更短，而在移动端设备上这种特点直接影响电池电量的消耗。

虽然在HTTPS的场景中，一次全握手产生的功耗要远大于对称加密环节产生的，但是在针对大文件加密、解密操作时，更快的对称加密算法依然存在实际应用价值。

但如果设备已经支持AES硬件加速指令，例如iPhone和部分Android系统手机或支持AES-NI指令的Intel CPU等，AES的速度依然具有绝对优势：

由上图可见，其性能约为ChaCha20的3倍左右，此外GCM模式的AES比CBC模式在有硬件加速的情况下性能提升的更大，这主要是由于GCM模式可以比CBC模式能更好利用硬件流水线进行并发。

HTTPS服务全面支持ChaCha20-Poly1305算法，可以同时采用自动适应客户端算法列表的处理手段：

1. 如果客户端不支持AES硬件加速指令，则优先使用ChaCha20
2. 否则按照服务器的算法优先级顺序选择AES算法

目前白山支持的TLS加密套件有：

1. TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
2. TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
3. TLS_CHACHA20_POLY1305_SHA256 (TLSv1.3用）

结合以上ChaCha20的性能对比，可以认为该算法适合在不支持AES硬件加速的Android平台中使用。因此作为应用程序，好可以判断当前运行的平台是否支持AES指令。如不支持，则将上述TLS加密套件排列在客户端ClientHello消息中前的位置（根据支持的协议），根据客户端支持的加密套件列表选择优算法来和客户端握手。在支持AES指令的硬件平台上，推荐优先选择AES-GCM算法；而CBC模式的RSA和RC4算法在很多情况下并非好选择，应当尽量避免过多使用。

四、HTTPS可视化运营——更直观

HTTPS的数字化运营在HTTPS服务的质量监控、服务优化等方面有着举足轻重的作用。

目前白山数字化运营平台对主要关注如下几点：

• HTTPS请求数：可直接观察当前网站的活跃程度，提供用户行为的参考依据；
• HTTPS握手时间统计： 透明化展示握手阶段的时间消耗，同时增加对该耗时的监控，握手时间超过阈值时能快速感知并处理，大程度保障用户体验；
• HTTPS握手复用率统计：复用表示客户端可直接复用上次与服务端协商得到的密钥。复用率高则表示HTTPS的握手阶段消耗低；当复用率处于较低的水平时，则需要及时调整复用策略；
• 协议分布（主要指SSL/TLS的协议版本）：通过大数据分析得到协议分布情况。大量客户端使用低版本协议发起请求可能意味着异常情况。 
  为提供更好的HTTPS服务，还需关注更加细致的状态参数：
• 加密算法分布：HTTPS服务质量一定程度上取决于加密算法的性能，通过对加密算法统计分析，可有效指导算法优化。例如：90%以上的HTTPS握手会使用RSA算法，白山针对该算法开发多素数RSA功能，并提交到OpenSSL社区，提高了RSA算法效率；
• 客户端分布：不同客户端可能针对不同算法有相应的优化，例如ChaCha20在不支持AES硬件加速的Android平台中有比较好的性能，可根据客户端分布情况预判该算法优化效果。另外当产生新的安全漏洞，需要升级或废弃SSL/TLS的某些特性时，需要综合该信息判断影响范围。例如：某些特性的停用会导致部分旧版本客户端无法访问，就可以通过分析这类客户端占比来决定如何处理。

以下是可视化运营平台截图：