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

转自:http://chuansong.me/n/1286703952743

三. 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是用的最广泛的,是事实上的标准。

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。

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

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值