2019-08-01浏览留言区，留言区同学和我有一样的疑问“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
版权声明：本文为博主原创文章，转载请附上博文链接！展开作者回复: 非常好的同学，大力表扬！
2 12
2019-07-26比如TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256：使用ECDHE进行密钥交换（文中已经讲了，用它算出Pre_Master，成会话密钥Master Secret。密钥交换过程中应该会使用到非对称加密中的公钥加密），RSA进行身份验证（私钥加密公钥解密），使用128位GCM分组工作模式的AES进行消息和会话密钥的对称加密（加密真正的消息），使用SHA256摘要算法（如HMAC、PRM）对数据签名，保证数据完整性作者回复: 说的很好。
1 6
2019-08-07第二个问题：客户端使用tcp链接明文将自己的随机数、密码套件、tls版本号发送给服务端，服务端根据自己支持的密码套件从客户端的密码套件中选取一个最合适的密码套件，协商出tls版本，将协商好的密码套件、tls版本以及自己的随机数明文告诉客户端，并将自己的证书发送给客户端，并结束
客户端收到证书之后去ca一级一级验证证书的有效性，验证通过后，客户端使用随机数生成pre-master并 用服务器的公钥进行加密传给服务端，服务端使用自己的私钥进行解密，使用解密后的值与客户端随机数，自己的随机数进行计算，得出master secret；这时候，客户端使用三个值也能计算出master secret，客户端告诉服务器我之后都使用加密进行通信了，结束；服务端也告诉客户端，我也要开始使用加密通信了，over
接下来两个人使用计算出来的master secret进行消息加密，两人balabala，并使用master secret进行解密展开作者回复: good。
4
2019-08-30老师，我通过nslookup获得百度的一个ip为180.101.49.11，然后用https://180.101.49.11访问，浏览器会提示建立的连接不安全。在chrome浏览器的security页面中，连接走的还是TLS , 但该网页缺失认证。我的理解是，证书在访问网页的时候就返回了，但证书只能证明某个公钥是属于某个域名的，不能证明公钥是否归属某个IP，是不是这样呢？作者回复: 这是因为申请证书的时候一般都是绑定在域名上，证书证明的是域名而不是ip，所以无法验证网址的合法性。
如果申请证书时就绑定ip，那么就没问题了，但几乎没有人会这么做，因为ip地址会变，而域名通常是稳定的。 3
2019-08-17老师，还是没有明白服务端/客户端发送public key的用途是什么，麻烦老师再重点说一下，感谢！作者回复: 服务器客户端不会直接发送public key，如果你指的是密钥交换的过程，它实际上是ECDHE算法锁要求的参数，交换这些参数就可以在两边分别算出pre-master，而外部的黑客是无法计算得到的。
发送证书是为了配合私钥签名验证客户端或服务器是身份，只要签名对，就说明对方是证书所标记的实体。 3
2019-07-26Client Params 和 Server Params 都可以被截获，为何中间人没法通过这两个信息计算 Pre-Master Secret 呢？作者回复: 由密钥交换算法保证，比如rsa、ecdhe。
2
2020-01-19之前面试阿里第二轮的时候，面试官就问我关于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，握手正式结束.展开作者回复: 总结的非常好。
1
2019-12-18老师，以下问题，麻烦回答一下：
1.为了更好地分析 TLS 握手过程，你可以再对系统和 Wireshark 做一下设置，让浏览器导出握手过程中的秘密信息，这样 Wireshark 就可以把密文解密，还原出明文。这不是明文传输的嘛？ Wireshark 就可以把密文解密这句话是不是有问题啊？
2.浏览器直接发送的TLS1.2的版本，那么为什么只发这个，不发TLS1.3的呢？
3.这里服务器是不是有两套公私钥，一个是证书的公私钥，一个是椭圆曲线的公私钥匙。服务器在证书后发送“Server Key Exchange”消息之后的签名用的是证书的私钥加密的？展开作者回复:
1.对于tls通信的双方来说，tls只是加密了通信链路，在通信的两个端点必然是要解密的，也就是明文，不然就无法操作了。
设置系统和wireshark就是告诉浏览器，把密钥导出来，然后wireshark用这个密钥来解密，但传输的数据仍然是加密的，如果没有这个密钥wireshark也是看不出明文的。
密文解密的前提是有密钥，如果没有密钥通信就是安全的。
2.看后面一讲，介绍了tls1.3，这里就不重复了。
3.是的。椭圆曲线的密钥用于ecdhe交换会话密钥，证书的私钥用来身份验证，对消息签名。
但椭圆曲线的密钥是临时生成的，每次握手都不固定，见答疑篇。 1
2019-11-22老师好，请教一下“双向验证”的问题：
1. 双向验证，是不是客户端和服务器端协商决定的？
例如我用浏览器访问这个测试网址：https://server.cryptomix.com/secure/ 会弹出选择客户端证书的窗口。如果是的话，服务器怎么让客户端知道需要客户端证书的？
2. 您在客户作业中提到“画出双向验证的流程图”，我自己还没有理解到，留言区似乎也还没有答案，您能公布答案么？谢谢🙏作者回复:
1.服务器会发出一个Certificate Request消息，要求客户端提供证书，这样在ServerHelloDone消息后，客户端就会发送Client Certificate提供客户端证书。
2.双向认证的流程就在ServerHelloDone消息后多了个客户端证书，比较简单，看后面有时间再补充一篇答疑吧。 1
2019-08-07在上一课中，讲到ecdhe非对称加密算法可以不等服务器返回finished就直接抢跑发送数据，相当于1个rtt。tls1.3这里好像并没有实际上减少握手时间？作者回复: 是的，但false start是有条件的（ecdhe），如果用rsa就是2-rtt。
而tls1.3是无条件，一定是1-rtt，而且它还有0-rtt。 1
2019-08-05看的有点晚，面试的时候问了 Https 的连接过程.......作者回复: 没事，现在学会了也不晚，更好的机会在等着你。
1- 2019-08-05请问老师我在Wireshark 设置过滤器tcp.port==443 查看抓包，有很多其他TCP包也被抓到了，过滤的不彻底，老师的过滤器tcp port 443 在哪设置？谢谢！
作者回复: wireshark启动后的初始界面，“使用这个过滤器”，在文本框里输入。
1 
2019-07-31老师，问下。Server Key Exchange需要用私钥签名认证。那Client Key Exchange会用公钥加密下吗，如果不会，为什么不像传统握手把pre-master用公钥加密发送给server？作者回复: pre-master的交换方式是由密钥交换算法决定的，如果是rsa就直接公钥加密，如果是ecdhe就要用算法参数。
这些都要按照tls协议来，Client Key Exchange已经由密钥交换算法保证了安全，所以不需要再加密或者签名。
如果是双向认证，那么客户端会发送客户端的证书，也要做签名认证，让服务器验证身份。 1
2019-07-26老师好，RSA 握手过程下面有个不明白的地方，使用 ECDHE 可以不用等到服务器发回“Finish”立即就发出 HTTP 报文。使用 RSA 为什么就不可以先发出 HTTP 报文？作者回复: 这个只能说是fasle start协议的规定，其实rsa也可以抢先发出报文，但没有人这么用。
1- 2019-07-26Pre-Master Secret 这个不理解，是说客户端和服务器分别通过 Client Params 和 Server Params 都能计算出一样的 Pre-Master Secret 吗？如果是，为什么中间人算不出？
作者回复: 这是由DH算法决定的，DH算法是专门用作密钥交换的，它本身能够保证交换安全，具体的细节一下子说不清楚，你可以搜一下相关的资料。
1 
2019-07-26老师讲得好啊，现在完全理解了，往返最多两次，之前一直理解很得模糊。作者回复: 可以把自己理解的过程写出来，这样才能说明真正弄懂了。
1 1
2019-07-26请问一下老师，上面的握手过程是不是没有用到非对称加密啊？如果没有用到那非对称加密什么时候用呢？作者回复: 有啊，在握手里用ecdhe交换pre-master，之前有发送证书，验证书就有非对称加密。
可以看一下双方商定的密码套件，看看里面的算法都用在了哪个环节。 1
2019-07-26如果想测试公网的https服务报文，是不是把浏览器端的私钥导入wireshark就可以了作者回复: 不用，只要设置了环境变量SSLKEYLOGFILE，wireshark就可以从日志里读取握手过程中的信息，相当于浏览器告诉了wireshark pre-master，所以就可以解密。
不需要任何私钥。 1
2020-02-08请教下：Pre-Master的计算是在客户端完成的，还是服务端完成的呢，还是双方一起算，而且算出来的都是一样的？作者回复: 两端同时计算，根据算法，会得到相同的结果，可以参考一下示意图。
2020-02-03老师，因为使用了 ECDHE，客户端可以不用等到服务器发回“Finished”确认握手完毕，立即就发出 HTTP 报文，省去了一个消息往返的时间浪费。。这个没看懂，rsa为啥不行？作者回复: 这个是rfc的规定，只允许ecdhe使用false start。
背后的真正原因是什么我也不太清楚，可能还是因为rsa不支持前向安全吧。