HTTPS ECDHE握手内容解析

这篇具有很好参考价值的文章主要介绍了HTTPS ECDHE握手内容解析。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

  • HTTPS 常用的密钥交换算法有两种,分别是 RSA 和 ECDHE 算法。

  • 离散对数

    • DH 算法是非对称加密算法, 因此它可以用于密钥交换,该算法的核心数学思想是离散对数。

      • 对数运算的取值是可以连续的,而离散对数的取值是不能连续的,因此也以「离散」得名

      • 离散对数是在对数运算的基础上加了「模运算」,也就说取余数,对应编程语言的操作符是「%」,也可以用 mod 表示。离散对数的概念如下图

        • 底数 a 和模数 p 是离散对数的公共参数,也就说是公开的,b 是真数,i 是对数

        • 特别是当模数 p 是一个很大的质数,即使知道底数 a 和真数 b ,在现有的计算机的计算水平是几乎无法算出离散对数的,这就是 DH 算法的数学基础。

    • DH算法

    • DHE算法

      • DH分为两种

        • static DH 算法,这个是已经被废弃了;

        • DHE 算法,现在常用的;

      • static DH 算法里有一方的私钥是静态的,也就说每次密钥协商的时候有一方的私钥都是一样的,一般是服务器方固定,即 a 不变,客户端的私钥则是随机生成的。

        • DH 交换密钥时就只有客户端的公钥是变化,而服务端公钥是不变的,那么随着时间延长,黑客就会截获海量的密钥协商过程的数据,因为密钥协商的过程有些数据是公开的,黑客就可以依据这些数据暴力破解出服务器的私钥,然后就可以计算出会话密钥了,于是之前截获的加密数据会被破解,所以 static DH 算法不具备前向安全性。

      • 既然固定一方的私钥有被破解的风险,那么干脆就让双方的私钥在每次密钥交换通信时,都是随机生成的、临时的,这个方式也就是 DHE 算法,E 全称是 ephemeral(临时性的)。

      • 即使有个牛逼的黑客破解了某一次通信过程的私钥,其他通信过程的私钥仍然是安全的,因为每个通信过程的私钥都是没有任何关系的,都是独立的,这样就保证了「前向安全」

    • ECDHE算法

      • DHE 算法由于计算性能不佳,因为需要做大量的乘法,为了提升 DHE 算法的性能,所以就出现了现在广泛用于密钥交换算法 —— ECDHE 算法。

      • ECDHE 算法是在 DHE 算法的基础上利用了 ECC 椭圆曲线特性,可以用更少的计算量计算出公钥,以及最终的会话密钥。

      • 握手过程

        • 使用了 ECDHE,在 TLS 第四次握手前,客户端就已经发送了加密的 HTTP 数据,而对于 RSA 握手过程,必须要完成 TLS 四次握手,才能传输应用数据。

        • ECDHE 相比 RSA 握手过程省去了一个消息往返的时间,这个有点「抢跑」的意思,它被称为是「TLS False Start」,跟「TCP Fast Open」有点像,都是在还没连接完全建立前,就发送了应用数据,这样便提高了传输的效率。

        • TLS第一次握手

          • 客户端首先会发一个「Client Hello」消息,消息里面有客户端使用的 TLS 版本号、支持的密码套件列表,以及生成的随机数(Client Random)。

        • TLS第二次握手

          • 服务端收到客户端的「打招呼」,同样也要回礼,会返回「Server Hello」消息,消息面有服务器确认的 TLS 版本号,也给出了一个随机数(Server Random),然后从客户端的密码套件列表选择了一个合适的密码套件。

          • 不过,这次选择的密码套件就和 RSA 不一样了 「 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384」

            • 密钥协商算法使用 ECDHE;

            • 签名算法使用 RSA;

            • 握手后的通信使用 AES 对称算法,密钥长度 256 位,分组模式是 GCM;

            • 摘要算法使用 SHA384;

          • 服务端为了证明自己的身份,发送「Certificate」消息,会把证书也发给客户端。

          • 这一步就和 RSA 握手过程有很大的区别了,因为服务端选择了 ECDHE 密钥协商算法,所以会在发送完证书后,发送「Server Key Exchange」消息。

          • 这个过程服务器做了三件事

            • 选择了名为 x25519 的椭圆曲线,选好了椭圆曲线相当于椭圆曲线基点 G 也定好了,这些都会公开给客户端;

            • 生成随机数作为服务端椭圆曲线的私钥,保留到本地;

            • 根据基点 G 和私钥计算出服务端的椭圆曲线公钥,这个会公开给客户端。

          • 为了保证这个椭圆曲线的公钥不被第三方篡改,服务端会用 RSA 签名算法给服务端的椭圆曲线公钥做个签名。

          • 就是「Server Hello Done」消息,服务端跟客户端表明:“这些就是我提供的信息,打招呼完毕”。

          • 至此,TLS 两次握手就已经完成了,目前客户端和服务端通过明文共享了这几个信息:Client Random、Server Random 、使用的椭圆曲线、椭圆曲线基点 G、服务端椭圆曲线的公钥,这几个信息很重要,是后续生成会话密钥的材料

        • TLS第三次握手

          • 客户端收到了服务端的证书后,自然要校验证书是否合法,如果证书合法,那么服务端到身份就是没问题的

          • 校验证书的过程会走证书链逐级验证,确认证书的真实性,再用证书的公钥验证签名,这样就能确认服务端的身份了,确认无误后,就可以继续往下走

          • 客户端会生成一个随机数作为客户端椭圆曲线的私钥,然后再根据服务端前面给的信息,生成客户端的椭圆曲线公钥,然后用「Client Key Exchange」消息发给服务端。

          • 至此,双方都有对方的椭圆曲线公钥、自己的椭圆曲线私钥、椭圆曲线基点 G。于是,双方都就计算出点(x,y),其中 x 坐标值双方都是一样的,前面说 ECDHE 算法时候,说 x 是会话密钥,但实际应用中,x 还不是最终的会话密钥。

          • 最终的会话密钥,就是用「客户端随机数 + 服务端随机数 + x(ECDHE 算法算出的共享密钥) 」三个材料生成的。

          • 算好会话密钥后,客户端会发一个「Change Cipher Spec」消息,告诉服务端后续改用对称算法加密通信。

          • 接着,客户端会发「Encrypted Handshake Message」消息,把之前发送的数据做一个摘要,再用对称密钥加密一下,让服务端做个验证,验证下本次生成的对称密钥是否可以正常使用。

        • TLS第四次握手

          • 服务端也会有一个同样的操作,发「Change Cipher Spec」和「Encrypted Handshake Message」消息,如果双方都验证加密和解密没问题,那么握手正式完成。于是,就可以正常收发加密的 HTTP 请求和响应了

    • RSA 和 ECDHE 握手过程的区别

      • RSA 密钥协商算法「不支持」前向保密,ECDHE 密钥协商算法「支持」前向保密;

      • 使用了 RSA 密钥协商算法,TLS 完成四次握手后,才能进行应用数据传输,而对于 ECDHE 算法,客户端可以不用等服务端的最后一次 TLS 握手,就可以提前发出加密的 HTTP 数据,节省了一个消息的往返时间(这个是 RFC 文档规定的,具体原因文档没有说明,所以这点我也不太明白);

      • 使用 ECDHE, 在 TLS 第 2 次握手中,会出现服务器端发出的「Server Key Exchange」消息,而 RSA 握手过程没有该消息;文章来源地址https://www.toymoban.com/news/detail-844100.html

到了这里,关于HTTPS ECDHE握手内容解析的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 计算机网络面经之TCP三次握手和四次挥手的详解

    1.详细描述三次握手和四次挥手的过程。 2.三次握手可以变成两次握手吗? 3.简述 TCP 连接和关闭的状态转移。 4.简述TCP 四次挥手的 TIME_WAIT状态,以及为什么需要有这个状态 (1)序号(sequence number):seq序号,占32位,用来标识从TCP源端向目的端发送的字节流,发起方发送数据

    2024年02月12日
    浏览(49)
  • 【计算机网络经典面试题】简述 TCP 三次握手和四次挥手的过程

    1)第一次握手:建立连接时,客户端向服务器发送SYN包(seq=x),请求建立连接,等待确认 2)第二次握手:服务端收到客户端的SYN包,回一个ACK包(ACK=x+1)确认收到,同时发送一个SYN包(seq=y)给客户端 3)第三次握手:客户端收到SYN+ACK包,再回一个ACK包(ACK=y+1)告诉服务

    2024年04月08日
    浏览(62)
  • 计算机网络:TCP协议的三次握手和四次挥手与UDP协议区别.

    TCP协议: UDP协议: TCP协议与UDP协议都工作在传输层. TCP协议与UDP协议它们的目标: TCP协议与UDP协议的最大区别: TCP协议保持连接的三个关键步骤: UDP协议: TCP协议与UDP协议主要区别: 传输控制协议(TCP,Transmission Control Protocol)是一种面向连接的、可靠的、基于字节流的

    2023年04月15日
    浏览(55)
  • 【计算机网络】HTTPS

    HTTPS也是一个应用层协议,在HTTP协议基础上引入加密层 由于HTTP协议内容都是按照文本形式 明文传输的,就导致在传输过程中出现一些篡改的情况 报文在传送时,有效载荷是明文传送的,容易泄露 在应用层和传输层之间 添加 软件层 ,一般称为 SSL /TLS SSL/TLS 本质就是 HTTP的握

    2024年02月09日
    浏览(45)
  • 【计算机网络】内容整理

    分组交换则采用存储转发(整个包必须到达路由器,然后才能在下一个链路上传输)技术。 在发送端,先把较长的报文划分成较短的、固定长度的数据段。 在端系统间通信会话期间,预留了端系统间沿路径通信所需要的资源(缓存、链路传输速率) 建立连接:建立一条专用的物

    2024年01月21日
    浏览(46)
  • 【计算机网络】HTTPs 传输流程

    1、HTTP协议传输的数据都是未加密的,是明文的,使用HTTP协议传输隐私信息非常不安 HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议,要比http协议安全。 2、HTTPS协议需要到CA申请证书,一般免费证书较少,因而需要一定费用。 3、http和https使用的是完全

    2024年02月11日
    浏览(44)
  • 计算机网络(6) --- https协议

    计算机网络(5) --- http协议_哈里沃克的博客-CSDN博客 http协议 https://blog.csdn.net/m0_63488627/article/details/132089130?spm=1001.2014.3001.5501 目录 1.HTTPS的出现 1.HTTPS协议介绍 2.补充概念 1.加密 1.解释 2.原因 3.加密方式 对称加密 非对称密钥 2.数据摘要和数字签名 数据摘要 数字签名 3.加密方

    2024年02月14日
    浏览(36)
  • 计算机网络—TCP和UDP、输入url之后显示主页过程、TCP三次握手和四次挥手

    TCP是面向连接的、可靠的,基于字节流的传输层通信协议 。 图片来源小林coding 序号:传输方向上字节流的字节编号。初始时序号会被设置一个随机的初始值(ISN),之后每次发送数据时,序号值 = ISN + 数据在整个字节流中的偏移。假设A - B且ISN = 1024,第一段数据512字节已经

    2024年02月14日
    浏览(52)
  • 【计算机网络】什么是HTTPS?HTTPS为什么是安全的?

    【面试经典题】 前言: HTTP最初的设计就是用于数据的共享和传输,并没有考虑到数据的安全性,如窃听风险,篡改风险和冒充风险。HTTPS是在 HTTP 的基础上引入了一个加密层。HTTPS通过数据加密,数据完整性检验和身份认证有效的保证了数据传输的安全性。HTTP默认端口号8

    2024年02月08日
    浏览(48)
  • 【计算机网络】一些乱七八糟内容

    MAC = Media Access Control  用于在局域网(LAN)或广域网(WAN)中实现设备自动接入网络 \\\"载波侦听多路访问\\\"(Carrier Sense Multiple Access) CSMA/CD 是CSMA的升级版本,加入了序列号检测机制。 CSMA/CA 是CSMA/CD的升级版本,加入了确认应答机制。 为什么是取最小值? 为了确保网络的稳定性和

    2024年02月22日
    浏览(44)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包