TLS/SSL

12 篇文章 0 订阅 ¥99.90 ¥99.00

TLS/SSL简介

SSL/TLS是世界上应用最广泛的密码通信方法。

1:不能被窃听——机密性问题
2:不能被篡改——完整性问题
3:确认是否是真正的——认证的问题

要确保机密性,可以使用对称密码。使用伪随机数生成器生成密钥。若要将对称密码的密钥发送给通信对象,可以使用公钥密码或者Diffie-Hellman密钥交换。
要识别篡改,对数据进行认证,可以使用消息认证码。消息认证码是使用单向散列函数来实现的。
要对通信对象进行认证,可以使用对公钥加上数字签名所生成的证书。

密码套件

SSL/TLS提供了一种密码通信的框架,这意味着SSL/TLS中使用的对称密码、公钥密码、数字签名、单向散列函数等技术,都是可以像零件一样进行替换的。也就是说,如果发现现在所使用的某个密码技术存在弱点,那么只要将这一部分进行替换就可以了。尽管如此,但并不是说所有的组件都可以自由选择,选择过于自由,很难保证兼容性。所以规定了一些密码技术的“推荐套餐”,这种推荐套餐称为密码套件。

SSL(Secure Socket Sayer,安全套阶层)是1994年由网景(Netscape)公司设计的一种协议,并在该公司的Web浏览器Netscape Navigator中进行了实现。称为事实上的行业标准。SSL与1995年发布了3.0版本,但在2014年,SSL3.0协议被发现存在可能导致POODLE攻击的安全漏洞,因此SSL3.0已经不安全了。

TLS(Transport Layer Security,传输层安全)是IETF在SSL3.0的基础上设计的协议。在1999年作为RFC2246发布的TLS1.0,实际上相当于SSL3.1。

2006年,TLS1.1以RFC4346的形式发布,这个版本中增加了针对CBC攻击的对策,并加入了AES对称密码算法。
TLS1.2中新增了对GCM、CCM认证加密的支持,此外还新增了HMAC-SHA256,并删除了IDEA和DES,将伪随机函数(PRF)改为基于SHA-256来实现。

层次化的协议

TLS协议是由TLS记录协议(TLS record protocol)和TLS握手协议(TLS handshake protocol)这两层协议叠加而成的。位于底层的TLS记录协议负责进行加密,而位于上层的TLS握手协议则负责除加密以外的其他各种操作。上层的TLS握手协议又可以分为4个子协议。

TLS记录协议

TLS记录协议位于TLS握手协议的下层,是负责使用对称密码对消息进行加密通信的部分。TLS记录协议中使用了对称加密和消息认证码,但是具体的算法和共享密钥则是通过握手协议在服务器和客户端之间协商决定的。

TLS记录协议负责消息的压缩、加密以及数据的认证。
首先,消息被分割成多个较短的片段(fragment),然后分别对每个片段进行压缩。压缩算法需要与通信对象协商决定。

接下来,经过压缩的片段会被加上消息认证码,这是为了保证完整性,并进行数据的认证。通过附加消息认证码的MAC值,可以识别出篡改。与此同时,为了防止重放攻击,在计算消息认证码时,还加上了片段的编号。单向散列函数的算法,以及消息认证码所使用的共享密钥都需要与通信对象协商决定。

再接下来,经过压缩的片段再加上消息认证码会一起通过对称密码进行加密。加密使用CBC模式,CBC模式的初始化向量(IV)通过主密码(master secret)生成,而对称密码的算法以及共享密钥需要与通信对象协商决定。

最后,上述经过加密的数据再加上由数据类型、版本号、压缩后的长度组成的报头就是最终的报文数据。其中,数据类型为TLS记录协议所承载的4个子协议的其中之一。

TLS握手协议

TSL握手协议分为4个子协议:握手协议、密码规格变更协议、警告协议和应用数据协议。

1)握手协议

握手协议是TLS握手协议的一部分,负责在客户端和服务器之间协商决定密码算法和共享密钥。基于证书的认证操作也在这个协议中完成。它是4个子协议中最复杂的一个。

握手协议是TLS握手协议的一部分,负责生成共享密钥以及交换证书。其中,生成共享密钥是为了进行密码通信,交换证书是为了通信双方相互进行认证。

由于握手协议中的信息交换是在没有加密的情况下进行的,因此在这一过程中必须使用公钥密码或者Diffie-Hellman密钥交换。

  ClientHello                  -------->
                                                  ServerHello
                                                 Certificate*
                                           ServerKeyExchange*
                                          CertificateRequest*
                               <--------      ServerHelloDone
  Certificate*
  ClientKeyExchange
  CertificateVerify*
  [ChangeCipherSpec]
  Finished                     -------->
                                           [ChangeCipherSpec]
                               <--------             Finished
  Application Data             <------->     Application Data

(1)ClientHello(客户端->服务端)

可用的版本号
当前时间:在基本的TLS中是不使用的,但上层协议中有可能会使用到这一信息。
客户端随机数:是一个由客户端生成的不可预测的随机数
会话ID:当客户端和服务器希望重新使用之前建立的会话(通信路径)时所使用的信息。
可用的密码套件清单
可用的压缩方式清单

(2)ServerHello(客户端<-服务端)

使用的版本号
当前时间:在基本的TLS中是不使用的,但上层协议中有可能会使用到这一信息。
服务端随机数:是一个由服务器生成的不可预测的随机数,这个随机数必须与客户端生成的随机数无关
会话ID
使用的密码套件
使用的压缩方式

(3)Certificate(客户端<-服务端)

服务器给客户端发送证书清单
证书清单是一组X.509v3证书序列,首先发送的是服务器(发送方)的证书,然后会按顺序发送对服务器证书签名的认证机构的证书。
客户端会对服务器发送过来的证书进行验证。当以匿名方式通信时,不发送Certificate信息。

(4)ServerKeyExchange(客户端<-服务端)

当Certificate消息不足以满足需求时,服务器会通过ServerKeyExchange消息向客户端发送一些必要信息。具体所发送的信息内容会根据所使用的密码套件而有所不同。
当不需要这些信息时,将不会发送ServerKeyExchange消息。

(5) CertifcateRequest(客户端<-服务端)

CertifcateRequest消息用于服务器向客户端请求证书,这是为了进行客户端认真。通过这一消息,服务器会向客户端发送下列信息:

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

当不使用客户端认证时,不会发送CertifcateRequest消息。

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

这一消息表示从ServerHello消息开始的一系列消息的结束。

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

当步骤(5)中服务器发送了CertifcateRequest消息时,客户端会将自己的证书同Certificate消息一起发送给服务器。
服务器读取客户端的证书并进行验证。
当服务器没有发送CertificateRequest消息时,客户端不会发送Certificate消息。

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

当密码套件中包含RSA时,会随ClientKeyExchange消息一起发送经过加密的预备主密码。
当密码套件中包含Diffie-Hellman密钥交换时,会随ClietnKeyExchange消息一起发送Diffie-Hellman的公开值。
预备主密码(pre-master secret)是由客户端生成的随机数,之后会被用作生成主密码的种子。这个值会在服务器的公钥进行加密后发送给服务器。

根据预备主密码,服务器和客户端会计算出相同的主密码,然后再根据主密码生成下列比特序列(密钥素材)。

对称密码的密钥
消息认证码的密钥
对称密码的CBC模式中使用的初始化向量(IV)

问题:客户端使用服务器的公钥对预备主密码进行加密的,那么客户端又是什么时候得到服务器的公钥的呢?
客户端是在收到服务器发送的Certificate消息时获得服务器的公钥的。

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

客户端只有在服务器发送CertificateRequest消息时才会发送CertificateVerify消息。这个消息的目的是向服务器证明自己的确持有客户端证书的私钥。

为了实现这一目的,客户端会计算“主密码”和“握手协议中传送的消息”的散列值,并加上自己的数字签名后发送给服务器。

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

ChangeCipherSpec并不是握手协议的消息,而是密码规格变更协议的消息。
在ChangeCipherSpec消息之前,客户端和服务器之间已经交换了所有关于密码套件的信息,因此在收到这一消息时,客户端和服务器会同时切换密码。

在这一消息之后,TLS记录协议就开始使用双方协议决定的密码通信方式了。

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

由于已经完成了密码切换,因此Finished消息是使用切换后的密码套件来发送的。实际负责加密操作的是TLS记录协议。

Finished消息的内容是固定的,因此服务器可以将收到的密文解密,来确认所收到的Finished消息是否正确。通过这一消息,就可以确认握手协议是否正常结束,密码套件的切换是否正确。

(12)ChangeCipherSpec(客户端<-服务器)

(13)Finished(客户端<-服务器)

这一消息会使用切换后的密码套件来发送。实际负责加密操作的是TLS记录协议。

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

在此之后,客户端和服务器会使用应用数据协议和TLS记录协议进行密码通信。
从结果来看,握手协议完成了下列操作。

客户端获得了服务器的合法公钥,完成了服务器认证
服务器获得了客户端的合法公钥,完成了客户端认证(当需要客户端认证时)
客户端和服务器生成了密码通信中使用的共享密钥
客户端和服务器生成了消息认证码中使用的共享密钥

2)密码规格变更协议

密码规格变更协议是TLS握手协议的一部分,负责向通信对象传达变更密码方式的信号。用于密码切换的同步。

为什么这个协议不叫密码规格开始协议,而是要叫做密码规格变更协议呢?因为即便在密码通信开始之后,客户端和服务器也可以通过重新握手来再次改变密码套件。也就是说,在最开始的时候,客户端和服务器是使用“不加密”这一密码套件进行通信的,因此通信内容没有进行加密。

3)警告协议

警告协议是TLS握手协议的一部分,负责在发生错误时将错误传达给对方。
当握手协议的过程中产生异常,或者发生消息认证码错误、压缩数据无法解压缩等问题时,会使用该协议。

4)应用数据协议

应用数据协议是TLS握手协议的一部分,用于和通信对象之间传送应用数据。应用数据协议是将TLS上面承载的应用数据传达给通信对象的协议。

当TLS承载HTTP时,HTTP的请求和响应就会通过TLS的应用数据协议和TLS记录协议来进行传送。

主密钥&预备主密钥

主密钥

主密钥是TLS客户端和服务器之间协商出来的一个秘密的数值。这个数值非常重要,TLS密码通信的机密性和数据的认证全部依靠这个数值。主密码是一个48字节(384比特)的数值。

主密钥的计算
主密钥是客户端和服务器根据下列信息计算出来的。

预备主密码

客户端随机数
服务器随机数

当使用RSA公钥密码时,客户端会在发送ClientKeyExchange消息时,将经过加密的预备主密钥一起发送给服务器。
当使用Diffie-Hellman密钥交换时,客户端会在发送ClientKeyExchange消息时,将Diffie-Hellan的公开值一起发送给服务器。根据这个值,客户端和服务器会各自生成预备主密钥。

客户端随机数和服务器随机数的作用相当于防止攻击者实现计算出密钥的盐。
当根据预备主密码计算主密钥时,需要使用基于密码套件中定义的单向散列函数来实现的伪随机函数(Pseudo Random Function,PRF)

主密钥的目的

主密钥用于生成下列6种信息
对称密码的密钥(客户端->服务器)
对称密码的密钥(客户端<-服务器)
消息认证码的密钥(客户端->服务器)
消息认证码的密钥(客户端<-服务器)
对称密码的CBC模式所使用的初始化向量(客户端->服务器)
对称密码的CBC模式所使用的初始化向量(客户端<-服务器)

TLS中使用的密码技术小结

TLS握手协议中使用的密码技术

密码技术作用
公钥密码加密预备主密钥
单向散列函数 构成伪随机数生成器
数字签名验证服务器和客户端的证书
伪随机数生成器 生成预备主密钥、根据主密码生成密钥(密码参数)、生成初始化向量

TLS记录协议中使用的密码技术

密码技术作用
对称密码(CBC模式)确保片段的机密性
消息认证码确保片段的完整性并进行认证
认证加密(AEAD)确保片段的完整性和机密性并进行认证
  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值