下图是在iPhone Chrome上打开Google日本网站后的加密信息截图。
野狗WildDog已经全站支持在移动设备上更高性能、更省电的加密套件ChaCha20-Poly1305。下面是在Chrome上打开野狗官网的加密信息截图。
为了能够更好的了解ChaCha20-Poly1305,先简单介绍对称加密和AES-NI。
对称加密与AES-NI
对称加密
在HTTPS握手过程,通过非对称加密协商出对称加密密钥,然后使用对称加密对双方通信的数据内容进行加密。非对称加密是服务器性能的开销是巨大的,通过Session Resume等方法可以进行加速。常见的非对称加密算法有RSA、ECDHE等。
在协商出对称加密密钥后,HTTPS中所有数据内容通信的加密都使用对称加密进行。对称加密分为流式加密和分组加密。
常见的流式加密算法有:RC4,ChaCha20-Poly1305。
常见的分组加密算法有:AES-CBC,AES-GCM。
RC4由于存在严重安全漏洞,已经基本不再使用;AES-CBC容易遭受BEAST和LUCKY13攻击,使用也逐渐减少,AES-GCM是它们的安全替代,AES-GCM也是目前最为流行的对称加密算法。
安全风险可参看ssllabs上的相关文章:
AES-NI
AES-GCM解决了对称加密存在的安全问题,但带来了性能问题。为此,出现了AES-NI(Advanced Encryption Standard New Instruction)。AES-NI是Intel和AMD微处理器上x86架构的一个扩展,可以从硬件上加速AES的性能,目前在服务器和PC端,CPU对AES-NI的支持率已经非常普及。
测试结果:服务器开启AES-NI后,性能提高了5-8倍左右,这与Intel官方公布的数据基本是一致的。
测试方法:
可以使用OpenSSL测试也可以使用其他SSL库测试,因为所有SSL库都支持AES-128-GCM。
OpenSSL AES-NI = OFF
# OPENSSL_ia32cap=”~0x200000200000000″ openssl speed -elapsed -evp aes-128-gcm
OpenSSL AES-NI = ON
# openssl speed -elapsed -evp aes-128-gcm
关于AES-NI的指令集,推荐查看Shay Gueron编写的《Intel 高级加密标准 (AES) 指令集 (2010)》。
ChaCha20-Poly1305优势何在?
Google推出新的加密套件并在所有移动端的Chrome浏览器上优先使用原因:
ChaCha20-Poly1305避开了现有发现的所有安全漏洞和攻击;
ChaCha20-Poly1305针对移动端设备大量使用的ARM芯片做了优化,能够充分利用ARM向量指令,在移动设备上加解密速度更快、更省电;
更加节省带宽,Poly1305的输出是16字节,而HMAC-SHA1是20字节,可以节省16%的overhead消耗。
通过实际的测试数据来看看ChaCha20-Poly1305在移动端使用的优势。
测试一:
在支持AES-NI扩展的设备上,AES加密的性能优势是明显的。 目前最为常用的对称加密AES-128-GCM的性能是ChaCha20-Poly1305的近5倍。
由于原生的OpenSSL目前还不支持ChaCha20-Poly1305,通过编译LibreSSL源码(最新源码来进行测试。
测试方法:
进入到编译后的LibreSSL目录,通过下面的命令测试。
./apps/openssl/openssl speed -elapsed -evp chacha
./apps/openssl/openssl speed -elapsed -evp aes-128-gcm
./apps/openssl/openssl speed -elapsed -evp aes-256-gcm
./apps/openssl/openssl speed -elapsed -evp aes-128-cbc
./apps/openssl/openssl speed -elapsed -evp aes-256-cbc
测试二:
在不支持AES-NI扩展的移动设备上,ChaCha20-Poly1305的性能是AES-GCM的三倍左右。
对称加密最合理的使用方法是:在支持AES-NI的设备上,优先使用AES-128-GCM加密套件;在不支持AES-NI的移动设备上,特别是ARM架构的设备上,优先使用ChaCha20-Poly1305加密套件。
Nginx实现ChaCha20-Poly1305的三种方法
OpenSSL官方版本目前不支持ChaCha20-Poly1305,所以不能使用原生的OpenSSL版本。关注OpenSSL官方的动态
在Nginx上实现ChaCha20-Poly1305主流的方法有三种:
使用OpenBSD从OpenSSL fork的分支LibreSSL;
使用Google从OpenSSL fork的分支BoringSSL;
使用CloudFlare提供的OpenSSL Patch。
主流的三种方法,都已经在服务器上部署成功并经过流量测试,各有优缺点。具体的部署方法、Nginx配置、部署过程可能会遇到的错误及解决方法,涉及的内容太多,相关内容如下:
Nginx编译安装BoringSSL
Nginx编译安装LibreSSL
Nginx编译安装CloudFlare提供的OpenSSL Patch
下面是我总结的这三种方法的优缺点,这个欢迎大家补充。
LibreSSL
编译安装方法最为简单;
OpenBSD小组对OpenSSL的代码进行了全面清理并重构,更为轻量;
已经发布稳定版本,相比于OpenSSL团队,问题修复更及时。
BoringSSL
支持等价加密算法组功能(Equal preference cipher groups),这功能我认为很有意思,在后面博客中再介绍;
与Nginx编译友好性不足,编译容易出错,至少需要修改两处源码;
不支持OCSP Stapling功能。这一点是比较有意思的,Google工程师在博客上说OCSP Stapling存在缺陷,目前不支持,但不排除后面支持的可能性。联想到Chrome浏览器默认也不使用OCSP,可见Google对OCSP的情感是复杂的。
OpenSSL Patch
编译安装过程较为复杂;
OpenSSL本身较重,存在的安全问题也多,需要频繁升级版本;
稳定性需要进一步验证。
目前野狗WildDog网站使用的是LibreSSL,来解决移动端的加速省电等新性能,如果你有疑问,或者想更多交流,或者在使用ChaCha20-Poly1305时遇到问题,都欢迎和我们联系。最后附上野狗官网(www.wilddog.com)在ssllabs上评测结果中截图。
这是没有办法的。HTTPS意味着在进行TCP握手后,还要进行一次TLS握手。
具体请看这篇文章,通俗地讲述了HTTPS的原理,好处,坏处:
http://huaidan.org/archives/3355.html
目前的TLS协议不够全面,对使用CDN等缓存机制提出了相当的限制。
加速方面,如果是因为线路问题的部分,确实可以通过VPN/HTTP Proxy缓解。
面也部署配置了证书,设置的全程加密,但是打不开网站,客服改为半程加密说节点访问没问题,访问我源服务器有问题,但是没用云加速时,网站都是正常访问的呀,服务器上也没什么第三方的安全设置,防火墙也关闭了。123欢迎分享,转载请注明来源:夏雨云
评论列表(0条)