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