Fight For Freedom

12月 31

https原理的来龙去脉之二

       继续上次的话题。

0x04. 浅析ssl/tls协议

       趁着这个机会,顺便抓抓包,分析下其中的交互过程。
       SSL/TLS的会话过程:

     

        客户端(192.168.19.129)访问服务端(192.168.19.128),产生了如下的报文:     

        我将只简单地分析圈出的交互过程,对于进行复杂的算法计算这里不作讨论,只在最后提一下。

      一、握手过程

       1. 前面三次握手,表明ssl/tls协议是建立在tcp连接之上的;

       2. Client Hello:是握手过程中的第一条消息,用于告知服务器客户端所支持的密码套件种类、最高SSL/TLS协议版本以及压缩算法,除此之外,客户端还要产生一个随机数(random),这个随机数一方面需要在客户端保存,另一方面需要传送给服务端。如下:

        

        3. ServerHello:服务器接受到ClientHello后,会返回ServerHello。服务器从客户端在ClientHello中提供的密码套件、SSL/TLS版本、压缩算法列表里选择它所支持的项,并把它的选择包含在ServerHello中告知客户端,并且也携带着随机数。

           Certificate:服务器一般在ServerHello后会接一条Certificate消息(客户端和服务器都可以发送证书消息来证明自己的身份,但是通常客户端证书不被使用,比如这里就没有),Certificate消息中会包含一条证书链,从服务器证书开始,到Certificate authority(CA)或者最新的自签名证书结束。这里我们做实验,直接向自建CA申请的,故不存在这种情况。

          服务端需要将自己的证书发送给客户端。这个证书是对于服务端的一种认证。例如,客户端收到了一个来自于称自己是www.alipay.com的数据,但是 如何证明对方是合法的alipay支付宝呢?这就是证书的作用,支付宝的证书可以证明它是alipay,而不是财付通。证书是需要申请,并由专门的数字证书认证机构(CA)通过非常严格的审核之后颁发的电子证书。颁发证书的同时会产生一个私钥和公钥。私钥由服务端自己保存,不可泄漏。公钥则是附带在证书的信息中,可以公开的。证书本身也附带一个证书电子签名,这个签名用来验证证书的完整性和真实性,可以防止证书被串改(用CA的私钥签名了)。另外,证书还有个有效期。

        如下:

证书会附带与协商好的密钥交换算法对应的密钥。

        ServerKeyExchange:只有使用指定的密钥交换算法时,服务端才会发送此消息,ServerkeyExchange消息会携带这些密钥交换算法所需要的额外参数。

        ServerHelloDone:服务器发送这条消息表明服务器部分的密钥交换信息已经发送完了,等待客户端的消息以继续接下来的步骤。这条消息只用作提醒,不包含数据域。

        4. ClientKeyExchange:这条消息包含的数据与所选用的密钥交换算法有关。

          比如选择的密钥交换算法是RSA,那么消息包含的参数为用服务器传过来的RSA公钥(包含在之前证书中的或者是ServerKeyExchange中的)加密过的PreMasterSecret(由客户端指定)

          然而从上面抓包中可以看到我们做实验用的是ECDHE交换密钥算法,PreMasterKey产生的方法跟上述RSA密钥交换算法的有些差别。

          客户端需要对服务端的证书进行检查,具体怎么检测呢?个人猜测:用CA的公钥去解密数字证书,来验证书来源的合法性,同时也会检查证书的完整性以及证书跟服务端域名是否吻合。

          ChangeCipherSpec 协议:一条消息表明握手协议已经完成,体现在数据包中就是一个字节的数据,用于告知服务端,客户端已经切换到之前协商好的加密套件的状态,准备使用之前协商好的加密套件加密数据并传输了。

      

     二、KEY

       上面的讲解突出了ssl的握手过程,但对随机数、PreMasterKey等并没有仔细分析。这里稍微提下,至于具体的是怎么算出来、之间怎么计算等等问题,这里不涉及。
        PreMaster secret是在客户端使用RSA或者Diffie-Hellman等加密算法生成的。它将用来跟服务端和客户端在Hello阶段产生的随机数结合在一起 生成Master secret。在客户端使用服务单的公钥对PreMaster secret进行加密之后传送给服务端,服务端将使用私钥进行解密得到PreMaster secret。也就是说服务端和客户端都有一份相同的PreMaster secret和随机数。
        由于服务端和客户端都有一份相同的PreMaster secret和随机数,这个随机数将作为后面产生Master secret的种子,结合PreMaster secret,客户端和服务端将计算出同样的Master secret。
        而Master secret是有系列的hash值组成的,它将作为数据加解密相关的secret的Key Material。Master secret最终解析出来的数据如下:
                
        其中,write MAC key,就是session secret或者说是session key。Client write MAC key是客户端发数据的session secret,Server write MAC secret是服务端发送数据的session key。MAC(Message Authentication Code),是一个数字签名(就是一个带有key的杂凑函数)用来验证数据的完整性,可以检测到数据是否被串改。
        我们可以从下面的图中清晰地看到Secret Keys的的生成过程以及作用:
          

       三、通信过程

          在所有握手过程完成后,双方就开始传送通信数据了。应用数据在传输之前要附加上MAC secret,然后再对这个数据包使用write encryption key进行加密。在服务端收到密文之后,使用Client write encryption key进行解密,客户端收到服务端的数据之后使用Server write encryption key进行解密,然后使用各自的write MAC key对数据的完整性包括是否被串改进行验证。

          好了,现在我们可以对上面所有的通信今过程给出一个形象的比喻来:

            A:我要和你通话啦,我这可以支持....这些密码套件(client hello);
            B:那我们用DHE-RSA-SHA这对组合好了(Server Hello)。对了,我把证书也给你看看,你验证下我身份吧(Certificate)。我的话说完了(ServerHelloDone
            A:(通过早就有CA的信息来验证证书的真实性)
                  (产生一份秘密消息(PreMasterKey)。用B的公钥加密后发给B
                   我生成了秘密消息哦,发过来了哟(ClientKeyExchange);
                   注意啦,下面我就要用加密的办法给你发消息了(ChangeCipherSpec);
                  (这份秘密消息PreMasterKey复杂处理后将用作加密密钥、加密初始化向量和hmac的密钥)
             B:(用自己的私钥将ClientKeyExchange中的秘密消息解密出来,然后将秘密消息进行处理,生成加密密钥、加密初始化向量和hmac的密钥,这时双方已经安全的协商出一套加密办法了)
                   嗯嗯,好好,我也要把信息加密给你发过来。
             A:......(已加密)
             B:(解密数据,用mac验证数据的完整性)
                   ......(已加密)

0x05. 总结       

       不同密钥交换算法有怎样不同的握手过程、密钥是怎样计算生成的、数据是怎么加密传输的、ssl和tls的区别等等,我都没讲到,不过这丝毫不会影响到理解ssl协议本身。我们依然可以去发现其中的奥秘。
       如何实现加密通信,看起来不是很难的问题,却花了很多前辈的心血。当一个个问题接连出现时,如何更好地去解决?不管是在原有的经验上进行创新,还是用新的眼光去开拓另外的技术土壤,这都是值得学习的。
       从ssl/tls协议本身上来说,它已不仅仅是协议这么简单了,它是一个新的思考点,融汇了如此多的思想和技术,比如数学、比如生活等等。每当看完这些新的技术时,心中总有一种敬意。



参考资料:
http://sweetpotato.blog.51cto.com/533893/1662061
http://drops.wooyun.org/tips/6002

标签:none

还不快抢沙发

添加新评论

captcha
请输入验证码

最新文章

最近回复

  • L_AnG:友链第一个居然是那个傻逼熟人,无语无语
  • lynahex:拜大佬
  • cdxy:师傅好
  • lynahex:十分感谢解惑,特别是解决问题的方法。
  • ld:1. 搜索CVE-2016-0701 进入 https://cv...
  • lynahex:好的。
  • xdxd:友链已加~~~希望有机会多多交流~~
  • lynahex:恩,重测了下是可以的。可能当时一些危险函数被我禁掉了。 thx
  • 过客:虽然博主文章过了好久了,本地system测试还是可以执行的
  • 友情链接

    分类

    其它