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

TLS 同时被 2 个专栏收录
43 篇文章 12 订阅
38 篇文章 142 订阅

对于使用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

  • 2
    点赞
  • 10
    评论
  • 5
    收藏
  • 一键三连
    一键三连
  • 扫一扫,分享海报

©️2021 CSDN 皮肤主题: 大白 设计师:CSDN官方博客 返回首页
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值