对称加密算法优化之 ChaCha20-Poly1305 算法支持
前言
近几年，Google、Baidu、Facebook 等互联网巨头，不谋而合地开始大力推行 HTTPS，国内外的大型互联网公司很多也都已启用全站 HTTPS，这也是未来互联网发展的趋势；从 2017 年开始，Chrome 浏览器已把采用 HTTP 协议的网站标记为不安全网站，苹果 App Store 中的所有应用也都必须使用 HTTPS 加密连接。
又拍云积极推动 HTTPS 的普及，共建安全云生态，将互联网安全提升到一个新的高度。2017年初，又拍云相继推出了免费的 Let's Encrypt 和 TrustAsia 证书 ，并且和国际顶级 CA （包括：Symantec、GeoTrust）机构合作，提供 SSL 证书的申购、管理、部署等功能，操作流程简单方便，一键申购，与又拍云 CDN 服务完美结合，可为用户提供一站式 HTTPS 安全加速解决方案。
SSL 证书购买界面：
在推动 HTTPS 普及的同时，我们也不遗余力的对 HTTPS 性能 进行优化，寄希望于可以达到比未加密的 HTTP 协议更快的性能，前面章节我们也介绍了又拍云 HTTPS 优化之路，支持的特性包括：
- Session ID 复用
- OCSP Stapling
- HSTS
- HTTP/2
- False Start
以上特性的支持，极大的加快了 HTTPS 访问速度。HTTPS 网站的普及使得大家更加关注 HTTPS 的性能，之前的性能优化技术基本上都是针对 PC 端，并没有针对移动端设备进行专项优化。
今天，我们在此宣布，又拍云 CDN 已经支持 Google 推出的针对移动端优化的加密套件，也即 ChaCha20-Poly1305。又拍云平台上所有的 CDN 用户都可以享受到该算法带来的好处。接下来的章节将会围绕此算法来展开介绍。
对称加密算法 PK
在 TLS 握手的过程中，对称加密就是通过非对称加密算法得到的对称加密密钥。通俗的讲，就是加密（encryption）与解密（decryption）过程中使用相同的密钥。2000年10月2日，美国国家标准与技术研究所（NIST–American National Institute of Standards and Technology）选择了 Rijndael 算法作为新的高级加密标准（AES–Advanced Encryption Standard），常用的对称加密算法如下：
| 算法名 | 优点 | 缺点 |
| AES-128-CBC | 实现简单，运行速度快 | 无 MAC 功能 |
| AES-128-GCM | 有 MAC 功能 | 实现复杂，速度较 CBC 慢 |
| ChaCha20-Poly1305 | 运行速度快，适用于移动端 | 推出时间较短 |
| RC4 | 实现简单，运行速度快 | 已经不安全 |
AES-GCM 是目前常用的分组加密算法，但是其有一个缺点就是计算量大，导致性能和电量开销比较大。为了解决这个问题，intel 推出了名为 AES NI（Advanced Encryption Standard new instructions）的 x86 指令拓展集，从硬件上提供对 AES 的支持，具体参见文档。
所以对于支持 AES NI 指令的设备来说，使用 AES-GCM 无疑是最佳选择。针对移动端，对于不支持 AES NI 的设备来说，Google 在 2014年 推出了一种新的流式加密算法 ChaCha20-Poly1305，在 ARM 平台上，性能是 AES-GCM 的 3-4 倍。
ChaCha20-Poly1305 算法介绍
Chacha20-Poly1305 是由 Google 专门针对移动端 CPU 优化而采用的一种新式流式加密算法，它的性能相比普通算法要提高 3 倍，在 CPU 为精简指令集的 ARM 平台上尤为显著（ARM v8前效果较明显）。其中 Chacha20 是指对称加密算法，Poly1305 是指身份认证算法。使用该算法，可减少加密解密所产生的数据量进而可以改善用户体验，减少等待时间，节省电池寿命等。由于其算法精简、安全性强、兼容性强等特点，目前 Google致力于全面将其在移动端推广。
- 更好的性能体现
从 Google 公司公布的数据来看，Chacha20-Poly1305 能够提升 30% 以上的加解密性能，可有效节省移动端耗电量。对比当前流行的加密套件 AES-GCM，在不支持 AES NI 指令的硬件设备上，该算法会引起性能问题，如大部分的智能手机、平板电脑以及可穿戴设备。总的来说，在部分移动设备上，ChaCha20-Poly1305 加密的速度是 AES 的 3 倍还多。也即在使用 ChaCha20-Poly1305 时，较旧的计算机或者移动端设备在加解密方面会花费更少的计算时间，减少加解密时间意味着更快的页面加载速度以及更少的设备电池消耗。
针对移动端设备，我们很容易得出这样的结论和解决方案：在具有硬件 AES 支持的 PC 电脑上，使用 AES-GCM 算法无疑是不错的选择；又拍云 CDN 平台会根据客户端支持的加密套件情况来智能选择是否提供 AES-GCM 还是 ChaCha20-Poly1305。对于最新的英特尔处理器，我们会使用标准的 AES-GCM 算法；对于没有硬件 AES 支持的设备来说，我们会优先选择 ChaCha20-Poly1305。
- 更安全的组合方式
就安全性而言，ChaCha20-Poly1305 加密套件使用了两种算法，其中 Chacha20 是指对称加密算法，Poly1305 是指身份认证算法。从 RFC 文档里面可以得知，ChaCha20 提供了 256 位的加密强度，这对于 AES-GCM 算法的 128 位的加密强度来说，已经绰绰有余。也就是说，使用 ChaCha20 作为对称加密算法来保障 HTTPS 安全性已经足够了。
Poly1305 作为身份认证算法提供身份验证，可以防止攻击者在 TLS 握手过程中，将虚假信息插入到安全的数据流中，Poly1305 提供了大约 100 位的安全性，足以阻止这类攻击。在 TLS 握手过程中，身份验证相比加密并没有那么重要，因为即使攻击者可以向数据流中添加虚假消息，在密钥信息没有被破解的情况下，也不会读取到内部的数据信息。
总之，ChaCha20-Poly1305 作为一个加密组合，可同时对数据提供机密性，完整性和真实性保证，避开了现有发现的所有安全漏洞和攻击，是一组极佳的加密套件组合。
实现方式及效果
为了达到「针对支持 AES-NI 的终端使用 AES-GCM 算法，否则使用 ChaCha20 算法」这样的效果，服务端需要支持等价加密算法组就可以满足此要求，服务端 ssl_ciphers 配置可以参考如下：
ssl_ciphers [ECDHE-ECDSA-AES128-GCM-SHA256|ECDHE-ECDSA-CHACHA20-POLY1305|ECDHE-RSA-AES128-GCM-SHA256|ECDHE-RSA-CHACHA20-POLY1305]:ECDHE+AES128:RSA+AES128:ECDHE+AES256:RSA+AES256:ECDHE+3DES:RSA+3DES
方括号 “[]” 中的配置就是等价加密算法，通过以上配置可以看出，加密套件 ECDHE-ECDSA-AES128-GCM-SHA256、ECDHE-ECDSA-CHACHA20-POLY1305、ECDHE-RSA-AES128-GCM-SHA256、ECDHE-RSA-CHACHA20-POLY1305 具有相同的优先级。接下来，客户端就可以把优先希望访问的加密套件放到前面，服务端就可以根据等价算法组进行匹配，优先响应客户端支持的且排在前列的加密算法。举例说明如下：
Mac Chrome 支持的加密套件序列如下：
Cipher Suites (13 suites) :
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca9)
Cipher Suite: TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca8)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)
Cipher Suite: TLS_RSA_WITH_AES_128_GCM_SHA256 (0x009c)
Cipher Suite: TLS_RSA_WITH_AES_256_GCM_SHA384 (0x009d)
Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)
按照以上服务端的配置以及等价加密算法的原理，则服务端会优先响应如下加密算法：
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
iphone Chrome 支持的加密套件序列如下：
Cipher Suites (10 suites)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 (0xcc14)
Cipher Suite: TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (0xcc13)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
Cipher Suite: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x009e)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)
Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033)
按照以上服务端的配置以及等价加密算法的原理，则服务端会优先响应如下加密算法：
Cipher Suite: TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 (0xcc14)
通过以上举例可以看出，Chrome 会在不同的平台会发送不同顺序的加密算法序列，而服务端会根据等价加密算法组的支持，就可以实现针对支持 AES-NI 的终端使用 AES-GCM 算法，否则使用 ChaCha20 算法的目标。
使用方式
又拍云 CDN 平台已经默认支持了 CHACHA20_POLY1305，并且针对不支持 AES-NI 的终端优先选择此算法作为对称加密算法，该特性无需单独开启。