SSL协议的基本原理

简介

  SSL/TLS是世界上应用最广泛的密码通信协议,当我们上网页时会发现一些网址前面是”https”,这就说明这个页面是使用了SSL/TLS技术进行通信,这种方式在很大程度上可以保证通信内容的机密性。
  TLS实际上是SSL的改进版本,分别是transport layer security 和 secure socket layer,人们一般将SSL和TLS作为一个整体来看待。
  SSL/TLS可以承载HTTP和其他的一些协议,比如发送邮件时使用的SMTP(邮件传输协议)、POP3(邮局协议)。这样SSL就可以对传输的信息进行加密,从而保证机密性。
  这种技术提供了一个通信的框架,里面用到了对称密码、公钥密码、数字签名、单向散列函数、伪随机数生成器、消息认证码等技术,如果哪一部分出现问题,我们可以灵活地替换该部分。

SSL/TLS的结构

层次化的协议

  TLS协议是由“TLS记录协议”和“TLS握手协议”组成的,TLS记录协议位于底层负责进行加密,位于上层的TLS握手协议负责其他操作,他们的结构如下:

TLSstructure.png

TLS记录协议

  负责消息的压缩、加密以及数据的认证。处理工程如下:

TLS记录协议.png

  • 将消息分割成小片段,然后对每个片段进行压缩,压缩算法需要与通信对象进行协商。
  • 将每个压缩的片段加上消息认证码,这是为了保证完整性并进行数据的认证。通过附加消息的MAC值,可以识别出篡改。与此同时,为了防止重放攻击,在计算消息认证码时,还加上了片段的编号,单向散列函数的算法。以及消息认证码所使用的共享密钥都需要与通信对象协商决定。
  • 经过压缩的片段加上消息认证码会一起通过对称密码进行加密。加密使用CBC模式,CBC的初始化向量(IV)通过主密码(master secret)生成,而对称密码的算法以及共享密钥需要协商。
  • 上述的加密数据再加上数据类型、版本号、压缩后的长度组成的报头就是最终的报文数据。

TLS握手协议

  负责在客户端和服务器之间协商决定密码算法和共享密钥。基于证书的认证也在这一步完成。这段协议相当于下面的会话:

  • 客户端:“你好,我能理解的密码套件有RSA/3DES,或者DSS/AES,请问我们使用哪一种?”
  • 服务器:“你好,我们使用RSA/3DES吧,这是我的证书。”
  • 协商之后,就会互相发出信号来切换密码。负责发出信号的就是下面介绍的密码规格变更协议。

密码规格变更协议

  负责向通信对象传达变更密码方式的信号:

  • 客户端:“我们按照刚才的约定切换密码吧。1,2,3”
  • 中途发生错误时,就会通过下面的警告协议传达给对方。

警告协议

  负责在发生错误时将错误传达给对方:

  • 服务器:刚才的消息无法正确解析。
  • 如果没有发生错误,就会使用应用数据协议来进行通信。

应用数据协议

  • 将TLS上面承载的应用数据传达给通信对象的协议。

工作流程

流程图

SSLstep1.png
SSLstep2.png

(1)ClientHello(客户端→服务器)

  客户端向服务器发出加密通信的请求。在这一步,客户端主要向服务器提供以下信息:

  • 支持的协议版本,比如TLS 1.0版。
  • 当前时间
  • 一个客户端生成的随机数,稍后用于生成”对话密钥”。
  • 会话ID
  • 支持的加密方法,比如RSA公钥加密。
  • 支持的压缩方法。
  • “会话ID”是当客户端和服务器希望重新使用之前建立的会话(通信路径)时所使用的信息。

(2)ServerHello(客户端←服务器)

  服务器收到客户端请求后,向客户端发出回应。服务器的回应包含以下内容:

  • 确认使用的加密通信协议版本,比如TLS 1.0版本。如果浏览器与服务器支持的版本不一致,服务器关闭加密通信。
  • 一个服务器生成的随机数,稍后用于生成”对话密钥”。
  • 当前时间
  • 会话ID
  • 确认使用的加密方法,比如RSA公钥加密。
  • 密码套件。

(3)Certificate(客户端←服务器)

  服务器发送Certificate消息。包含以下内容:

  • 证书清单
      首先发送的是服务器的证书,然后会按顺序发送对服务器证书签名的认证机构的证书。当以匿名方式通信时,不发送Certificate消息。

(4)ServerKeyExchange(客户端←服务器)

  当Certificate消息不足以满足需求时(例如匿名方式通信),服务器会通过ServerKeyExchange消息向客户端发送一些必要信息。
  当使用RSA时,服务器发送N与E,也就是公钥。
  当使用DH算法时,服务器发送P、G、G的x次方modP(DH算法的公开参数)

(5)CertificateRquest(服务器 -> 客户端)

  有可能服务器找客户端要其证书用来验证,这个过程中,服务器会向客户端发送这些消息:

  • 服务器能够理解的证书类型
  • 服务器能够理解的认证机构名称清单

(6)ServerHelloDone(服务器 -> 客户端)

  • 通知客户端hello时间结束

(7)Certificate(客户端 -> 服务器)

  • 第5步中如果服务器要了客户端的证书,则发送给服务器

(8)ClientKeyExchange(客户端 -> 服务器)

  • 这个是关键的一步,交换生成最终密钥的关键素材
  • 如果是使用的RSA,则会将经过服务器公钥加密的预备主密码随着ClientKeyExchange消息一起发送
  • 如果是Diffie-Hellman密钥交换,则随着ClientKeyExchange消息一起发送的是Diffie-Hellman公开值
  • 预备主密码使得服务端和客户端分别计算出相同的主密码
  • 主密码作为关键的密钥素材可以生成:对称密码的密钥、消息认证码的密钥、对称密码的CBC模式中使用的初始化向量

(9)CertificateVerify(客户端 -> 服务器)

  • 只有发送了第5步消息的时候,客户端才会向服务器发送CertificateVerify消息
  • 这个消息是为了向服务器证明,自己确实是真实的客户端,拥有客户端证书的私钥。为了实现这个目的,客户端会计算主密码和握手协议种传送的消息的散列值加上自己的数字签名后发送给服务器。

(10)ChangeCipherSpec(客户端 -> 服务器)

  • 这不是握手协议,而是密码规格变更协议。客户端告诉服务器我要换密码了。
  • 因为已经双方已经交换了密码套件信息,可以开始切换密码进行通信了。

(11)Finished(客户端 -> 服务器)

  • 客户端:握手协议到此结束
  • 这时客户端已经切换了密码套件,服务器可以将密文解密,确认消息是否正确,从而判断密码套件切换是否正确

(12)ChangeCipherSpec(客户端←服务器)

  • 服务器:我也要切换密码了

(13)Finished(客户端←服务器)

  • 服务器:握手协议到此结束。

(14)切换至应用数据协议

  • 至此,握手协议完成了一下操作
  • 客户端获得了服务器的合法公钥,完成了服务器认证
  • 服务器获得了客户端的公钥,完成了客户端认证
  • 客户端和服务器之间生成了密码通信用的共享密钥
  • 客户端和服务器之间生成了消息认证码中用的共享密钥

抓包分析

SSL抓包.png
  以对淘宝抓包为例,可以看到,首先客户端对服务器发送ClientHello,然后服务器端分别回复ServerHello、Certificate、ServerKeyExchange、ServerHelloDone,其中没有请求我们客户端的证书。然后客户端开始发送ClientKeyExchange、ChangeCipherSpec、EncryptedHandshakeMessage。最后服务器端回复NewS二十四onTicket、ChangeCiherSpec、EncryptedHandshakeMessage。其中比我们之前的少了(5)、(7)步。

对SSL/TLS的攻击

  • 对各个密码技术的攻击
  • 利用证书的时间差进行攻击
  • 对伪随机数生成器的攻击

参考

[1] https://www.jianshu.com/p/6b690f04a12b
[2] https://blog.csdn.net/ustccw/article/details/76691248
[3] https://www.jianshu.com/p/8d7c8f59ea21
[4] 《图解密码技术》

迎与我分享你的看法。
转载请注明出处:http://taowusheng.cn/