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.youkuaiyun.com/dog250/article/details/24552307

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

boringssl
Google’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 for
everything by default. … In order to do this we had to deploy no
additional machines and no special hardware. On our production
frontend machines, SSL accounts for < 1% of the CPU load, < 10 KB of
memory per connection, and < 2% of network overhead…

If you stop reading now you only need to remember one thing: SSL is
not 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/gottls
https://www.imperialviolet.org/2010/06/25/overclocking-ssl.html
https://istlsfastyet.com/
https://www.ssllabs.com/downloads/SSL_TLS_Deployment_Best_Practices.pdf
http://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+SPDY
https://www.chromium.org/quic

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

http://network.chinabyte.com/162/13361162.shtml
http://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/ProtocolV2
https://github.com/trevp/axolotl/wiki
https://whispersystems.org/blog/advanced-ratcheting/

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

5. otr 协议

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

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

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

symmetric encryption: AES-256 in GCM mode
asymmetric encryption: RSA-4096 with OAEP(SHA-512) padding
asymmetric 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.pdf
https://cryptojedi.org/peter/data/tenerife-20130121.pdf
http://nacl.cr.yp.to/

7. Tox.im

一款实用NaCL的端到端加密im
https://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