关于im: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/a...

可怜的是，OpenSSL是用的最宽泛的，是事实上的规范。

boringssl
Google’s OpenSSL fork by Adam Langley (@agl__)

https://github.com/sweis/cryp...

四. TLS协定的部署与优化

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

全站https时代正在到来!，
挪动互联网对人们生存的染指越来越深人，用户越来越多的隐衷数据和领取数据通过网络传输，人们的隐衷意识安全意识一直进步；运营商流量劫持，强行插入广告越来越引起反感。因而，各互联网大厂都开始切换到https。

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

不久后淘宝切了全站https，https://www.taobao.com/
http://velocity.oreilly.com.c...

国外：由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.or... )

google的优化：
https://bit.ly/gottls
https://www.imperialviolet.or...
https://istlsfastyet.com/
https://www.ssllabs.com/downl...
http://chimera.labs.oreilly.c...

baidu的教训：
http://op.baidu.com/2015/04/h...

aws的配置
http://docs.aws.amazon.com/El...

能够参考byron之前给出的一个介绍nginx配置的文章 [Nginx下配置高性能，高安全性的https TLS服务] https://blog.helong.info/blog... ，自己提供售后咨询服务，哈哈。

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

hardenedlinux的这个文档：SSL/TLS部署最佳实际v1.4:
http://hardenedlinux.org/jeky...

全站切https，值得关注的一个点是cdn切https，如果cdn资源不应用cdn提供商的域名的话，之前会有私钥必须得交给cdn提供商的平安危险，然而侥幸的是cloudflare提出了keyless ssl计划，解决了这个问题
https://github.com/cloudflare...，cdn切https应该能够借鉴。

有时候咱们会用wireshark之类的工具抓包，来调试http协定，然而切换到https后，都变成二进制密文了，间接抓包是行不通了，那怎么调试协定呢？
解决办法是有的，能够参考 https://imququ.com/post/how-t...
参考 https://developer.mozilla.org...

五. 更多的加密通信协议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/...
http://blog.chromium.org/2015...
截止2015.04，从Chrome到Google server的流量的大略50% 是走的QUIC协定，而且还在一直减少。
据说缩小了YouTube的30%的卡顿。

https://github.com/devsisters...

2. apple ios iMessage

iOS Security Guide : https://www.apple.com/busines...

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/busines...

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/bl...
http://www.wired.com/2014/11/...)。

TextSecure V2 协定：
https://github.com/WhisperSys...
https://github.com/trevp/axol...
https://whispersystems.org/bl...

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

5. otr 协定

规范文档见：https://otr.cypherpunks.ca/Pr...

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/coo...
https://cryptojedi.org/peter/...
http://nacl.cr.yp.to/

7. Tox.im

一款实用NaCL的端到端加密im
https://github.com/irungentoo...

8. CurveCP

http://curvecp.org/security.html

9. tcpcrypt

http://tcpcrypt.org/

10.noise

https://github.com/trevp/nois...

11.tcpcrypt

http://tcpcrypt.org/

12. netflix MSL

http://techblog.netflix.com/2...

http://www.infoq.com/cn/news/...

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

https://d0.awsstatic.com/whit...

值得注意和借鉴的点：

• 对称加密算法抉择了 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/...

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

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

更多技术文章：

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

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

【OpenIM原创】开源OpenIM：轻量、高效、实时、牢靠、低成本的音讯模型
https://forum.rentsoft.cn/thr...