26 | 信任始于握手：TLS1.2连接过程解析
HTTPS 建立连接
TLS 协议的组成
请订阅文章所属专栏。
精选留言(40)
彩色的沙漠浏览留言区，留言区同学和我有一样的疑问“Client Params 和 Server Params 都可以被截获，为何中间人没法通过这两个信息计算 Pre-Master Secret 呢？”
我去网上找了关于ECDHE握手过程，这个可以帮助大家更好的理解ECDHE，具体过程如下：
（1）：客户端随机生成随机值Ra，计算Pa(x, y) = Ra * Q(x, y)，Q(x, y)为全世界公认的某个椭圆曲线算法的基点。将Pa(x, y)发送至服务器。
（2）：服务器随机生成随机值Rb，计算Pb(x,y) = Rb * Q(x, y)。将Pb(x, y)发送至客户端。
（3）：客户端计算Sa(x, y) = Ra * Pb(x, y)；服务器计算Sb(x, y) = Rb *Pa(x, y)
（4）：算法保证了Sa = Sb = S，提取其中的S的x向量作为密钥（预主密钥）。
@引用
---------------------
作者：Mrpre
来源：CSDN
原文：https://blog.csdn.net/mrpre/article/details/78025940
版权声明：本文为博主原创文章，转载请附上博文链接！作者回复: 非常好的同学，大力表扬！
2019-08-01 1 9
magicnum比如TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256：使用ECDHE进行密钥交换（文中已经讲了，用它算出Pre_Master，成会话密钥Master Secret。密钥交换过程中应该会使用到非对称加密中的公钥加密），RSA进行身份验证（私钥加密公钥解密），使用128位GCM分组工作模式的AES进行消息和会话密钥的对称加密（加密真正的消息），使用SHA256摘要算法（如HMAC、PRM）对数据签名，保证数据完整性作者回复: 说的很好。
2019-07-26 1 5
极夜老师，我通过nslookup获得百度的一个ip为180.101.49.11，然后用https://180.101.49.11访问，浏览器会提示建立的连接不安全。在chrome浏览器的security页面中，连接走的还是TLS , 但该网页缺失认证。我的理解是，证书在访问网页的时候就返回了，但证书只能证明某个公钥是属于某个域名的，不能证明公钥是否归属某个IP，是不是这样呢？作者回复: 这是因为申请证书的时候一般都是绑定在域名上，证书证明的是域名而不是ip，所以无法验证网址的合法性。
如果申请证书时就绑定ip，那么就没问题了，但几乎没有人会这么做，因为ip地址会变，而域名通常是稳定的。2019-08-30 3
一坛幽梦老师，还是没有明白服务端/客户端发送public key的用途是什么，麻烦老师再重点说一下，感谢！作者回复: 服务器客户端不会直接发送public key，如果你指的是密钥交换的过程，它实际上是ECDHE算法锁要求的参数，交换这些参数就可以在两边分别算出pre-master，而外部的黑客是无法计算得到的。
发送证书是为了配合私钥签名验证客户端或服务器是身份，只要签名对，就说明对方是证书所标记的实体。2019-08-17 2
亚洲舞王.尼古拉斯赵四第二个问题：客户端使用tcp链接明文将自己的随机数、密码套件、tls版本号发送给服务端，服务端根据自己支持的密码套件从客户端的密码套件中选取一个最合适的密码套件，协商出tls版本，将协商好的密码套件、tls版本以及自己的随机数明文告诉客户端，并将自己的证书发送给客户端，并结束
客户端收到证书之后去ca一级一级验证证书的有效性，验证通过后，客户端使用随机数生成pre-master并 用服务器的公钥进行加密传给服务端，服务端使用自己的私钥进行解密，使用解密后的值与客户端随机数，自己的随机数进行计算，得出master secret；这时候，客户端使用三个值也能计算出master secret，客户端告诉服务器我之后都使用加密进行通信了，结束；服务端也告诉客户端，我也要开始使用加密通信了，over
接下来两个人使用计算出来的master secret进行消息加密，两人balabala，并使用master secret进行解密作者回复: good。
2019-08-07 2
Neo老师好，请教一下“双向验证”的问题：
1. 双向验证，是不是客户端和服务器端协商决定的？
例如我用浏览器访问这个测试网址：https://server.cryptomix.com/secure/ 会弹出选择客户端证书的窗口。如果是的话，服务器怎么让客户端知道需要客户端证书的？
2. 您在客户作业中提到“画出双向验证的流程图”，我自己还没有理解到，留言区似乎也还没有答案，您能公布答案么？谢谢🙏作者回复:
1.服务器会发出一个Certificate Request消息，要求客户端提供证书，这样在ServerHelloDone消息后，客户端就会发送Client Certificate提供客户端证书。
2.双向认证的流程就在ServerHelloDone消息后多了个客户端证书，比较简单，看后面有时间再补充一篇答疑吧。2019-11-22 1
🌞🇨🇳👦在上一课中，讲到ecdhe非对称加密算法可以不等服务器返回finished就直接抢跑发送数据，相当于1个rtt。tls1.3这里好像并没有实际上减少握手时间？作者回复: 是的，但false start是有条件的（ecdhe），如果用rsa就是2-rtt。
而tls1.3是无条件，一定是1-rtt，而且它还有0-rtt。2019-08-07 1
J.D.看的有点晚，面试的时候问了 Https 的连接过程.......作者回复: 没事，现在学会了也不晚，更好的机会在等着你。
2019-08-05 1- 彩色的沙漠请问老师我在Wireshark 设置过滤器tcp.port==443 查看抓包，有很多其他TCP包也被抓到了，过滤的不彻底，老师的过滤器tcp port 443 在哪设置？谢谢！
作者回复: wireshark启动后的初始界面，“使用这个过滤器”，在文本框里输入。
2019-08-05 1 
叶佳欣老师，问下。Server Key Exchange需要用私钥签名认证。那Client Key Exchange会用公钥加密下吗，如果不会，为什么不像传统握手把pre-master用公钥加密发送给server？作者回复: pre-master的交换方式是由密钥交换算法决定的，如果是rsa就直接公钥加密，如果是ecdhe就要用算法参数。
这些都要按照tls协议来，Client Key Exchange已经由密钥交换算法保证了安全，所以不需要再加密或者签名。
如果是双向认证，那么客户端会发送客户端的证书，也要做签名认证，让服务器验证身份。2019-07-31 1
丶景老师好，RSA 握手过程下面有个不明白的地方，使用 ECDHE 可以不用等到服务器发回“Finish”立即就发出 HTTP 报文。使用 RSA 为什么就不可以先发出 HTTP 报文？作者回复: 这个只能说是fasle start协议的规定，其实rsa也可以抢先发出报文，但没有人这么用。
2019-07-26 1- 丶景Pre-Master Secret 这个不理解，是说客户端和服务器分别通过 Client Params 和 Server Params 都能计算出一样的 Pre-Master Secret 吗？如果是，为什么中间人算不出？
作者回复: 这是由DH算法决定的，DH算法是专门用作密钥交换的，它本身能够保证交换安全，具体的细节一下子说不清楚，你可以搜一下相关的资料。
2019-07-26 1 
许童童老师讲得好啊，现在完全理解了，往返最多两次，之前一直理解很得模糊。作者回复: 可以把自己理解的过程写出来，这样才能说明真正弄懂了。
2019-07-26 1 1
大小兵请问一下老师，上面的握手过程是不是没有用到非对称加密啊？如果没有用到那非对称加密什么时候用呢？作者回复: 有啊，在握手里用ecdhe交换pre-master，之前有发送证书，验证书就有非对称加密。
可以看一下双方商定的密码套件，看看里面的算法都用在了哪个环节。2019-07-26 1
何用Client Params 和 Server Params 都可以被截获，为何中间人没法通过这两个信息计算 Pre-Master Secret 呢？作者回复: 由密钥交换算法保证，比如rsa、ecdhe。
2019-07-26 1
Leon📷如果想测试公网的https服务报文，是不是把浏览器端的私钥导入wireshark就可以了作者回复: 不用，只要设置了环境变量SSLKEYLOGFILE，wireshark就可以从日志里读取握手过程中的信息，相当于浏览器告诉了wireshark pre-master，所以就可以解密。
不需要任何私钥。2019-07-26 1
Ben有个疑问没有想清楚：client在发送“client key exchange”消息之前需要把client的证书发送给server吗？
我在想server发送给client的“server key exchange”消息需要签名认证，那么client发送给server的“client key exchange”难道不需要签名认证吗？
如果需要签名认证的话，那么是不是就需要先把client的证书发送给server做验证。作者回复:
1.服务器会发出一个Certificate Request消息，要求客户端提供证书，这样在ServerHelloDone消息后，客户端就会发送Client Certificate提供客户端证书。如果没有Certificate Request客户端就不必提供证书。
2.tls握手分双向认证和单向认证两种，我们通常都用的是单向认证，即客户端认证服务器，服务器不认证客户端。
因为毕竟私钥签名比较费时间，而且给成千上万的客户端都颁发证书不太现实。单向认证通过后，可以再用用户名+口令的方式来验证客户端的身份。
3.少数场合，比如网银，为了加强安全，就会使用双向认证，确保通信双方的身份不被伪造。2019-12-10
ddq432还有一个问题，在服务器发送证书给客户端的时候，还有一个数字签名，这个签名是在什么时候使用的作者回复: 签名用来验证之前发送的握手数据，保证不会被窜改。
2019-12-06- ddq432有一点不是很明白，服务器把证书给客户端之后，客户端是依据什么来判断 这个证书是合法的证书？它是根据什么匹配它自己是哪一家ca颁发的呢？还有，服务器的公钥是在这个证书里面的吧？只不过是被第三方的认为可靠的机构进用他们自己的私钥加密了，那第三方的公钥从哪里得到呢，是被直接内置到客户端里面的吗？我比较笨，希望老师解惑
作者回复: 可参考前两讲，证书是使用ca的证书来验证是否合法的，走证书链，链的源头的自证明的根证书。
第三方也就是ca的公钥私钥是自己生成，自己签名的。著名的ca的证书都会被内置到操作系统或者浏览器里。
当然服务器也可以直接在证书链里发送根证书，但这样比较浪费带宽，一般不这样做。2019-12-06 
张智凯使用ECDHE-RSA-AES256-GCM-SHA384加密套件进行TLS握手的过程
1 客户端向服务器端发送clienthello请求，请求的内容里包括客户端支持的TLS版本号、支持的加密套件列表、客户端随机数
2 收到客户端的请求后，服务器端向客户端发送serverhello请求，请求里包括服务器选择的TLS版本号、选择的加密套件、服务器端随机数。
3 服务器端接着向客户端发送自己的证书链
4 服务器向可客户端发送exchangekey请求，因为选择的的套件的密钥交换算法是ECDHE，所以请求里包括 密钥交换算法的椭圆曲线的名称、基点信息、以及交换算法所需要的一个参数公钥serverparam，然后服务器会对上面这些信息使用摘要算法SHA384做哈希，然后对哈希结果使用证书里的公钥对应的私钥进行加密，即签名来证实自己的身份
5 服务器发送server hello done
6客户端收到服务器的证书后会查找本地的根证书，从证书链的顶级，逐级向下验证，验证通过后，会向服务器端发送client key exchange请求，请求里的内容是椭圆曲线算法需要的另一个公钥client paramsEDCH
7 客户端发送change cipher spec接着通过 ECDHE的两个算法以及两个param算出 pre-master secret，并同过pre-master secret以及两个随机数，算出master-key，以及其他会话传输的密钥
8 客户端发送finished，并对之前发过的信息进行摘要，并使用master-key加密？
9 服务器收到请求后发送change cipher spec，会通过ECDHE算法以及两个param算出一个pre-master secret，然后利用客户端随机数、服务器随机数、pre-master secret得到server secret以及一系列得其他会话密钥。
10 服务器发送finished，并对之前发送的消息做摘要算法，并使用master-key加密
自此TLS握手阶段就完成了，后面使用master-key加密后的http协议进行通信
有三个疑问：
1 ， EDCHE算法的问题，都是两个参数，以及一个函数，而且都是明文传递的，为什么黑客得不到pre-master secret，难道还要其中一个param对应得私钥才行？
2 后面的http正文的加密是使用master-key吗，master-key是对称加密算法的密钥？
3 我们只选择了套件，对称加密的密钥是通过条件里的对称加密算法根据两个随机数以及对称加密赛算法生成的？作者回复:
1.可参见答疑篇，详细介绍了ECDHE算法。
2.master key顾名思义，只是主密钥，还会再派生出多个用途各不相同的密钥，例如客户端发送数据用client_write_key，这点课程里简单提了一下。
3.理解的有点小偏差，对称密钥，也就是会话密钥是由master key生成的，而master key是由之前密钥交换过程中的三个随机数生成的。前两个随机数公开，而第三个随机数Pre-Master是由ecdhe算法保证了交换安全。2019-11-01 1