互联网日益发达,全球每天产生的网络数据不计其数,信息的安全性要求越来越高。科学家们设计了一套安全可靠的网络数据加密协议,保证我们每天访问的信息、支付的电子账单都是安全的。这套安全可靠的网络数据加密协议就是我们今天要说的TLS。
目录
- TLS的基本常识
- 握手的过程
2.1 RSA算法
2.2 DH算法
2.3 DHE算法
2.4 ECDH算法
2.5 ECDHE算法
- TLS Record
- 握手过程的优化
4.1 Session Resumption
4.3 Connection Resumption
4.4 False Start
4.5 调整 TLS Record Size
4.6 优化证书信任链
- Charles 抓包原理
1. TLS的基本常识
我们经常使用的HTTPS实际上是HTTP over SSL,其中的SSL(Secure Sockets Layer)最初是由网景公司(Netscape) 开发的保证电子商务交易安全的一套web协议。最开始发布的版本是SSL 2.0,然后很快发布了SSL 3.0,最终在1999年由IETF在RFC 2246中标准化了并开始命名为TLS(Transport Layer Security) 1.0,之后由IETF陆续发布了TLS 1.1(2006/4)、TLS 1.2(2008/8)、TLS 1.3(2018/8)。目前业界用的最多的是TLS 1.2和 TLS 1.1,由于TLS 1.3 刚发布不久还很少有公司全面升级。
TLS和SSL其实是同一套协议的不同版本,我们经常会说SSL/TLS也源于此
TLS是实现在应用层协议(如HTTP、SMTP等)与传输层协议(如TCP、UDP)中间的一套协议:

TLS位于应用层协议与传输层协议中间
TLS与应用层协议和传输层协议是独立的,对上不仅仅可以适用于HTTP,也可以适用与FTP(FTPS)、SMTP over SSL/TLS、POP3 over SSL/TLS ; 对下不仅仅适用于TCP,也可以适用于UDP(DTLS)
TLS主要通过三种方式来解决安全传输问题:
加密
使传输的数据不能被中间人直接解析
身份认证
验证对方的身份,确认对方是否是可信任的
完整性
确保数据不被中间人篡改
关于这三者的技术文章有很多,这里不展开介绍,推荐先去这里了解一下这些基本知识。
2. 握手过程
TLS握手实际上就是客户端与服务端协商对称密钥的过程,这个对称密钥将来就用来加密应用数据。为了保证这个密钥的安全性,要使用非对称密钥的加密算法来交换。
RSA算法
传统的握手是基于RSA算法的,其依靠的原理就是:“两个大质数相乘容易,但是做因式分解却很复杂”。目前公钥长度为512位和768位的都被破解了,对1024位的也产生了威胁,所以现在一般都用2048位保证安全性。
其握手过程如下图:

RSA握手
Keyless 表示是否在第三方服务器(如CDN)上存储自己的私钥,这里直接把私钥放在CloudFare上所以是Without Keyless SSL。 有些银行可能为了安全,把私钥放在自己的服务器上,CloudFare此时只做一次加密数据的转发,premaster secret的解密还是在自己的服务器上完成,那时称为Keyless SSL
文字描述一下具体过程如下:
- 客户端生成一个随机数random1,给服务端发送Client Hello,携带random1并告诉服务器自己支持的协议版本、加密套件等信息。
- 服务端收到Client Hello,从中选择一个双方都支持的协议版本和加密套件,然后发送Server Hello,并带上自己的证书(包含自己的公钥public-key B)以及随机数random2
- 客户端验证证书并取出public-key B, 生成一个预主密钥premaster key, 用public-key B加密后发送给服务端。
- 服务端利用private-key B解密得到premaster key
- 客户端与服务端使用协商好的相同算法根据random1、random2、premaster key生成对称密钥session key,之后的通信数据就使用这个session key加密。
整个过程交换了三个随机数,其中前两个是明文传输的,只有第三个是加密传输的,也就是RSA算法所用到的地方。然而,从理论上讲,一旦指望用公钥加密随机数网络上传输,那么终究会有被破解的风险,而且即使现在不破解,未来破解时也会把之前的会话信息都解密。这也是RSA握手的安全性在理论上还不够完美的地方。
DH 算法
于是就有科学家想出来更安全的算法,即协商过程的第三个随机数不依靠公钥加密来保证安全,而是明文传输算法参数由双方各自算出同样的premaster secret。这样一来协商过程的所有信息都是明文的,但中间人还是破解不了。这就是著名的DH(Diffie–Hellman)算法。
DH算法依赖的数学原理是求解“离散对数问题”的复杂性,简单介绍一下其原理:
- 客户端C与服务端S协商好算法参数:质数p和质数q
- C生成一个随机数a作为自己的私钥,然后计算A = p^a mod q 作为自己的公钥
- S生成一个随机数b作为自己的私钥,然后计算B = p^b mod q 作为自己的公钥
- CS双方交换自己的公钥,此时双方都有了共同的参数: A、B、p、q
- C 计算 k = B^a mod q, S计算 k = A^b mod q,得出的k就是RSA握手中的premaster secret,然后双方使用相同的算法计算出对称密钥。
这个算法保证了几个关键点:
- 双方算出的k是相同的。
- 双方都无法推算出对方的私钥。
- 中间人即使偷窥到A、B、p、q,也不能推算出a、b,也就无法计算出k。
其握手过程如下:

DH握手
看得出来与RSA算法握手的区别就是在第三步协商Premaster secret时。注意到第三步中使用到了私钥,它只是用来做签名完成认证的。因为DH算法不支持签名认证,需要借助RSA签名。
目前非对称加密算法中只有RSA即可以用于密钥交换又可用于证书签名。
DHE算法
这是DH算法的一个变种,其中E代表的是ephemeral
(短暂的),其解决的是前向保密(FS, forward secrecy)问题:“即使用来产生会话密钥(session key)的长期(long-term)密钥泄漏或者被破解后,也保证之前会话的通讯内容的安全性”。
RSA是无法做到前向保密的,因为其私钥是长期稳定不变的,攻击者可以先保存加密的会话内容,一旦未来某天拿到了私钥,就可以解密出会话密钥,也就能解析之前保存的会话内容了。DH算法的私钥是可以动态生成的,因此可以强制每个会话都使用新生成的私钥从而产生新的session key。
这也是DH算法比RSA更安全的一个原因
ECDH算法
这是DH算法的另一个变种,全称是椭圆曲线DH(Elliptic Curve Diffie-Hellman)算法。
它与 DH 类似,差别在于:
DH 依赖的是——求解“离散对数问题”的困难。
ECDH 依赖的是——求解“椭圆曲线离散对数问题”的困难。
数学原理更复杂,所以也更安全。
ECDHE算法
显而易见,这是结合了DHE和ECDH算法的各自优点变种的新算法。
看看小专栏握手后协商的是什么加密算法:

小专栏TLS握手的算法
服务端选择了TLS的版本是1.2,选择的加密方式:
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
- ECDHE 是密钥交换使用的非对称加密算法
- RSA 是签名认证使用非对称加密算法
- AES 是最后的会话密钥,对称加密算法
- 128是AES的密码长度
- GCM是AES的加密模式
- SHA256是消息验证码(MAC, message authentication code )使用的哈希算法,可以理解为签名中的摘要算法
互联网日益发达,全球每天产生的网络数据不计其数,信息的安全性要求越来越高。科学家们设计了一套安全可靠的网络数据加密协议,保证我们每天访问的信息、支付的电子账单都是安全的。这套安全可靠的网络数据加密协议就是我们今天要说的TLS。
目录
- TLS的基本常识
- 握手的过程
2.1 RSA算法
2.2 DH算法
2.3 DHE算法
2.4 ECDH算法
2.5 ECDHE算法
- TLS Record
- 握手过程的优化
4.1 Session Resumption
4.3 Connection Resumption
4.4 False Start
4.5 调整 TLS Record Size
4.6 优化证书信任链
- Charles 抓包原理
1. TLS的基本常识
我们经常使用的HTTPS实际上是HTTP over SSL,其中的SSL(Secure Sockets Layer)最初是由网景公司(Netscape) 开发的保证电子商务交易安全的一套web协议。最开始发布的版本是SSL 2.0,然后很快发布了SSL 3.0,最终在1999年由IETF在RFC 2246中标准化了并开始命名为TLS(Transport Layer Security) 1.0,之后由IETF陆续发布了TLS 1.1(2006/4)、TLS 1.2(2008/8)、TLS 1.3(2018/8)。目前业界用的最多的是TLS 1.2和 TLS 1.1,由于TLS 1.3 刚发布不久还很少有公司全面升级。
TLS和SSL其实是同一套协议的不同版本,我们经常会说SSL/TLS也源于此
TLS是实现在应用层协议(如HTTP、SMTP等)与传输层协议(如TCP、UDP)中间的一套协议:

TLS位于应用层协议与传输层协议中间
TLS与应用层协议和传输层协议是独立的,对上不仅仅可以适用于HTTP,也可以适用与FTP(FTPS)、SMTP over SSL/TLS、POP3 over SSL/TLS ; 对下不仅仅适用于TCP,也可以适用于UDP(DTLS)
TLS主要通过三种方式来解决安全传输问题:
加密
使传输的数据不能被中间人直接解析
身份认证
验证对方的身份,确认对方是否是可信任的
完整性
确保数据不被中间人篡改
关于这三者的技术文章有很多,这里不展开介绍,推荐先去这里了解一下这些基本知识。
2. 握手过程
TLS握手实际上就是客户端与服务端协商对称密钥的过程,这个对称密钥将来就用来加密应用数据。为了保证这个密钥的安全性,要使用非对称密钥的加密算法来交换。
RSA算法
传统的握手是基于RSA算法的,其依靠的原理就是:“两个大质数相乘容易,但是做因式分解却很复杂”。目前公钥长度为512位和768位的都被破解了,对1024位的也产生了威胁,所以现在一般都用2048位保证安全性。
其握手过程如下图:

RSA握手
Keyless 表示是否在第三方服务器(如CDN)上存储自己的私钥,这里直接把私钥放在CloudFare上所以是Without Keyless SSL。 有些银行可能为了安全,把私钥放在自己的服务器上,CloudFare此时只做一次加密数据的转发,premaster secret的解密还是在自己的服务器上完成,那时称为Keyless SSL
文字描述一下具体过程如下:
- 客户端生成一个随机数random1,给服务端发送Client Hello,携带random1并告诉服务器自己支持的协议版本、加密套件等信息。
- 服务端收到Client Hello,从中选择一个双方都支持的协议版本和加密套件,然后发送Server Hello,并带上自己的证书(包含自己的公钥public-key B)以及随机数random2
- 客户端验证证书并取出public-key B, 生成一个预主密钥premaster key, 用public-key B加密后发送给服务端。
- 服务端利用private-key B解密得到premaster key
- 客户端与服务端使用协商好的相同算法根据random1、random2、premaster key生成对称密钥session key,之后的通信数据就使用这个session key加密。
整个过程交换了三个随机数,其中前两个是明文传输的,只有第三个是加密传输的,也就是RSA算法所用到的地方。然而,从理论上讲,一旦指望用公钥加密随机数网络上传输,那么终究会有被破解的风险,而且即使现在不破解,未来破解时也会把之前的会话信息都解密。这也是RSA握手的安全性在理论上还不够完美的地方。
DH 算法
于是就有科学家想出来更安全的算法,即协商过程的第三个随机数不依靠公钥加密来保证安全,而是明文传输算法参数由双方各自算出同样的premaster secret。这样一来协商过程的所有信息都是明文的,但中间人还是破解不了。这就是著名的DH(Diffie–Hellman)算法。
DH算法依赖的数学原理是求解“离散对数问题”的复杂性,简单介绍一下其原理:
- 客户端C与服务端S协商好算法参数:质数p和质数q
- C生成一个随机数a作为自己的私钥,然后计算A = p^a mod q 作为自己的公钥
- S生成一个随机数b作为自己的私钥,然后计算B = p^b mod q 作为自己的公钥
- CS双方交换自己的公钥,此时双方都有了共同的参数: A、B、p、q
- C 计算 k = B^a mod q, S计算 k = A^b mod q,得出的k就是RSA握手中的premaster secret,然后双方使用相同的算法计算出对称密钥。
这个算法保证了几个关键点:
- 双方算出的k是相同的。
- 双方都无法推算出对方的私钥。
- 中间人即使偷窥到A、B、p、q,也不能推算出a、b,也就无法计算出k。
其握手过程如下:

DH握手
看得出来与RSA算法握手的区别就是在第三步协商Premaster secret时。注意到第三步中使用到了私钥,它只是用来做签名完成认证的。因为DH算法不支持签名认证,需要借助RSA签名。
目前非对称加密算法中只有RSA即可以用于密钥交换又可用于证书签名。
DHE算法
这是DH算法的一个变种,其中E代表的是ephemeral
(短暂的),其解决的是前向保密(FS, forward secrecy)问题:“即使用来产生会话密钥(session key)的长期(long-term)密钥泄漏或者被破解后,也保证之前会话的通讯内容的安全性”。
RSA是无法做到前向保密的,因为其私钥是长期稳定不变的,攻击者可以先保存加密的会话内容,一旦未来某天拿到了私钥,就可以解密出会话密钥,也就能解析之前保存的会话内容了。DH算法的私钥是可以动态生成的,因此可以强制每个会话都使用新生成的私钥从而产生新的session key。
这也是DH算法比RSA更安全的一个原因
ECDH算法
这是DH算法的另一个变种,全称是椭圆曲线DH(Elliptic Curve Diffie-Hellman)算法。
它与 DH 类似,差别在于:
DH 依赖的是——求解“离散对数问题”的困难。
ECDH 依赖的是——求解“椭圆曲线离散对数问题”的困难。
数学原理更复杂,所以也更安全。
ECDHE算法
显而易见,这是结合了DHE和ECDH算法的各自优点变种的新算法。
看看小专栏握手后协商的是什么加密算法:

小专栏TLS握手的算法
服务端选择了TLS的版本是1.2,选择的加密方式:
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
- ECDHE 是密钥交换使用的非对称加密算法
- RSA 是签名认证使用非对称加密算法
- AES 是最后的会话密钥,对称加密算法
- 128是AES的密码长度
- GCM是AES的加密模式
- SHA256是消息验证码(MAC, message authentication code )使用的哈希算法,可以理解为签名中的摘要算法
互联网日益发达,全球每天产生的网络数据不计其数,信息的安全性要求越来越高。科学家们设计了一套安全可靠的网络数据加密协议,保证我们每天访问的信息、支付的电子账单都是安全的。这套安全可靠的网络数据加密协议就是我们今天要说的TLS。
目录
- TLS的基本常识
- 握手的过程
2.1 RSA算法
2.2 DH算法
2.3 DHE算法
2.4 ECDH算法
2.5 ECDHE算法
- TLS Record
- 握手过程的优化
4.1 Session Resumption
4.3 Connection Resumption
4.4 False Start
4.5 调整 TLS Record Size
4.6 优化证书信任链
- Charles 抓包原理
1. TLS的基本常识
我们经常使用的HTTPS实际上是HTTP over SSL,其中的SSL(Secure Sockets Layer)最初是由网景公司(Netscape) 开发的保证电子商务交易安全的一套web协议。最开始发布的版本是SSL 2.0,然后很快发布了SSL 3.0,最终在1999年由IETF在RFC 2246中标准化了并开始命名为TLS(Transport Layer Security) 1.0,之后由IETF陆续发布了TLS 1.1(2006/4)、TLS 1.2(2008/8)、TLS 1.3(2018/8)。目前业界用的最多的是TLS 1.2和 TLS 1.1,由于TLS 1.3 刚发布不久还很少有公司全面升级。
TLS和SSL其实是同一套协议的不同版本,我们经常会说SSL/TLS也源于此
TLS是实现在应用层协议(如HTTP、SMTP等)与传输层协议(如TCP、UDP)中间的一套协议:

TLS位于应用层协议与传输层协议中间
TLS与应用层协议和传输层协议是独立的,对上不仅仅可以适用于HTTP,也可以适用与FTP(FTPS)、SMTP over SSL/TLS、POP3 over SSL/TLS ; 对下不仅仅适用于TCP,也可以适用于UDP(DTLS)
TLS主要通过三种方式来解决安全传输问题:
加密
使传输的数据不能被中间人直接解析
身份认证
验证对方的身份,确认对方是否是可信任的
完整性
确保数据不被中间人篡改
关于这三者的技术文章有很多,这里不展开介绍,推荐先去这里了解一下这些基本知识。
2. 握手过程
TLS握手实际上就是客户端与服务端协商对称密钥的过程,这个对称密钥将来就用来加密应用数据。为了保证这个密钥的安全性,要使用非对称密钥的加密算法来交换。
RSA算法
传统的握手是基于RSA算法的,其依靠的原理就是:“两个大质数相乘容易,但是做因式分解却很复杂”。目前公钥长度为512位和768位的都被破解了,对1024位的也产生了威胁,所以现在一般都用2048位保证安全性。
其握手过程如下图:

RSA握手
Keyless 表示是否在第三方服务器(如CDN)上存储自己的私钥,这里直接把私钥放在CloudFare上所以是Without Keyless SSL。 有些银行可能为了安全,把私钥放在自己的服务器上,CloudFare此时只做一次加密数据的转发,premaster secret的解密还是在自己的服务器上完成,那时称为Keyless SSL
文字描述一下具体过程如下:
- 客户端生成一个随机数random1,给服务端发送Client Hello,携带random1并告诉服务器自己支持的协议版本、加密套件等信息。
- 服务端收到Client Hello,从中选择一个双方都支持的协议版本和加密套件,然后发送Server Hello,并带上自己的证书(包含自己的公钥public-key B)以及随机数random2
- 客户端验证证书并取出public-key B, 生成一个预主密钥premaster key, 用public-key B加密后发送给服务端。
- 服务端利用private-key B解密得到premaster key
- 客户端与服务端使用协商好的相同算法根据random1、random2、premaster key生成对称密钥session key,之后的通信数据就使用这个session key加密。
整个过程交换了三个随机数,其中前两个是明文传输的,只有第三个是加密传输的,也就是RSA算法所用到的地方。然而,从理论上讲,一旦指望用公钥加密随机数网络上传输,那么终究会有被破解的风险,而且即使现在不破解,未来破解时也会把之前的会话信息都解密。这也是RSA握手的安全性在理论上还不够完美的地方。
DH 算法
于是就有科学家想出来更安全的算法,即协商过程的第三个随机数不依靠公钥加密来保证安全,而是明文传输算法参数由双方各自算出同样的premaster secret。这样一来协商过程的所有信息都是明文的,但中间人还是破解不了。这就是著名的DH(Diffie–Hellman)算法。
DH算法依赖的数学原理是求解“离散对数问题”的复杂性,简单介绍一下其原理:
- 客户端C与服务端S协商好算法参数:质数p和质数q
- C生成一个随机数a作为自己的私钥,然后计算A = p^a mod q 作为自己的公钥
- S生成一个随机数b作为自己的私钥,然后计算B = p^b mod q 作为自己的公钥
- CS双方交换自己的公钥,此时双方都有了共同的参数: A、B、p、q
- C 计算 k = B^a mod q, S计算 k = A^b mod q,得出的k就是RSA握手中的premaster secret,然后双方使用相同的算法计算出对称密钥。
这个算法保证了几个关键点:
- 双方算出的k是相同的。
- 双方都无法推算出对方的私钥。
- 中间人即使偷窥到A、B、p、q,也不能推算出a、b,也就无法计算出k。
其握手过程如下:

DH握手
看得出来与RSA算法握手的区别就是在第三步协商Premaster secret时。注意到第三步中使用到了私钥,它只是用来做签名完成认证的。因为DH算法不支持签名认证,需要借助RSA签名。
目前非对称加密算法中只有RSA即可以用于密钥交换又可用于证书签名。
DHE算法
这是DH算法的一个变种,其中E代表的是ephemeral
(短暂的),其解决的是前向保密(FS, forward secrecy)问题:“即使用来产生会话密钥(session key)的长期(long-term)密钥泄漏或者被破解后,也保证之前会话的通讯内容的安全性”。
RSA是无法做到前向保密的,因为其私钥是长期稳定不变的,攻击者可以先保存加密的会话内容,一旦未来某天拿到了私钥,就可以解密出会话密钥,也就能解析之前保存的会话内容了。DH算法的私钥是可以动态生成的,因此可以强制每个会话都使用新生成的私钥从而产生新的session key。
这也是DH算法比RSA更安全的一个原因
ECDH算法
这是DH算法的另一个变种,全称是椭圆曲线DH(Elliptic Curve Diffie-Hellman)算法。
它与 DH 类似,差别在于:
DH 依赖的是——求解“离散对数问题”的困难。
ECDH 依赖的是——求解“椭圆曲线离散对数问题”的困难。
数学原理更复杂,所以也更安全。
ECDHE算法
显而易见,这是结合了DHE和ECDH算法的各自优点变种的新算法。
看看小专栏握手后协商的是什么加密算法:

小专栏TLS握手的算法
服务端选择了TLS的版本是1.2,选择的加密方式:
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
- ECDHE 是密钥交换使用的非对称加密算法
- RSA 是签名认证使用非对称加密算法
- AES 是最后的会话密钥,对称加密算法
- 128是AES的密码长度
- GCM是AES的加密模式
- SHA256是消息验证码(MAC, message authentication code )使用的哈希算法,可以理解为签名中的摘要算法