互联网日益发达，全球每天产生的网络数据不计其数，信息的安全性要求越来越高。科学家们设计了一套安全可靠的网络数据加密协议，保证我们每天访问的信息、支付的电子账单都是安全的。这套安全可靠的网络数据加密协议就是我们今天要说的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 )使用的哈希算法，可以理解为签名中的摘要算法
