TLS 协议分析 (八) 实现与开源项目

三. TLS 协议的代码实现

TLS 的主要实现：

• OpenSSL

• boringssl(Google)

• libressl

• s2n(Amazon)

• nss(Mozilla)

• polarssl

• botan

• gnutls(gpl)

• cyassl

• go.crypto

openssl 的 tls 协议实现有 6W 行，libressl 3.68W 行， polarssl 1.29 W 行， Botan 1.13 W 行

openssl 是其中代码最糟糕的（没有之一）。openssl 提供了的 api 都太过于底层，api 设计的也很费解，而且严重匮乏文档。请参考 [《令人作呕的 OpenSSL》] 链接 http://blog.csdn.net/dog250/article/details/24552307

不幸的是，OpenSSL 是用的最广泛的，是事实上的标准。

boringsslGoogle’s OpenSSL fork by Adam Langley (@agl__)

https://github.com/sweis/crypto-might-not-suck

四. TLS 协议的部署与优化

这个方面网上的文章还是不少的，本文就简略一点。

全站 https 时代正在到来!，移动互联网对人们生活的介入越来越深人，用户越来越多的隐私数据和支付数据通过网络传输，人们的隐私意识安全意识不断提高；运营商流量劫持，强行插入广告越来越引起反感。因此，各互联网大厂都开始切换到 https。

例如，2015 年 3 月百度全站切换到 https，百度运维部的介绍文章：[《全站 https 时代的号角 : 大型网站的 https 实践系列》] 链接 http://op.baidu.com/2015/04/https-index/ 。

不久后淘宝切了全站 https，https://www.taobao.com/http://velocity.oreilly.com.cn/2015/index.php?func=session&id=8

国外：由 Snowden 爆料，美国人发现 NSA 在大范围深度地监听互联网; 还有 openssl 连续被爆多个严重安全漏洞。之后近 2 年，各种加密通信协议，软件，项目开始热门，各大厂商开始关注密码协议，做数据加密，信息安全。(openssl 资助，pfs 被重视，)

Google 的性能数据：

“In January this year (2010), Gmail switched to using HTTPS foreverything by default. .. In order to do this we had to deploy noadditional machines and no special hardware. On our productionfrontend machines, SSL accounts for < 1% of the CPU load, < 10 KB ofmemory per connection, and < 2% of network overhead…

If you stop reading now you only need to remember one thing: SSL isnot computationally expensive any more.”

— Overclocking SSL blog post by Adam Langley (Google https://www.imperialviolet.org/2010/06/25/overclocking-ssl.html )

google 的优化：https://bit.ly/gottlshttps://www.imperialviolet.org/2010/06/25/overclocking-ssl.htmlhttps://istlsfastyet.com/https://www.ssllabs.com/downloads/SSL_TLS_Deployment_Best_Practices.pdfhttp://chimera.labs.oreilly.com/books/1230000000545/ch04.html

baidu 的经验：http://op.baidu.com/2015/04/https-index/

aws 的配置http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/elb-https-load-balancers.html

可以参考 byron 之前给出的一个介绍 nginx 配置的文章 [Nginx 下配置高性能，高安全性的 https TLS 服务] https://blog.helong.info/blog/2015/05/08/https-config-optimize-in-nginx/ ，本人提供售后咨询服务，哈哈。

CipherSuite 配置(Mozilla 的权威配置)https://wiki.mozilla.org/Security/Server_Side_TLS

hardenedlinux 的这个文档：SSL/TLS 部署最佳实践 v1.4:http://hardenedlinux.org/jekyll/update/2015/07/28/ssl-tls-deployment-1.4.html

全站切 https，值得关注的一个点是 cdn 切 https，如果 cdn 资源不使用 cdn 提供商的域名的话，之前会有私钥必须得交给 cdn 提供商的安全风险，但是幸运的是 cloudflare 提出了 keyless ssl 方案，解决了这个问题https://github.com/cloudflare/keyless，cdn 切 https 应该可以借鉴。

有时候我们会用 wireshark 之类的工具抓包，来调试 http 协议，但是切换到 https 后，都变成二进制密文了，直接抓包是行不通了，那怎么调试协议呢？解决办法是有的，可以参考 https://imququ.com/post/how-to-decrypt-https.html参考 https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/Key_Log_Format

五. 更多的加密通信协议 case：QUIC，iMessage，TextSecure, otr, ios HomeKit，libsodium

时间有限，下面有些协议就没有做详细的分析了，读者自己去看吧。

1. QUIC

QUIC = TCP+TLS+SPDYhttps://www.chromium.org/quic

其中的 crypto design 文档是本文关注的。

http://network.chinabyte.com/162/13361162.shtmlhttp://blog.chromium.org/2015/04/a-quic-update-on-googles-experimental.html截止 2015.04，从 Chrome 到 Google server 的流量的大概 50% 是走的 QUIC 协议，而且还在不断增加。据说减少了 YouTube 的 30%的卡顿。

https://github.com/devsisters/libquic

2. apple ios iMessage

iOS Security Guide : https://www.apple.com/business/docs/iOS_Security_Guide.pdf

Apple 的 iMessage 系统的密码学安全机制设计，端到端加密，前向安全(PFS)，签名使用 ECDSA P-256，非对称加密使用 RSA 1280 bit，苹果自己维护一个 用户名—》公钥 的目录服务。

iMessage 在注册时，给每个用户生成一对 RSA-1280 密钥用作非对称加密，一对 NIST P-256 ECDSA 密钥用作签名，2 个私钥本地保存，公钥上传给 Apple 的目录服务器(IDS)。

当要发送消息的时候，根据接收方的用户名，从 IDS 里面找到 RSA 公钥 和 APNS 地址。然后随机生成 128 比特密钥，用 AES-CTR-128 加密要发送的消息，用接收方的 RSA 1280 公钥，使用 OAEP 填充加密 128 比特 aes 密钥。然后拼接 aes 密文和 rsa 密文，对结果使用发送方的 ECDSA 私钥，用 sha1 算一次数字签名。然后把 aes 密文，rsa 密文，数字签名拼接起来，发给 APNS 投递给接收方。

如果要发送大文件，就生成一个 key，用 aes-ctr-256 加密文件，并计算一个 sha1，然后把 key 和 sha1 放入消息里面发送。

3. apple ios HomeKit

iOS Security Guide : https://www.apple.com/business/docs/iOS_Security_Guide.pdf

Apple 的 HomeKit，是 WWDC2014 上提出的 iot 智能家居开发平台 （iot 啊，目前最火的概念啊，各种高大上啊）。可以看到 HomeKit 作为一个全新的协议， 抛弃了历史遗留算法，直接采用了目前最先进的算法

HomeKit 密码学安全机制的设计：使用 Ed25519 做 公钥签名/验证，使用 SRP(3072 bit) 做来在 iOS 设备和 HomeKit 配件之间交换密码并做认证，使用 ChaCha20-Poly1305 做对称加密，使用 HKDF-SHA512 做密钥拓展。每个 session 的开始用 Station-to-Station 协议做密钥协商和认证，随后使用 Curve25519 做密钥协商，生成共享 key。

4. TextSecure

TextSecure 是一个端到端 im 加密通信协议，由 WhisperSystem 公司设计，目前 whatsapp 和 WhisperSystem 公司有合作，看网上资料，2014 年 11 月开始，whatsapp 已经开始使用 TextSecure 协议来做端到端加密(消息来源: https://whispersystems.org/blog/whatsapp/http://www.wired.com/2014/11/whatsapp-encrypted-messaging/)。

TextSecure V2 协议：https://github.com/WhisperSystems/TextSecure/wiki/ProtocolV2https://github.com/trevp/axolotl/wikihttps://whispersystems.org/blog/advanced-ratcheting/

The TextSecure encrypted messaging protocol 是 otr 的一个衍生协议，主要有 2 个不同点:1.ECDSA 代替 DSA2.某些数据结构压缩

5. otr 协议

标准文档见：https://otr.cypherpunks.ca/Protocol-v3-4.0.0.html

open kullo 协议https://www.kullo.net/protocol/

Choice of algorithmsWhenever we write about symmetric or asymmetric encryption or signatures, we mean the following algorithms, modes and parameters:

symmetric encryption: AES-256 in GCM modeasymmetric encryption: RSA-4096 with OAEP(SHA-512) paddingasymmetric signatures: RSA-4096 with PSS(SHA-512) padding

6. libsodium/NaCL

libsodium/NaCL 值得重点介绍，大力推广 。新的没有兼容包袱的系统，都值得考虑用 NaCL 来代替 openssl。libsodium 是对 NaCL 的封装，NaCL 大有来头，作者 DJB 是密码学领域的权威人物，chacha20，Curve25519 的作者 。没有历史包袱的项目，强烈建议使用 libsodium/NaCL。

这篇文章介绍了 NaCL 和 openssl 相比的各方面改进http://cr.yp.to/highspeed/coolnacl-20120725.pdfhttps://cryptojedi.org/peter/data/tenerife-20130121.pdfhttp://nacl.cr.yp.to/

7. Tox.im

一款实用 NaCL 的端到端加密 imhttps://github.com/irungentoo/toxcore/blob/master/docs/updates/Crypto.md

8. CurveCP

http://curvecp.org/security.html

9. tcpcrypt

http://tcpcrypt.org/

10.noise

https://github.com/trevp/noise/wiki

11.tcpcrypt

http://tcpcrypt.org/

12. netflix MSL

http://techblog.netflix.com/2014/10/message-security-layer-modern-take-on.html

http://www.infoq.com/cn/news/2014/11/netflix-safe-communication

13.Amazon KMS 密钥管理服务 白皮书

https://d0.awsstatic.com/whitepapers/KMS-Cryptographic-Details.pdf

值得注意和借鉴的点：

• 对称加密算法选择了 AES-GCM-256

• 数字签名有 2 种：ECDSA，RSA，

• ECDSA 的曲线选择了 secp384r1 （P384），hash 算法选择了 SHA384

• RSA 选择 2048 位，签名体制选择 RSASSA-PSS，hash 算法选择了 SHA256

• 密钥协商，使用 ECDH，选择曲线 secp384r1 (P384)，有 2 种用法

• one-pass ECDH.

• ECDHE

• 电子信封加密，KMS 内置了电子信封。

• 电子信封就是，你预先知道对方的长期公钥，你有一个消息要发送给对方，所以你生成一个随机的 msgKey,然后 ciphertext = Encrypt(msgKey, message), 并且用对方的公钥加密 msgKey： encKey = Encrypt(k, msgKey), 最后把(encKey, ciphertext) 发给对方，这样，只有公钥对应私钥的拥有者才能打开信封。典型应用比如 OpenPGP。

其中的 one-pass ECDH，大概意思是：发起方有一对长期使用的签名密钥对，发起方生成一对临时的 ECDH 密钥，用自己的长期签名密钥签署 临时 ECDH 公钥。对端有一对长期 ECDH 密钥，收到发起方发来的 ECDH 公钥后，验证签名，并且用自己的长期 ECDH 私钥和收到的公钥协商出共享密钥。整个过程中，只是用了一对临时 ECDH 密钥，2 对长期密钥。

ECDHE 就是比较典型的 ECDHE 了，和 TLS 用法一样：双方都持有一对长期使用的签名密钥对，并拥有对方的签名公钥，然后分别生成一对临时 ECDH 密钥，用自己的签名私钥签署 ECDH 公钥，把得出的签名和 ECDH 公钥发给对方，双方收到对方的 ECDH 公钥后，验证签名，通过后用对方的 ECDH 公钥和自己的 ECDH 私钥协商出共享密钥。DONE。

白皮书中还举了几个例子.

​ 本文转自微信后台团队,如有侵犯,请联系我们立即删除

OpenIMgithub 开源地址：

https://github.com/OpenIMSDK/Open-IM-Server

OpenIM 官网 ： https://www.rentsoft.cn

**OpenIM 官方论坛： ** https://forum.rentsoft.cn/

更多技术文章：

开源 OpenIM：高性能、可伸缩、易扩展的即时通讯架构https://forum.rentsoft.cn/thread/3

【OpenIM 原创】简单轻松入门 一文讲解 WebRTC 实现 1 对 1 音视频通信原理https://forum.rentsoft.cn/thread/4

【OpenIM 原创】开源 OpenIM：轻量、高效、实时、可靠、低成本的消息模型https://forum.rentsoft.cn/thread/1