《一个陌生女人的来信》HTTPS中安全传输,值得你看

854 阅读13分钟

前言

(《一个陌生女人的来信》)借名著说一些网络基础知识,小玲珑打算全面梳理网络知识,这是关于网络分享的第二篇。

没有网络基础也可以看看我前面的文章~

这一篇内容是关于HTTPS握手的内容,关于传统的秘钥交换算法和基于TLS1.2椭圆曲线算法讲解数据安全可靠传输的过程,保证您能看得懂🐱‍🏍

如果真的有不懂的地方就评论区找我就好啦,下面就先看看协议发展的过程吧😉

传输层安全协议发展

TLS传输层安全协议,前生是SSL安全套接层协议。

TSL是以SSL为原型所以有时候统称为SSL协议---《图解HTTP》

传输层安全的协议发展历程可以参考这张表格,其中TSL1.0和SSL3.0相差很小很小。

现在主流的版本是 TLS/1.2, 之前的 TLS1.0、TLS1.1 都被认为是不安全的,这篇文章会说明HTTPS握手和TLS1.2以及1.3的握手过程。

协议 年份
SSL 1.0 未知
SSL 2.0 1995
SSL 3.0 1996
协议 年份
TLS 1.0 1999
TLS 1.1 2006
TLS 1.2 2008
TLS 1.3 2018

第一节.https传统的RSA握手

《图解http》中有两句话https是身披SSL外壳的httphttp+加密+认证+完整性保护=https

SSL 即安全套接层(Secure Sockets Layer),在 OSI 七层模型中处于会话层(第 5 层)。之前 SSL 出过三个大版本,当它发展到第三个大版本的时候才被标准化,成为 TLS(传输层安全,Transport Layer Security),并被当做 TLS1.0 的版本,准确地说,SSL3.1=TLS1.0

1.对称加密

记得最开始女主和男主写信吗,

女主写了10封信之后跟男主说:hey,男主,我感觉大家都可以看到我给你写的信呢。怎么办?

男主说,我也感觉到了。不如我给你一个密码,我用这个密码把信加密你用这个密码解密别人就看不到啦。

女主想好像也还可以。应该是看不到了。 但是后来感觉不对啊,你给我的密码可能被别人获取呀

用同一种秘钥进行加解密。虽然信息被加密,但是这种方法秘钥可能会被获取导致信息被篡改。

得不到信息我可以得到你的密码,嘻嘻嘻。

2.非对称加密

男主:看来密码不能公开呀。既然这样的话,那我们各自拥有两个密码,一个加密,一个解密。加密秘钥公开,解密秘钥不公开。公钥加密私钥解密不就好了吗?

女主:好主意!

利用私钥和公钥,公钥进行加密,私钥进行解密。如果A向B发送数据,就用B的公钥进行加密,然后传到B后B再用私钥进行解密。同理B向A发数据,B用A的公钥进行加密,B的私钥进行解密。

但是非对称加密的方式效率太低。

女主:hey,男主。我们现在效率好慢呀,送出的信太少了。。。

男主:是啊,别急,我正在想办法。

3.两种方式结合

男主:有啦,我们可以用前两种办法结合,我先给你非对称加密传一个密码,然后再对称加密传信件。这样我们用同样的秘钥加密解密,传输的过程中别人也不会获取到我们的密码。

女主:我也是这样想的,哈哈哈,这下应该要快多了。

先用RSA非对称加密算法传输一个秘钥,最后再用这个秘钥进行通信,为什么这个秘钥不会被劫持呢?因为之前传输过一次了,现在就不用再传输。

整个过程是客户端生成一个client_random给服务器,(1)

服务器接着生成server_random和自己公钥给客户端,(2)

客户端用公钥将pre_random加密发送给服务端,(3)

服务端`私钥解密`后拿到参数,将这三个参数合形成一个秘钥;(4)

客户端也有这三个相同的参数合成一个秘钥,然后两者有了相同的秘钥后进行对称加密传输。(5)

(重点)第三步客户端用公钥加密的pre-random只有服务端的私钥才能解开。因此攻击者没有办法获取pre-randown。进而没有办法得到秘钥。

4.中间人攻击

女主以为这会信息安全了,但是没想到男主的另外一个粉丝佳佳也想给男主写信。。。

佳佳进而冒充男主和女主送信。拿到女主的信后又冒充女主与男主通信,这样男主女主都不会发现。这就是中间人攻击。

佳佳通过DNS劫持,将目标地址转换为佳佳的地址,佳佳也生成公钥和私钥,客户端向服务端发送参数(用佳佳的公钥)发到了佳佳那,佳佳用自己的私钥进行解密,和客户端进行沟通。客户端还以为佳佳就是服务器。佳佳用服务端的公钥将信息加密,发给服务端。服务端却还以为自己是和客户端通信。

如何解决这个问题?这个问题还是因为公钥是公共的。如果客户端知道收到的公钥是来自服务器不是佳佳,那么就能解决这个问题了。

5.数字证书

男主:我给你发消息的时候证明一下自己是本人,我给你一个证书吧。然后可以通过数字签名来防止证书在传送的过程中被篡改。

女主:证书我知道,就像是你的身份证一样可以证明你自己,那什么是数字签名呢有什么用?

男主:哈哈哈,我把我的公钥和个人信息用哈希算法加密形成消息摘要,hash算法加密的消息摘要是不可逆的,可以防止被中间人修改。然后消息摘要还需要通过专门的认证中心(CA)用私钥加密形成一个数字签名

女主:既然hash算法能够防止消息摘要不被修改,为什么还要通过认证中心加密呢?那不是多次一举?

男主:哈哈,为了防止这些中间人。没办法呀,你想虽然他们不能修改消息摘要,但是可以用hash算法重新生成一个新的消息摘要。整个原始信息都被替换了呀。

女主:我明白了,中间人不修改消息摘要,直接给我一个他的消息摘要也是可以的。所以需要AC的私钥加密消息摘要。

男主:是滴,但是还没完,我还要将数字签名和(我的公钥+个人信息)结合起来形成数字证书。我把数字证书传给你,而不是传递数字签名给你。

女主:是因为我要对数字你的信息认证吧?我把的数组证书的数字签名用CA的公钥进行解密拿到消息摘要,然后把服务器的公钥通过hash算法加密形成一个消息摘要,然后对比这两个摘要是否相同?相同就表示认证通过?

男主:没错!

以上就是数字证书有关的东西:公钥+个人信息hash算法CA认证中心数字签名数字证书是否都理清楚了呢?

数字证书和数字签名千万不要混淆。

数字签名是服务端的公钥通过hash算法进行处理成为消息摘要,消息摘要再进过AC的私钥加密成为数字签名。

数字签名只是数字证书的一部分而已。数字签名属于数字证书。数字证书包含数字签名

6.整个过程

完成交流的过程其实就是上满男女主的对话。下面看看图再说一遍,加深理解。

  • 服务器生成数字证书的过程

  • 浏览器验证证书的过程

  • 完整的过程
  1. 客户端向服务器发送client_random和加密方法列表,

  2. 服务器收到后向浏览器发送数字证书,server-random,选择的加密方法

  3. 客户端对数字证书中的数字签名解密,对公钥进行加密,就得到了两个消息摘要。比较两者是否相同

  4. 若比对成功相同,生成pre-random给服务器。

  5. 服务器私钥解密获取了pre-random。

  6. 服务器联合三个随机参数生成秘钥。并确认

  7. 浏览器生成秘钥

  8. 双方通过对称加密进行传输数据,happy🐱‍💻。

说明:

  1. CA认证中心的私钥进行签名生成数字签名,数字签名要CA的公钥进行解密,那么如何保证公钥的可靠性?CA的公钥需要更牛的CA给他签名,然后形成CA证书(这个CA证书里有公钥)。

    想知道这个CA证书是否可靠,就要看更牛的CA证书的公钥能够解开CA签名。这样一层层往上查找CA,直到找到全球著名的CA,也就是root CA.

  2. 为什么是三个参数? 我自己的理解是首先浏览器的client-random表示浏览器向客户端发出请求,然后服务器再做出响应发出client-random。这两个参数相当于是双方互相认证。发送私密的pre-randon随机参数是为了生成不被攻击者知道的秘钥,所以要三个参数,如果觉得我的理解不对还请指正😉

  3. 上面的pre-random在一些文章书籍中叫pre-master secret,这个影响不大。

第二节:TLS1.2的握手过程

前面说过SSL 即安全套接层(Secure Sockets Layer),在 OSI 七层模型中处于会话层(第 5 层)。之前 SSL1.0,2.0设计时候发现了很多问题,没有被使用,当它发展到第三个大版本的时候才被标准化,成为 TLS(传输层安全,Transport Layer Security),TLS1.0=SSL3.0。

主要是用ECDHE椭圆曲线算法根据client_params和server_parmas生成pre_random 最后再计算出秘钥。上一节说的是传统的秘钥交换RSA算法,这些算法的原理目前真的看不懂,密码学似玄学😂

1.客户端发起加密请求

客户端发送随机数,TLS版本和加密套件列表给服务端。

一组加密套件列表里有很多个密码套件。我们那一组套件列表中的一个密码套件为例子。

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256                          (0xc02f)
  • TLS:表示基于TLS协议。
  • ECDHE:TLS/SSL 的握手过程中使用ECDHE算法生成pre-random。
  • RSA:TLS/SSL 的 Authentication 使用RSA 验证证书签名。
  • AES_128_GCM:T使用长度128位的AES算法进行对称加密。在对称加密的过程中使用主流的GCM分组模式
  • HA256:哈希摘要算法 使用SHA256,常见到有SHA384, SHA512。
  • 0xc02f:加密套件的标识。每个加密套件是有唯一数字作为标识的。

2.服务端做出响应

服务端发送随机数,随机参数,确认TLS版本以及一组加密套件中选择一个加密套件,以及证书给浏览器

3.客户端验证证书,生成秘钥

客户端验证证书是否通过,如果通过生成客户端的随机参数client-params。利用client-params和sever-params这两个参数,通过椭圆曲线算法生成pre-random这个随机参数。同时传递client-params给服务端。

客户端根据pre-random,server-random,client-random和椭圆曲线算法生成秘钥

4.服务端生成秘钥

服务端也根据这三个参数生成秘钥,之后就使用这个秘钥进行对称加密解密。完整过程如下:

与传统的密钥交换RSA算发的比较

  1. 验证是双向的,客户端和服务器互相认证身份
  2. 生成秘钥之后各自都会给对方一个收尾消息,告诉之后的传输都用这个秘钥进行对称加密,图中简化成一个双向箭头了。
  3. 使用椭圆曲线算法可以抢跑,也就是说当客户端给服务端一个收尾消息后可以立即发HTTP请求,不用等到服务端的收尾消息发过来再发送HTTP请求,节约了一个往返时延。也叫TLS false start。

第三节:TSL1.3的握手

现在主流的版本是 TLS/1.2, 但是在 2018 年推出了更加优秀的 TLS1.3,大大优化了 TLS 握手过程。

1.浏览器发送client-params,client-random,TSL版本和加密套件列表。

2. 服务器确认套件列表,TSL版本,数字证书,两个随机参数

3.生成秘钥

对比

在性能和安全方面看看都有哪些改进吧。

  1. 性能:在TLS1.2中是要数字证书验证通过才生成client-params。根据client-params和server-parmas计算出pre-random进而生成秘钥。 TSL1.3一开始就生成client-params传递给服务器。和 TLS 1.2 相比少了一个 RTT。

    服务端不必等待对方验证证书之后才拿到client_params,而是直接在第一次握手的时候就能够拿到, 拿到之后立即计算secret,节省了之前不必要的等待时间。同时,这也意味着在第一次握手的时候客户端需要传送更多的信息,一口气给传完。

  2. 安全 在 TLS1.3 中废除了非常多的加密算法,最后只保留五个加密套件:

TLS_AES_128_GCM_SHA256
TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256
TLS_AES_128_GCM_SHA256
TLS_AES_128_GCM_8_SHA256

对称加密算法只有 AES 和 CHACHA20,之前主流的也会这两种。分组模式也只剩下 GCM 和 POLY1305, 哈希摘要算法只剩下了 SHA256 和 SHA384 了。

之前RSA这么重要的非对称加密算法怎么不在了?

第一、2015年发现了FREAK攻击,即已经有人发现了 RSA 的漏洞,能够进行破解了。

第二、一旦私钥泄露,那么中间人可以通过私钥计算出之前所有报文的secret,破解之前所有的密文。

回到 RSA 握手的过程中,客户端拿到服务器的证书后,提取出服务器的公钥,然后生成pre_random并用公钥加密传给服务器,服务器通过私钥解密,从而拿到真实的pre_random。当中间人拿到了服务器私钥,并且截获之前所有报文的时候,那么就能拿到pre_random、server_random和client_random并根据对应的随机数函数生成secret,也就是拿到了 TLS 最终的会话密钥,每一个历史报文都能通过这样的方式进行破解。

但ECDHE在每次握手时都会生成临时的密钥对,即使私钥被破解,之前的历史消息并不会收到影响。这种一次破解并不影响历史信息的性质也叫前向安全性

RSA 算法不具备前向安全性,而 ECDHE 具备,因此在 TLS1.3 中彻底取代了RSA。

最后

参考文章:

如果你看到了这里说明可能是喜欢这篇文章的,希望能够给你带来一丝启发与思考,下篇文章见,比心💕