SSL协议详解

  • Post author:
  • Post category:其他



目录


1、SSL简介


2、SSL协议结构


2.1 SSL工作大致可以分为两个阶段(类比于IPsec的话)


3、SSL原理


3.1 SSL握手协议第一阶段


3.2 SSL握手协议第二阶段


1.Certificate(可选)——第一次建立必须要有证书


2.Server Key Exchange(可选)


3.Certificate Request(可选)——可以是单向身份认证,也可以是双向


4.Server hello


3.3 SSL握手协议第三阶段


1.Certificate(可选)


2.Client Key Exchange


3.Certificate Verify(可选)


3.4 SSL握手第四阶段


1.Change Cipher Spec


2.Client finished


3.Server Finished


3.5 消息验证代码(MAC)与数据完整性


3.6 两个重要的密钥


Pre-master secret


Main-master secret


4、SSL原理—会话恢复


4.1 两种会话机制


4.2 恢复过程


5、SSL记录协议


5.1 工作过程


1、SSL简介


SSL





Security Socket Layer


)是一个安全协议,为基于TCP





Transmission Control Protocol)的应用层协议提供安全连接,


SSL


介于


TCP/IP


协议栈第四层和第七层之间。主要提供

私密性、完整性和身份验证

;我们常见的就是 SSL为


HTTP





Hypertext Transfer Protocol


)协议提供安全连接。


SSL协议是一种在两个机器之间提供安全通道的协议,它具有保护数据传输以及识别通信机器的功能。

内的愈来愈多的浏览器支持SSL,SSL协议成为应用最广泛的安全协议之一。到目前为止,SSL协议有三个版本,其中SSL2.0和SSL3.0得到广泛的应用,IETF基于SSL3.0推出了TLS1.0协议(也被称为SSL3.1)。随着SSL协议的不断完善,包括微软lE在内的越来越多浏览器支持SSL协议。

2、SSL协议结构

SSL协议分为两层,下层为SSL记录协议,上层为SSL握手协议、SSL密码变化协议和SSL警告协议。


1.

下层为SSL记录协议,主要作用是为高层协议提供基本的安全服务

建立在可靠的传输之上,负责对上层的数据进行分块、压缩、计算并添加MAC(消息验证码) 、加密,最后把记录块传输给对方。


2.

上层为SSL握手协议、SSL密码变化协议和SSL报警协议


1>

SSL握手协议:SSL握手协议被封装在SSL记录协议中,该协议允许服务器与客户端在应用程序传输和接收数据之前

互相认证、协商加密算法和密钥

。在初次建立SSL连接时,服务器与客户机交换一系列消息。


2>

SSL修改密文协议:保障SSL传输过程中的安全性,客户端和服务器双方应该每隔一段时间改变加密规范


3>

SSL报警协议:用来为对等体传递SSL的相关警告。如果在通信过程中某一方发现任何异常,就需要给对方发送一条警示消息通告。

2.1 SSL工作大致可以分为两个阶段(类比于IPsec的话)


1.第一阶段:

Handshake phase(握手阶段)

  • 协商加密算法
  • 认证服务器
  • 建立用于加密和MAC(Message Authentication Code)的会话密钥

该阶段类似于IPsec IKE的作用


2.第二阶段:

Secure data transfer phase(安全数据传输阶段)

在已经建立的SSL数据通道里安全的传输数据

该阶段类似于IPsec ESP/AH的作用

3、SSL原理

在用SSL进行通信之前,首先要使用SSL的Handshake协议在通信两端握手,协商数据传输中要用到的相关安全参数(如加密算法、共享密钥、产生密钥所要的材料等),并对对端的身份进行验证。

3.1 SSL握手协议第一阶段

客户端首先发送Client hello消息到服务器端,服务器收到消息后回复一个Server hello消息给客户端。

建立起安全属性,客户端发送一个Client hello消息,包括如下参数:

  • 版本:按优先级列出客户端支持的版本,首选客户端支持的最新版本。
  • 会话ID:会话ID标识一次会话,可以重复使用。
  • 随机数:用于计算后面所有消息的摘要或者计算预主密钥。
  • 密码算法列表:客户端会列出自己的密码套件,服务器会从中选出其中一套用来加密会话。
  • 压缩方法:为了减少带宽占用,可以进行压缩。

收到

客户端问候

之后服务器必须发送

服务器问候

信息,服务器会检查指定诸如版本和算法的客户端问候的条件,如果服务器接受并支持所有条件,它将发送其证书以及其他详细信息,否则,服务器将发送握手失败消息。,包括的参数如下:

  • 版本:服务器拿出client hello消息中的版本号,再看看自己支持的版本列表,选择两者都支持的最高的版本号作为这次通信的版本号。
  • 服务器产生的随机数:效果和客户端产生的随机数一致。(此时通信双方都分别拥有自己和对方的随机数)
  • 会话ID:服务器检测传过来的session Id,如果检索为空,没有发现传过来的Session ID,服务端会新建一个。
  • 服务器从客户端建议的密码套件中挑出一套密码算法。
  • 服务器从客户端建议的压缩算法中挑出一套压缩算法。

在此阶段之后通信双方分别确定了:

  • SSL版本
  • 密钥交换、信息验证和加密算法
  • 压缩算法
  • 通信双方的随机数(关于密钥的生成)

3.2 SSL握手协议第二阶段

服务器向客户端发送消息,本阶段服务器是唯一发送方,客户端是唯一接收方。

本阶段共有四个消息,如下:

  1. 证书:服务器将数字证书和到根CA整个链发给客户端,使客户端能用服务器证书中的服务器公钥认证服务器。
  2. 服务器密钥交换(可选):这里视密钥交换算法而定。
  3. 证书请求:服务端可能会要求客户自身进行验证。
  4. 服务器握手完成:第二阶段的结束,第三阶段开始的信号

1.Certificate(可选)——第一次建立必须要有证书

  • 一般情况下,除了会话恢复时不需要发送该消息,在SSL握手的全过程中都需要该消息。消息中包含一个X.509证书,证书中包含公钥,发给客户端用来验证签名或者在密钥交换时给消息加密。
  • 这一步是服务端将自己的证书下发给客户端,让客户端验证自己的身份,客户端验证通过后取出证书中的公钥,以便后面的使用。

2.Server Key Exchange(可选)

根据之前的client hello消息中的cipther suite信息决定了,密钥交换的方法(例如RSA和DH),因此在此消息中便会完成密钥交换所需的一系列参数。

3.Certificate Request(可选)——可以是单向身份认证,也可以是双向

这一步是可选的,在安全性要求高的场合可以看到;服务端发送Certificate Request消息,请求客户端发送他自己的证书来进行验证。该消息中包含服务器端支持的证书类型(RSA、DSA、ECDSA),和服务器所信任的所有证书的发行机构的CA列表,客户端会用这些信息来筛选证书。

4.Server hello

表示服务器已将所有的信息发送完毕,等待客户端发送消息

3.3 SSL握手协议第三阶段

客户收到服务器发送的一系列消息并解析后,将本段相应的回应发送给服务器;此阶段客户端是消息唯一发送方,服务器端是消息唯一接收方。

本阶段共有三个消息,如下:

  1. 证书(可选):为了对服务器证明自身,客户要发送一个证书信息,这是可选的,在IIS中可以配置强制客户端证书认证。
  2. 客户机密钥交换(Pre-master-secret):这里客户端将预备主密钥发送给服务端,注意这里会使用服务端的公钥进行加密。
  3. 证书验证(可选):对从第一条消息以来的所有握手消息进行签名。

1.Certificate(可选)

如果在第二阶段服务器要求客户端发送证书,客户端便会发送自己的证书,服务器端之前在发送的Certificate Request消息中包含了服务器所支持的证书类型和CA列表,客户端会在证书中找到满足要求的一个发送给服务器。若客户端没有证书,则会发送一个no_certificate警告。

2.Client Key Exchange

  • 根据之前从服务端收到的随机数,按照不同的密钥交换算法,算出一个Pre-master,发送给服务器,服务器收到pre-master,算出一个main-master。而客户端也能通过Pre-master自己算出一个main-master。如此一来,双方就算出了对称密钥。
  • 如果是RSA算法,会生成一个48位的随机数,然后用server的公钥加密后放入报文中;如果是DH算法,发送的就是客户端的DH参数,之后客户端和服务端根据DH算法,计算出相同的Pre-master secret。
  • 本消息在发送过程中,使用了服务器的公钥加密,服务器在收到后需要用服务器的私钥解密才能得到Pre-master Key。

3.Certificate Verify(可选)

只有在客户端在发送了证书到服务端时,这个消息才需要发送,其中包含签名,对从握手第一条消息以来的所有握手消息的HMAC值(用master_secret)进行签名。

3.4 SSL握手第四阶段

完成SSL握手协议,建立SSL连接

该阶段有四个消息交互,前两个为客户端发送,后两个为服务器发送。

建立起一个安全的连接,客户端发送一个Change Cipher spec消息,并且把协商得到的Cipher suite拷贝到当前连接的状态之中。然后客户端使用新的算法和密钥参数发送一个Finished消息,这条消息可以检测密钥交换和认证过程是否已经成功,其中包括一个校验值,对客户端整个握手消息进行校验。服务器同样发送一个Change Cipher Spec消息和Finished消息。握手过程完成,客户端和服务器可以交换应用层数据进行通信。

1.Change Cipher Spec

编码改变通知,表示随后的信息将用双方商定的加密算法和和密钥发送(

ChangeCipherSpec

是一个独立的协议,体现在数据包中就是一个字节的数据,用于告知服务端,客户端已经切换到之前协商好的加密套件(Cipher Suite)的状态,准备使用之前协商好的加密套件加密数据并传输了)。

2.Client finished

客户端握手结束通知,表示客户端的握手阶段已经结束。这一项同时也是前面所有发送的内容的hash值,用来供服务器校验。(使用

HMAC算法

计算收到和发送的所有握手消息的摘要,加密后发送。此数据是为了在正式传输应用数据之前对刚刚握手建立起来的加解密通道进行验证。)

3.Server Finished

服务端握手结束通知。

  1. 使用私钥解密加密的Pre-master数据,基于之前(Client Hello 和 Server Hello)交换的两个明文随机数 random_C 和 random_S,计算得到协商密钥:enc_key=Fuc(random_C, random_S, Pre-Master);
  2. 计算之前所有接收信息的hash值,然后解密客户端发送的 encrypted_handshake_message,验证数据和密钥正确性;
  3. 发送一个Change Cipher Spec(告知客户端已经切换到协商过的加密套件状态,准备使用加密套件和 Session Secret加密数据了)
  4. 服务端也会使用Session Secret加密一段Finish消息发送给客户端,以验证之前通过握手建立起来的加解密通道是否成功。

根据之前的握手信息,如果客户端和服务端都能对Finish信息进行正常加解密且消息正确的被验证,则说明握手通道已经建立成功,接下来,双方可以使用上面产生的Session Secret对数据进行加密传输了。

3.5 消息验证代码(MAC)与数据完整性

当服务器或客户端使用主密钥加密数据时,它还会计算明文数据的校验和(哈希值),这个校验和称为

消息验证代码(MAC)

。然后在发送之前将MAC包含在加密数据中。密钥用于从数据中生成MAC,以确保传输过程中攻击者无法从数据中生成相同的MAC,故而MAC被称为HMAC(哈希消息认证码)。另一方面,在接收到消息时,解密方将MAC与明文分开,然后用它的密钥计算明文的校验和,并将其与接收到的MAC进行比较,如果匹配,那我们就可以得出结论:数据在传输过程中没有被篡改。

3.6 两个重要的密钥

Pre-master secret

Pre-Master Secret是在客户端使用RSA或者Diffie-Hellman等加密算法生成的。它将用来跟服务端和客户端在Hello阶段产生的随机数结合在一起生成 Master Secret。Pre-Master secret前两个字节是TLS的版本号,这是一个比较重要的用来核对握手数据的版本号。服务端需要对密文中解密出来对的Pre-Master版本号跟之前Client Hello阶段的版本号进行对比,如果版本号变低,则说明被串改,则立即停止发送任何消息。

Main-master secret

由于最后通过交换,客户端和服务端都会有Pre-master和随机数,这个随机数将作为后面产生Master secret的种子,结合Pre-Master secret,客户端和服务端将计算出同样的Master secret。

4、SSL原理—会话恢复

会话恢复是指只要客户端和服务器已经通信过一次,它们就可以通过会话恢复的方式来跳过整个握手阶段而直接进行数据传输。SSL采用会话恢复的方式来减少SSL握手过程中造成的巨大开销。此功能从之前的13步减少到6步,大大减少了开销。

4.1 两种会话机制

  • 会话标识 session ID: 由服务器端支持,协议中的标准字段,因此基本所有服务器都支持,服务器端保存会话ID以及协商的通信信息,Nginx 中1M 内存约可以保存4000个 session ID 机器相关信息,占用服务器资源较多;
  • 会话记录 session ticket :需要服务器和客户端都支持,属于一个扩展字段,支持范围约60%(无可靠统计与来源),将协商的通信信息加密之后发送给客户端保存,密钥只有服务器知道,占用服务器资源很少。

二者对比,主要是保存协商信息的位置与方式不同,类似与 http 中的 session 与 cookie。二者都存在的情况下,(nginx 实现)优先使用 session_ticket。

4.2 恢复过程

如果服务器和客户端之间曾经建立过连接,服务器会在握手成功后返回一个session ID,并保存对应的参数在服务器中。如果客户端和服务器需要再次连接,则需要在Client hello消息中携带记录的信息,返回给服务器。服务器根据收的到的Session ID检索缓存记录,如果有缓存,则返回一个Change Cipher Spec消息和Finished消息,如果没有缓存则正常进行握手。如果客户端能够验证通过服务器加密数据,则同样回复一个Change Cipher Spec消息和Finished消息。服务器验证通过则握手建立成功,开始进行正常的加密数据通信。

5、SSL记录协议

SSL记录协议主要用于实现对数据的分块、加密解密、压缩解压缩、完整性检测和封装各种高层协议。

主要包括:

  • 内容类型
  • 协议版本号
  • 记录数据的长度
  • 数据有效载荷
  • 散列算法计算消息认证代码

5.1 工作过程

  1. 将上层分下来的数据包分成合适的数据块,但是每个数据块不得超过214字节。
  2. 对每个数据块进行压缩,但是不能丢失数据信息。
  3. 计算压缩后的数据消息认证码MAC,并添加在压缩包后。添加后总长度不得超过2262字节。
  4. 对称密码加密。
  5. 给SSL添加一个首部。其中包括:内容类型、主要版本、次要版本、压缩长度等信息。通过以上过程把原始的数据加密为SSL协议的记录集。

参考:

https://blog.csdn.net/qq_38265137/article/details/9011



版权声明:本文为weixin_43997530原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。