美文网首页
https协议原理推演

https协议原理推演

作者: bit_拳倾天下 | 来源:发表于2023-09-13 09:30 被阅读0次

    0 前言

    0.1 什么是 https?

    HTTPS (全称:Hyper Text Transfer Protocol over SecureSocket Layer),是以安全为目标的 HTTP 通道,在HTTP的基础上通过传输加密和身份认证保证了传输过程的安全性。HTTPS 在HTTP 的基础下加入SSL,HTTPS 的安全基础是 SSL,因此加密的详细内容就需要 SSL。 HTTPS(443) 存在不同于 HTTP(80) 的默认端口,以及一个加密/身份验证层(在 HTTP与 TCP 之间)。这个系统提供了身份验证与加密通讯方法。

    0.2 https 加密的目的是?什么为什么要加密?

    客户端和服务器之间传输数据,并不是只有收尾两个节点,而是中间经过若干个节点(下一跳机制)的跳转,最终传给对方。http 协议传输数据是明文传输,数据传输过程中,在任意节点被拦截,都可以被任意查看、篡改,甚至中间节点可以冒充服务器或客户端进行往来交互。

    节点跳转

    所以,http 协议并不安全。目前,要做到数据传输过程中不经过中间节点,几乎是不可能的。为了数据安全,需要将数据进行加密,使得即使中间节点拦截数据也无法查看和篡改。
    防御中间人攻击,这就是 https 的目的。

    1 http 加密推演

    1.1 相关关键词

    1.1.1 对称加密

    加密、解密用相同的秘钥。

    1.1.2 非对称加密

    加密和解密使用不同的秘钥。这种加密方法,通常生成一对秘钥:公钥、私钥。秘钥有以下两个特点:

    1. 公钥是可以公开的,但是私钥是绝对不对外开放的,只存在于服务器端。
    2. 公钥加密的数据,需要秘钥解密;私钥加密的数据,需要公钥解密。公钥加密的数据,用公钥解不开;私钥加密的数据,用私钥也解不开。

    1.2 加密推演

    从上面的结论来看,为防止中间人攻击,需要对数据加密。那么,用对称加密还是非对称加密呢?

    首先,来看看对称加密,使用对称加密,加密方为了使对方能够解密,需要将秘钥和数据一起传输,否则对方无法得知是用什么加密的。那么问题来了,中间节点拦下数据,他既有了加密后的数据,也有了秘钥,是存在破解的可能的。

    那么,非对称加密呢?服务器端保留私钥,然后公钥公开出去。这样,客户端传给服务端的数据,数据经过共要加密,中间人没有私钥,即使拦截到数据也无法解密(前面说过,公钥加密的数据,公钥解不开)。
    但是服务器端传数据给客户端时,数据是用私钥加密的,中间人可以获取公钥,这样以一来是存在被破解的风险的;这种情况,中间人只能看,不能改,因为数据拆开后没有私钥无法在加密回去。
    还有一种情况,中间人冒充服务器,生成一套自己的秘钥,和客户端通信;然后再冒充客户端,和服务器通信。这样一来,非对称加密就土崩瓦解了。

    所以,这两个加密方法单独使用都不能很好地保证数据不被中间人攻击。对于上面两个情况,可以归结为中间人攻击客户端和攻击服务器。


    攻击客户端 攻击服务端

    对于伪造秘钥的情况,客户端、服务器需要辨别公钥、私钥的真伪。如何做到呢?这就要说到 CA 证书。CA 证书需要向第三方授信机构进行申请,它是不可伪造的。

    申请 CA 证书流程简述:
    向第三方机构提供邓白氏编码(公司申请需要)或身份证号(个人申请需要),域名(全球唯一)以及服务器公钥等信息,并且要通过测试(例如在对应域名的服务器上某个文件夹放置指定文件,不是自己的服务器做不到,以此来证明服务器是你的),这些是其他人做不到的,所以证书无法伪造,一个域名只能对应一个证书。这样才能申请到 CA 证书。

    证书申请

    什么是 CA 证书?作用是什么?
    CA 证书实际上是将域名、公钥等信息用第三方机构自己的私钥进行加密的产物。要解密的话,需要通过公钥解密,而第三方授信机构的公钥都是嵌入到操作系统的。至于为什么要嵌入到操作系统,就是为了减少一次网络传输,据说是可以增加一点安全性。(但是中间人的操作系统必然也嵌入了第三方授信机构的公钥,这样做好像并没什么卵用,貌似只是给了先起步者垄断的机会。。。)

    CA 证书的使用简述及其作用:
    申请到 CA 证书后,放到服务器,由服务器下发给客户端。客户端通过嵌入到操作系统的公钥将证书解密,就可以获取到服务器的公钥。
    至于作用,就是加密服务器的公钥,保证公钥的真实性,因为前面说过受信的证书是无法伪造的。

    i证书下发

    对于客户端的攻击,中间人可以通过伪造公钥、秘钥而伪装成服务端或客户端。但是有了 CA 证书作为服务器公钥的传输介质,中间人无法伪造证书,也就无法伪造服务端公钥。这样,即使中间人用操作系统的第三方授信公钥将证书破解,最多就能获取到公钥,不能篡改,因为加密不回去了;即使中间人用自己的秘钥将信息加密成假的证书,客户端也无法解密。这样中间人拦截到客户端的数据,也无法读取和篡改(公-公解密也不成立),也无法向客户端发送有效的篡改数据(没有私钥无法解密)。这样就阻止了中间人伪造成服务器,对客户端进行攻击。

    虽然无法篡改客户端的数据,但是有了证书就能获取服务器公钥,可以直接替换数据,中间人干脆不解密客户端数据数据了,直接将自己的数据用服务器公钥加密,传给服务端,依然是可以办到的。而且,有了服务器公钥,也就能读取服务器发送的数据。

    推演到这里,中间人依然可以伪装成客户端攻击服务器,其原因就是他可以获取到服务器公钥。如果有办法办到即使他拿到公钥也没用,那么遗留的问题就解决了。

    这就需要引入对称加密了。

    客户端随机生成一个字符串作为对称加密的秘钥,将数据进行加密。然后再通过服务器公钥,将对称秘钥加密,这样将加密后的对称秘钥和数据传给服务端。服务端接到数据后,先获取经过公钥加密后的对称秘钥,然后用服务器的私钥将其解密,获取到对称秘钥,然后用对称秘钥对数据进行解密。服务端传数据给客户端时,也是用对称密钥对数据加密(返回数据时,不需要传对称秘钥回来,因为客户端有对称密钥)。


    CA证书+对称加密+非对称加密

    这样一来,后续传输数据的加、解密都是通过对称秘钥来完成。从了防止了中间人攻击,通常对称加密的效率也是高于非对称加密的

    中间人拦截到客户端的数据包括,对称加密后的数据和非对称加密后的对称密钥,想要破解数据,需要对称秘钥,而对称密钥需要服务器私钥解密,中间人没有私钥做不到,同时也无法加密数据返回给客户端。所以这种方法,中间人伪造成服务端的问题解决了。

    中间人拦截到服务端的数据,还是获取不到对称秘钥,也无法对数据加密、解密。所以,中间人伪造成客户端的问题也解决了。

    https 正是用这种“证书 + 对称加密 + 非对称加密”的方式,防止中间人攻击的。

    小结:

    CA 证书,用来加密服务器公钥(b),保证服务器公钥(b)不可篡改和伪造;
    对称秘钥(a),用来真正给数据加解密;
    服务器公钥(b),用来加密对称秘钥(a),保证中间人无法获取对称秘钥(a);
    服务器私钥(c),用来把加密后的对称秘钥解密,获取真正的对称秘钥(a);
    第三方受信机构公钥(x),嵌入到操作系统,用来解密证书,获取服务器公钥(b);
    第三方受信机构私钥(y),只存在于第三方受信机构,用来将服务器公钥(b)加密,生成证书。

    2 https 四次握手

    上面描述了下 对 http 加密的思路,或者说 https 的思想,下面是 https 的详解。

    首先 HTTPS 并非是应用层的一种新协议。只是 HTTP 通信接口部分用 SSL(SecureSocket Layer)和 TLS(Transport Layer Security)协议代替而已。
    通常,HTTP 直接和 TCP 通信。当使用 SSL 时,则演变成先和 SSL 通信,再由 SSL和 TCP 通信了。简言之,所谓 HTTPS,其实就是身披 SSL 协议这层外壳的HTTP
    http 三次握手 4次挥手 https 怎么握手

    2.1 SSL 和 TLS 简介

    SSL协议,是一种安全传输协议,最初是由 Netscape 在1996年发布,由于一些安全的原因 SSL v1.0 和 SSL v2.0 都没有公开,直到 1996 年的 SSL v3.0。TLS 是 SSL v3.0 的升级版,目前市面上所有的 Https 都是用的是 TLS,而不是SSL。TLS与SSL在传输层与应用层之间对网络连接进行加密。
    2.2 四次握手

    1. 客户端请求服务器简历 ssl 连接,并发送客户端支持的加密算法
    2. 服务器接到连接请求后,将 CA 证书、公钥下发给客户端,并活肤服务器支持的加密算法
    3. 客户端产生一个 Premaster secret 随机数(对称秘钥,后续加解密都靠它),用公钥将其加密传输给服务器,告知服务器,后续数据用 Premaster secret 加密
    4. 服务器回应收到,并且建立连接

    步骤 1: 客户端通过发送 Client Hello 报文开始 SSL 通信。报文中包含客户端支持的 SSL 的指定版本、加密组件(Cipher Suite)列表(所使用的加密算法及密钥长度等)。


    步骤 2: 服务器可进行 SSL 通信时,会以 Server Hello 报文作为应答。和客户端一样,在报文中包含 SSL 版本以及加密组件。服务器的加密组件内容是从接收到的客户端加密组件内筛选出来的。
    步骤 3: 之后服务器发送 Certificate 报文。报文中包含公开密钥证书。
    步骤 4: 最后服务器发送 Server Hello Done 报文通知客户端,最初阶段的SSL握手协商部分结束。


    步骤 5: 客户端以 Client Key Exchange 报文作为回应。报文中包含通信加密中使用的一种被称为 Pre-master secret 的随机密码串。该报文已用步骤 3 中的公开密钥进行加密。
    步骤 6: 接着客户端继续发送 Change Cipher Spec 报文。该报文会提示服务器,在此报文之后的通信会采用 Pre-master secret 密钥加密。
    步骤 7: 客户端发送 Finished 报文。该报文包含连接至今全部报文的整体校验值。这次握手协商是否能够成功,要以服务器是否能够正确解密该报文作为判定标准。


    步骤 8: 服务器同样发送 Change Cipher Spec 报文。
    步骤 9: 服务器同样发送 Finished 报文。
    步骤 10: 服务器和客户端的 Finished 报文交换完毕之后,SSL 连接就算建立完成。当然,通信会受到 SSL 的保护。从此处开始进行应用层协议的通信,即发送 HTTP请求。

    在以上流程中,应用层发送数据时会附加一种叫做 MAC(Message Authentication Code)的报文摘要。MAC 能够查知报文是否遭到篡改,从而保护报文的完整性。

    相关文章

      网友评论

          本文标题:https协议原理推演

          本文链接:https://www.haomeiwen.com/subject/knmnbltx.html