三. 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