TLS/SSL 协议详解(12) server key exchange

对于使用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”，如上图高亮部分，这是TLS1.2协议相较于之前协议不同之处之一，但是这2部分不参与签名计算。

 

 

1：DHE下，server key exchange 如下图

 

    1：指明自己使用的DH参数，p和g。

 

    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