使用wireshark对HTTPS解密的实践（二）--SSL/TSL协议及密钥交换算法

SSL 1.0、2.0和3.0

SSL（Secure Sockets Layer）是网景公司（Netscape）设计的主要用于Web的安全传输协议，这种协议在Web上获得了广泛的应用。
基础算法由作为网景公司的首席科学家塔希尔·盖莫尔（Taher Elgamal）编写，所以他被人称为“SSL之父”。
2014年10月，Google发布在SSL 3.0中发现设计缺陷，建议禁用此一协议。攻击者可以向TLS发送虚假错误提示，然后将安全连接强行降级到过时且不安全的SSL 3.0，然后就可以利用其中的设计漏洞窃取敏感信息。Google在自己公司相关产品中陆续禁止回溯兼容，强制使用TLS协议。Mozilla也在11月25日发布的Firefox34中彻底禁用了SSL 3.0。微软同样发出了安全通告。
1.0版本从未公开过，因为存在严重的安全漏洞。
2.0版本在1995年2月发布，但因为存在数个严重的安全漏洞而被3.0版本替代。
3.0版本在1996年发布，是由网景工程师Paul Kocher、Phil Karlton和Alan Freier完全重新设计的。较新版本的SSL/TLS基于SSL 3.0。SSL 3.0作为历史文献IETF通过RFC 6101发表。

TLS 1.0

IETF将SSL标准化，即RFC 2246，并将其称为TLS（Transport Layer Security）。从技术上讲，TLS 1.0与SSL 3.0的差异非常微小。但正如RFC所述"the differences between this protocol and SSL 3.0 are not dramatic, but they are significant enough to preclude interoperability between TLS 1.0 and SSL 3.0"（本协议和SSL 3.0之间的差异并不是显著，却足以排除TLS 1.0和SSL 3.0之间的互操作性）。TLS 1.0包括可以降级到SSL 3.0的实现，这削弱了连接的安全性。

TLS 1.1

TLS 1.1在RFC 4346中定义，于2006年4月发表，它是TLS 1.0的更新。在此版本中的差异包括：
添加对CBC攻击的保护：
隐式IV被替换成一个显式的IV。
更改分组密码模式中的填充错误。
支持IANA登记的参数。

TLS 1.2

TLS 1.2在RFC 5246中定义，于2008年8月发表。它基于更早的TLS 1.1规范。主要区别包括：
可使用密码组合选项指定伪随机函数使用SHA-256替换MD5-SHA-1组合。
可使用密码组合选项指定在完成消息的哈希认证中使用SHA-256替换MD5-SHA-1算法，但完成消息中哈希值的长度仍然被截断为96位。
在握手期间MD5-SHA-1组合的数字签名被替换为使用单一Hash方法，默认为SHA-1。
增强服务器和客户端指定Hash和签名算法的能力。
扩大经过身份验证的加密密码，主要用于GCM和CCM模式的AES加密的支持。
添加TLS扩展定义和AES密码组合。所有TLS版本在2011年3月发布的RFC 6176中删除了对SSL的兼容，这样TLS会话将永远无法协商使用的SSL 2.0以避免安全问题。

TLS 1.3

参见：来回通信延迟
TLS 1.3在RFC 8446中定义，于2018年8月发表。它基于更早的TLS 1.2规范，与TLS 1.2的主要区别包括：
将密钥协商和认证算法从密码包中分离出来。
移除脆弱和较少使用的命名椭圆曲线支持（参见椭圆曲线密码学）。
移除MD5和SHA-224密码散列函数的支持。
请求数字签名，即便使用之前的配置。
集成HKDF和半短暂DH提议。
替换使用PSK和票据的恢复。
支持1-RTT握手并初步支持0-RTT。
通过在(EC)DH密钥协议期间使用临时密钥来保证完善的前向安全性。
放弃许多不安全或过时特性的支持，包括数据压缩、重新协商、非AEAD密码本、静态RSA和静态DH密钥交换、自定义DHE分组、点格式协商、更改密码本规范的协议、UNIX时间的Hello消息，以及长度字段AD输入到AEAD密码本。
禁止用于向后兼容性的SSL和RC4协商。
集成会话散列的使用。
弃用记录层版本号和冻结数以改进向后兼容性。
将一些安全相关的算法细节从附录移动到标准，并将ClientKeyShare降级到附录。
添加带有Poly1305消息验证码的ChaCha20流加密。
添加Ed25519和Ed448数字签名算法。
添加x25519和x448密钥交换协议。
将支持加密服务器名称指示（EncryptedServerNameIndication, ESNI）。

网络安全服务（NSS）是由Mozilla开发并由其网络浏览器Firefox使用的加密库，自2017年2月起便默认启用TLS 1.3。随后TLS 1.3被添加到2017年3月发布的Firefox 52.0中，但它由于某些用户的兼容性问题，默认情况下禁用。直到Firefox 60.0才正式默认启用。
Google Chrome曾在2017年短时间将TLS 1.3设为默认，然而由于类似Blue Coat Systems等不兼容组件而被取消。
wolfSSL在2017年5月发布的3.11.1版本中启用了TLS 1.3。作为第一款支持TLS 1.3部署，wolfSSL 3.11.1 支持 TLS 1.3 Draft 18（ 现已支持到Draft 28），同时官方也发布了一系列关于TLS 1.2和TLS 1.3性能差距的博客。 

密钥交换和密钥协商

在客户端和服务器开始交换TLS所保护的加密信息之前，他们必须安全地交换或协定加密密钥和加密数据时要使用的密码。用于密钥交换的方法包括：使用RSA算法生成公钥和私钥（在TLS握手协议中被称为TLS_RSA），Diffie-Hellman（在TLS握手协议中被称为TLS_DH），临时Diffie-Hellman（在TLS握手协议中被称为TLS_DHE），椭圆曲线迪菲-赫尔曼（在TLS握手协议中被称为TLS_ECDH），临时椭圆曲线Diffie-Hellman（在TLS握手协议中被称为TLS_ECDHE），匿名Diffie-Hellman（在TLS握手协议中被称为TLS_DH_anon）和预共享密钥（在TLS握手协议中被称为TLS_PSK）。
TLS_DH_anon和TLS_ECDH_anon的密钥协商协议不能验证服务器或用户，因为易受中间人攻击因此很少使用。只有TLS_DHE和TLS_ECDHE提供前向保密能力。
在交换过程中使用的公钥/私钥加密密钥的长度和在交换协议过程中使用的公钥证书也各不相同，因而提供的强健性的安全。2013年7月，Google宣布向其用户提供的TLS加密将不再使用1024位公钥并切换到2048位，以提高安全性。

 

https://blog.csdn.net/jc_workspace/article/details/27987077
SSL支持的认证密钥交换方法
一共有5中方法：

一、RSA：

a)        服务端在发送certificate message时，包含服务端的一个X.509证书（用于验证服务端的RSA公钥）；服务端不需要发送server_key_exchange；客户端产生pre_master_secret（次密钥）后，利用上述证书中的RSA公钥对其加密，并通过client_key_exchange发送到服务端，服务端利用对应的RSA私钥解密得到pre_master_secret；

b)       服务端在发送certificate message时，包含服务端的一个X.509证书（用于验证服务端的RSA公钥）；服务端临时产生一个RSA公私钥对，并在发送server_key_exchange时包含上述临时RSA公钥（指数和模）和参数签名（利用服务端证书的RSA公钥对应的私钥对临时RSA公钥的hash加密产生签名）；客户端产生pre_master_secret（次密钥）后，利用临时RSA公钥对其加密，并通过client_key_exchange发送到服务端，服务端利用对应的RSA私钥解密得到pre_master_secret；

二、Fixed Diffie-Hellman：（固定Diffie-Hellman）

服务端在发送certificate message时，包含服务端的一个X.509证书（用于验证服务端的Diffie-Hellman公钥的三个参数）；服务端不需要发送server_key_exchange；

客户端在发送certificate message时，包含服务端的一个X.509证书（用于验证客户端的Diffie-Hellman公钥的三个参数）；客户端不需要发送client_key_exchange；

双方执行Diffie-Hellman计算，产生共享次密钥；

三、Ephemeral Diffie-Hellman：(瞬时Diffie-Hellman)

服务端在发送certificate message时，包含服务端的一个X.509证书（用于验证服务端的RSA公钥）；服务端产生一个临时Diffie-Hellman参数组，发送server_key_exchange时包含临时Diffie-Hellman公钥和参数签名（利用服务端证书的RSA公钥对应的私钥对临时Diffie-Hellman公钥的hash加密产生签名）；客户端发送client_key_secret时包含客户端Diffie-Hellman公钥参数；双方执行Diffie-Hellman计算，产生共享次密钥；

四、Anonymous Diffie-Hellman：（匿名Diffie-Hellman）

服务端无需发送certificate message，在发送server_key_exchange时直接发送服务端Diffie-Hellman公钥参数；客户端在发送client_key_exchange时包含客户端Diffie-Hellman公钥参数；双方执行Diffie-Hellman计算，产生共享次密钥；

五、Fortezza:为Fortezza方案定义的技术；