A little ssl
2 likes295 views
SSL（安全套接层）和TLS（传输层安全性）都是用于网络安全传输的协议，TLS相比SSL提供了更高的安全性。本文详细介绍了TLS的协商过程、密钥交换算法及其具体实现，同时还探讨了加速TLS协商和降低传输负荷的策略。特别提到使用ECC证书和优化算法来提高性能以及缓存协商结果的策略。
![struct {
uint8 major, minor;
} ProtocolVersion;
enum {
change_cipher_spec(20), alert(21), handshake(22),
application_data(23), (255)
} ContentType;
struct {
ContentType type;
ProtocolVersion version;
uint16 length;
opaque fragment[TLSPlaintext.length];
} TLSPlaintext;](https://image.slidesharecdn.com/alittlessl-170310090449/85/A-little-ssl-7-320.jpg)
A little ssl
- 2. SSL 是什什么 是⼀一种安全协议， 全称 Secure Sockets Layer, ⽹网景公司 （Netscape）在1994年年推出,在 Web 上做为⼀一种安全传输协议。
- 3. TLS 是什什么 也是⼀一种安全协议， 全称是 Transport Layer Security, 1999 年年 RFC 2246 提 出，基于 SSL 3.0 ⽤用于在两个通信应⽤用程序之间提供保密性和数据完整性。
- 4. SSL 和 TLS 的区别 TLS 具有更更⾼高的安全性以及适⽤用性
- 5. TLS 的产商实现 OpenSSL、Google 的 BoringSSL、Oracle 的 JSSE、 Amazon 的 S2n、Microsoft 的 SChannel、Apple 的 Secure Transport
- 6. TLS 的具体实现 TLS 是⼀一个分层协议.每⼀一层中的信息可能包含⻓长度、描述和内容 等字段。 record layer change_cipher_spec record layer alert record layer handshake record layer application_data
- 7. struct { uint8 major, minor; } ProtocolVersion; enum { change_cipher_spec(20), alert(21), handshake(22), application_data(23), (255) } ContentType; struct { ContentType type; ProtocolVersion version; uint16 length; opaque fragment[TLSPlaintext.length]; } TLSPlaintext;
- 9. TLS 协商的具体过程
- 11. Client Hello
- 12. Client Hello
- 13. Cipher Suite
- 14. Server Name
- 15. Server Hello
- 16. Server Hello
- 20. ⼀一个 cipher suite 是4类算法的组合： 1. key exchange algorithm (密钥交换) 2. authentication method (认证⽅方法) 3. bulk encryption cipher (加密算法) 4. message authentication code (消息认证码) 5. pseudorandom function （伪随机函数）
- 21. TLS_ECDHE_RSA_WITH_ AES_128_GCM_SHA256 密钥交换: ECDHE 认证⽅方法: RSA 加密算法: AES_128_GCM MAC 算法：SHA256
- 22. cipher suite 需要在 IANA 进⾏行行注册 https://www.iana.org/assignments/tls- parameters/tls-parameters.xhtml#tls- parameters-4
- 26. 客户端信任证书 ⼤大部分语⾔言使⽤用系统内置的信任证书 Chrome 使⽤用系统内置的信任证书 Firefox 使⽤用 mozilla 维护的信任证书： https://hg.mozilla.org/ mozilla-central/raw-file/tip/security/nss/lib/ckfw/builtins/ certdata.txt Linux 使⽤用 /etc/ssl/certs/ca-bundle.trust.crt 同样也来⾃自于 https:// hg.mozilla.org/mozilla-central/raw-file/tip/security/nss/lib/ckfw/ builtins/certdata.txt
- 27. Certificate Request(可选） 要求客户端随后发送证书 (Client Certificate)
- 28. Server Key Exchange Message 这条消息只会在 Server Certificate ⽆无法记录⾜足够的数据去交换 premaster secret时，才会被发送
- 36. Application Data
- 39. master_secret = PRF(pre_master_secret, "master secret", ClientHello.random + ServerHello.random) ClientHello.random 和 ServerHello.random 是明⽂文，只有 pre_master_secret不不知道
- 40. RSA 是密钥协商算法
- 41. 客户端⽤用服务端的证书公钥加密 pre_master_secret, 服务端获 取之后，⽤用私约解密即可获得 pre_master_secret. 所以只要获得服务端证书私钥就能正确解密 TLS 流量量
- 42. RSA 作为密钥协商的 最⼤大问题 pre master key 是静态的，不不具有所谓的前向安全性(Forward Secrecy), HTTP2 协议要求 SSL 的密钥协商算法需要具有 Perfect Forward Secrecy
- 43. DH 是密钥协商算法
- 44. 不不再直接传递 pre master key, ⽽而是传递 DH 算法所需要的参数，双⽅方各 ⾃自⽣生成⼀一对公钥和私钥，并把各⾃自的公钥交给对⽅方，DH 算法保证双⽅方 能在不不同的参数下⽣生成同样的 pre master key 因为不不知道各⾃自的私钥，所以中间⼈人⽆无法获取 pre master key。
- 45. 浏览器器的 SSLKEYLOGFILE 浏览器器会把每次 TLS 协商的 master key 放到这个⽂文件，因此配 合 wireshark，就能看到 TLS 加密的数据
- 46. 加速 TLS 协商
- 47. ⼏几个维度 1. 减少传输的负荷 2. 使⽤用更更快的算法 3. 缓存协商的结果 4. TLS 协议上优化
- 48. 减少传输的负荷
- 50. 2. 使⽤用 ECC 证书 可以选择 ECC（Elliptic Curve Cryptography，椭圆曲线密码 学）证书。256 位的 ECC Key 等同于 3072 位的 RSA Key.
- 51. ECC 证书的缺点 1. 服务商需要⽀支持⽣生成 ECC 的证书 （可以解决） 2. 兼容性较差，需要较⾼高的系统 （可以解决）
- 52. 使⽤用更更快的算法 在 ARM 平台上使⽤用⾕谷歌的 ChaCha20-Poly1305 算法， 算法针对 ARM 做了了优 化，在移动设备上使⽤用速度更更快、更更省电 在 intel 平台上使⽤用优先使⽤用 AES-GCM， Intel 提供了了 AES NI（Advanced Encryption Standard new instructions）的 x86 指令集扩展，从硬件上提供对 AES 的⽀支持
- 53. 缓存协商的结果 1. 使⽤用 TLS session id 缓存结果 缺点：服务端各个节点需同步 session id 2. 使⽤用 TLS session ticket 缓存结果 缺点：需要轮转 session ticket， 避免 session ticket 前向安全 性
- 54. TLS 协议上优化 需要两个 RTT 来协商
- 55. 开启 False Start （抢 跑） 开启TLS False Start需要浏览器器端和服务器器端同时满⾜足条件。 Chrome和Firefox需要⽀支持NPN/ALPN，并且服务器器端的 cipher suite ⽀支持前向安 全（Forward Secrecy）；
- 56. 使⽤用 OCSP Stapling 代替 OCSP 和 CRL
- 57. 使⽤用 TLS 1.3 ⽬目前只有 Chrome 和 Firefox 默认开启了了 TLS 1.3