26 | 信任始于握手：TLS1.2连接过程解析

浏览留言区，留言区同学和我有一样的疑问“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 版权声明：本文为博主原创文章，转载请附上博文链接！

之前面试阿里第二轮的时候，面试官就问我关于ssl握手的问题，其实我觉得像这种问题回答不出来也很正常，毕竟这么复杂的流程谁能记得住呢？使用现成的nginx+ssl的配置已经可以解决大多数问题了。 ------------------------------------------------- 总结下TLS的握手过程： 第一阶段：C/S两端共享Client Random、Server Random 和 Server Params信息 客户端--->服务器： 客户端的版本号、支持的密码套件，还有一个随机数（Client Random） 服务端--->客户端： 客户端的版本号、选择的客户端列表的密码套件如：TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384、随机数随机数（Server Random） 服务端--->客户端： 服务端证书（Server Certificate） 服务端--->客户端： 发送Server Key Exchange类型的请求，携带椭圆曲线的公钥（Server Params）用以实现密钥交换算法，另附私钥签名 服务端--->客户端： 发送完毕 第二阶段：证书验证 前验条件：客户端证书链逐级验证、证书公钥验证签名，服务端身份验证成功（证书合法） 客户端--->服务端 发送Client Key Exchange类型的请求，携带椭圆曲线的公钥（Client Params）用以实现秘钥交换算法 第三阶段：主密钥生成 客户端、服务端分别使用Client Params、Server Params通过ECDHE算法计算出随机值pre-master，然后用 Client Random、Server Random 和 Pre-Master三个值作为原材料，用PRF伪随机数函数（利用密码套件的摘要算法再次强化结果 值maser secert的随机性）计算出主密钥Master Secret， 主密钥并不是会话秘钥，还会再用PRF扩展出更多的密钥，比如客户端发送用的会话密钥（client_write_key）、服务器发送用的会话密钥（server_write_key） 客户端--->服务端: 客户端发一个“Change Cipher Spec”，然后再发一个“Finished”消息，把之前所有发送的数据做个摘要，再加密一下，让服务器做个验证. 服务端--->客户端： 服务器也是同样的操作，发“Change Cipher Spec”和“Finished”消息，双方都验证加密解密 OK，握手正式结束.

老师，我通过nslookup获得百度的一个ip为180.101.49.11，然后用https://180.101.49.11访问，浏览器会提示建立的连接不安全。在chrome浏览器的security页面中，连接走的还是TLS , 但该网页缺失认证。我的理解是，证书在访问网页的时候就返回了，但证书只能证明某个公钥是属于某个域名的，不能证明公钥是否归属某个IP，是不是这样呢？

第二个问题：客户端使用tcp链接明文将自己的随机数、密码套件、tls版本号发送给服务端，服务端根据自己支持的密码套件从客户端的密码套件中选取一个最合适的密码套件，协商出tls版本，将协商好的密码套件、tls版本以及自己的随机数明文告诉客户端，并将自己的证书发送给客户端，并结束 客户端收到证书之后去ca一级一级验证证书的有效性，验证通过后，客户端使用随机数生成pre-master并 用服务器的公钥进行加密传给服务端，服务端使用自己的私钥进行解密，使用解密后的值与客户端随机数，自己的随机数进行计算，得出master secret；这时候，客户端使用三个值也能计算出master secret，客户端告诉服务器我之后都使用加密进行通信了，结束；服务端也告诉客户端，我也要开始使用加密通信了，over 接下来两个人使用计算出来的master secret进行消息加密，两人balabala，并使用master secret进行解密

老师，你看看我这样理解对吗？ ECDHE中，没有采用服务器公钥来加密数据，而是采用交换两端的椭圆曲线公钥来保证pre_master的安全性 RSA中pre_master由客户端生成，采用服务器公钥加密pre_master来保证pre_master的安全性

比如TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256：使用ECDHE进行密钥交换（文中已经讲了，用它算出Pre_Master，成会话密钥Master Secret。密钥交换过程中应该会使用到非对称加密中的公钥加密），RSA进行身份验证（私钥加密公钥解密），使用128位GCM分组工作模式的AES进行消息和会话密钥的对称加密（加密真正的消息），使用SHA256摘要算法（如HMAC、PRM）对数据签名，保证数据完整性

在非对称加密算法中，公钥是公开信息，不需要保密,那用私钥加密，公钥解密的话（验证签名过程），其他知道公钥的人也可以解密，怎么确认发送者的身份？

“主密钥有 48 字节，但它也不是最终用于通信的会话密钥，还会再用 PRF 扩展出更多的密钥，比如客户端发送用的会话密钥（client_write_key）、服务器发送用的会话密钥（server_write_key）等等，避免只用一个密钥带来的安全隐患。”这个没太理解，这个不一样的会话密钥，在对称加密算法中怎么解密呢？

老师，以下问题，麻烦回答一下： 1.为了更好地分析 TLS 握手过程，你可以再对系统和 Wireshark 做一下设置，让浏览器导出握手过程中的秘密信息，这样 Wireshark 就可以把密文解密，还原出明文。这不是明文传输的嘛？ Wireshark 就可以把密文解密这句话是不是有问题啊？ 2.浏览器直接发送的TLS1.2的版本，那么为什么只发这个，不发TLS1.3的呢？ 3.这里服务器是不是有两套公私钥，一个是证书的公私钥，一个是椭圆曲线的公私钥匙。服务器在证书后发送“Server Key Exchange”消息之后的签名用的是证书的私钥加密的？

老师，还是没有明白服务端/客户端发送public key的用途是什么，麻烦老师再重点说一下，感谢！