社区微信群开通啦，扫一扫抢先加入社区官方微信群
社区微信群
对于使用DHE/ECDHE非对称密钥协商算法的SSL握手，将发送该类型握手。
RSA算法不会继续该握手流程（DH、ECDH也不会发送server key exchange）。
1：ECDHE下，server key exchange 如下图
ECDHE下主要有几点重要的信息
1：指明自己使用的椭圆曲线（一般根据客户端的拓展中supported_groups中的选择椭圆曲线算法）。
2：公钥。服务器本地计算一个大数（BIGNUM），乘上曲线的base point，得到一个新的point，这个point就是公钥，用04+x+y的格式组织起来。04表示unconpressed point，和客户端的ec_point_formats有关。
3：签名。和RSA握手不通，RSA情况下， 只要能值正常协商密钥，那么必然服务器端有证书对应的私钥，也间接表明了服务器拥有该证书。DHE/ECDHE不同，证书对应的私钥并不参与密钥协商，如果要证明服务器拥有证书，则必然有签名的操作（就像双向认证的情况下，客户端需要发送certificate verify）。被签名数据从curve type起，至point的y为止。对于TLS1.2，签名前使用client hello拓展中提供的摘要算法。TLS1.0和TLS1.1，如果本地证书是ECC证书，即若要使用ECDSA签名，这种摘要算法为SHA1，其他的情况摘要算法为md5+sha1。
计算摘要之后就调用RSA或者ECDSA进行签名。注意的是，TLS1.2时要带上2字节的“Signature Hash Algorithm”。
1：DHE下，server key exchange 如下图
2：客户端计算私钥key1，计算g^key1 mod p，将结果pub1发给服务器端，自己仅且自己保存key1。
服务器端计算私钥key2，计算g^key12 mod p，将结果pub2发给客户端，自己仅且自己保存key2。（本报文中的Pubkey就是该值）
客户端计算 pub2^key1 mod p。服务器计算pub1^key2 mod p，得出pre_master_key。
3：签名流程与上述类似，不再赘述。
关于ECDHE、DHE算法，详见我的博客：
http://blog.csdn.net/mrpre/article/details/78025940
如果觉得我的文章对您有用，请随意打赏。你的支持将鼓励我继续创作！
