【TLS】ECDHE得到密钥后会发生什么

网络太差了，我先写点别的东西，敷衍一下。。。
网络好了以后，再继续迷雾通第二篇！

===============正文开始===================
扫盲地址
https://wiki.openssl.org/index.php/Elliptic_Curve_Diffie_Hellman

注意到一句话
/* Never use a derived secret directly. Typically it is passed
* through some hash function to produce a key */

也就是说，服务器收到浏览器的ClientHello以后，计算得到了premaster secret不会直接作为AES的密钥来使用！那么，我们就会思考一个问题，那么AES的密钥到底是怎么来的呢？

通过HKDF算法[https://suntus.github.io/2019/05/09/HKDF%E7%AE%97%E6%B3%95/]

具体代码，我以火狐来讲解【因为Tor浏览器的代码基于火狐~】
打开代码文件security\nss\lib\ssl\tls13con.c
浏览器收到服务器返回的ServerHello，进入处理函数 tls13_HandleServerHelloPart2
跟着调用 tls13_HandleServerKeyShare 得到 ECDHE协商出来的 premaster secret密钥
然后调用 tls13_ComputeHandshakeSecrets 得到 HKDF以后的真正密钥！
其中 tls13_HandleServerKeyShare 内部调用了 tls13_HandleKeyShare 来计算得到ss->ssl3.hs.dheSecret【ecdhe协商出来的原始密钥，后面要用到】
因为过程就是github.io里说的那样，我就不废话了！！！

回过头看server端部分：
服务器收到 浏览器的ClientHello以后，进入 tls13_HandleClientHelloPart2函数
进入 tls13_HandleClientKeyShare 函数
然后是 tls13_HandleKeyShare 得到了 原始密钥
接下来是HKDF部分
看函数 tls13_SendServerHelloSequence -> tls13_SendEncryptedServerSequence
tls13_ComputeHandshakeSecrets，走到这里，就和客户端的流程一样，所以得到了同样的密钥