HTTPS ECDHE 握手解析
RSA是比较传统的密钥交换算法，它不具备前向安全的性质，因此现在很少服务器使用。ECDHE具有前向安全，所以被广泛使用。
ECDHE算法
- 双方事先确定好使用哪种椭圆曲线，和曲线上的基点G，这两个参数是公开的
- 双方各自随机生成一个随机数作为私钥d，并与基点G相乘得到公钥Q（Q=dG），此时客户端的公私钥为Q1和d1，服务端公私钥为Q2和d2
- 双方交换各自的公钥，最后客户端计算点（x1，y1）=d1Q2，服务端计算点（x2，y2）=d2Q1，由于椭圆曲线上是可以满足乘法交换和结合律的，所以d1Q2=d1d2G=d2d1G=d2Q1，因此双方的x坐标是一样的，所以它是共享密钥，也就是会话秘钥
这个过程功中，双方的私钥都是随机和临时生成的，都是不公开的，即使根据公开的信息（椭圆曲线、公钥、基点G）也是很难计算出椭圆曲线上的离散对数（私钥）。
ECDHE握手过程
第一次握手
- 客户端发送一个Client Hello，消息里面有客户端使用的TLS版本号、支持的密码套件列表、以及生成的数据数 Client Random
第二次握手
- 服务端收到客户端的招呼，返回Server Hello消息，里面有服务器确认的TLS版本号、随机数 Server Random、客户端列表里选择一个合适的密码套件。
- 接着服务端为证明自己身份，发送Certificate消息，把证书发给客户端
- 因为服务端选择了ECDHE密钥协商算法，所以在发送完证书后，发送Server Key Exchange消息。这个过程做了3件事
- 选择椭圆曲线，选好椭圆曲线相当于椭圆曲线基点G也定好了，这些都会公开给客户端
- 生成随机数作为服务端椭圆曲线的私钥，保留到本地
- 根据基点G和私钥计算出服务端的椭圆曲线公钥，这个会公开给客户端。为保证椭圆曲线公钥不被第三方篡改，服务端会用RAS签名算法给公钥做签名
- 随后就是Server Hello Done消息，表明服务端的招呼消息完毕
至此，两次握手完成，目前客户端和服务端通过明文共享了这几个信息：Client Random、Server Random、使用的椭圆曲线、椭圆曲线的基点G、服务端椭圆曲线的公钥。
第三次握手
- 客户端收到服务端证书后，要校验证书是否合法。校验证书的过程会走证书链逐级验证，确认证书的真实性，再用证书的公钥验证签名，这样就能确认服务端身份。
- 客户端生成一个随机数作为客户端椭圆曲线的私钥，然后再根据服务端前面给的信息，生成客户端的公钥，然后用Cliennt Key Exchange消息发送给服务端
至此，双方都有对方的椭圆曲线公钥、自己的椭圆曲线私钥、椭圆曲线基点G。于是双方都计算出点（x，y），其中x坐标值双方都是一样的，前面说ECDHE算法的时候，，说x是会话秘钥，但实际中，x还不是最终的会话秘钥。最终的会话秘钥，是用客户端随机数+服务端随机数+x，三个材料生成的。
之所以这么麻烦，是因为TLS设计者不信任客户端或服务器伪随机数的可靠性，为了保证真正的完全随机，把三个不可靠的随机数混合起来，那么随机的程度就非常高了。
- 算好秘钥后，客户端会发出一个Change Cipher Spec消息，告诉服务端后续改用对称加密算法通信
第四次握手
- 服务端发送Change Cipher Spec和Encrypted Handshake Message消息，如果双方都验证加解密没问题，那么握手正式完成。
总结
RSA和ECDHE握手过程的区别：
- RSA不支持前向保密
- RSA密钥协商算法，TLS完成四次握手后才能进行应用数据传输。而ECDHE算法，客户端可以不用等待服务端的最后一次TLS我收，就可以提前发出加密的HTTP数据，节省一个消息的往返时间
- 使用ECDHE，在TLS第二次握手中，会出现服务端发出的Server Key Exchange消息，而RSA握手过程没有。
