0.2、计算机网络-TLS 协议

缺乏、安全感 2022-01-24 00:23 355阅读 0赞

### 文章目录 ###

*   *   *   *  前言
             *  TLS 的基本介绍
             *  RFC 2246
             *   *  第一部分-关键术语
                 *  第二部分-Key Exchange 算法和对应证书类型
                 *  第三部分-握手协议和 master key
                 *   *  握手协议
                     *  算法计算
                 *  第四部分-一次完整的流程
             *  参考资料

#### 前言 ####

> 体能状态先于精神状态，习惯先于决心，聚焦先于喜好

#### TLS 的基本介绍 ####

> TLS 的全称是 Transport Layer Security，从这个名字看我们可以认为它属于运输层

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2Jlc3RjeHg_size_16_color_FFFFFF_t_70]

> TLS 主要用于 Https 协议中对Http 协议的加密  
> 下图只是一个简略图,TLS 并不单单使用 RSA 算法,其算法套件包含了 对称加密、非对称加密和数字验签的算法约定.  
> TLS的前身是SSL,SSL有1.0,2.0,3.0 三个版本,SSL3.0时制定了 TLS1.0;SSL3.0和TLS1.0相差不大.  
> 目前TLS已经发展到 TLS1.3

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2Jlc3RjeHg_size_16_color_FFFFFF_t_70 1]

#### RFC 2246 ####

> 关于 TLS的RFC2246 文档地址为 [http://www.rfc-editor.org/info/rfc2246][http_www.rfc-editor.org_info_rfc2246]  
> 需要注意,美国政府不允许包含 大于 512位key的 RSA 加密模块的软件的出口,但是并没有限制大于 512位key的RSA 算法用于数字签名.

##### 第一部分-关键术语 #####

*  XXX alert:各种各样的报错信息.
 *  X.509:一种非常通用的证书格式。所有的证书都符合ITU-T X.509国际标准，因此(理论上)为一种应用创建的证书可以用于任何其他符合X.509标准的应用。
 *  cipher suites:加密规范,包含了交互的协议、key协商的非对称加密算法、大批量数据加密的对称加密算法、验签的散列算法,形式如TLS\_ECDHE\_ECDSA\_WITH\_AES\_128\_GCM\_SHA256.
 *  Key Exchange Algorithm:密钥交换算法,即公钥交换的方式,RSA、RSA\_EXPORT、DHE\_DSS、  
    DHE\_DSS\_EXPORT、DHE\_RSA、DHE\_RSA\_EXPORT、DH\_DSS、DH\_RSA
 *  certificate:证书,可以由CA签发,或者自签发,证书需要有验签,证书提供的public key也需要有验签.
 *  key exchange method:由于TLS协议一般涉及大批量数据的对称加密,对称加密的key需要使用非对称加密方法在客户端和服务端之间进行协商,这就涉及到这个非对称的key如何交换.
 *  signing algorithm:验签算法,这里可以认为是摘要算法.
 *  Diffie-Hellman:一种确保共享KEY安全穿越不安全网络的方法，它是OAKLEY的一个组成部分。Whitefield与Martin Hellman在1976年提出了一个奇妙的密钥交换协议，称为Diffie-Hellman密钥交换协议/算法(Diffie-Hellman Key Exchange/Agreement Algorithm).这个机制的巧妙在于需要安全通信的双方可以用这个方法确定对称密钥。然后可以用这个密钥进行加密和解密。但是注意，这个密钥交换协议/算法只能用于密钥的交换，而不能进行消息的加密和解密。双方确定要用的密钥后，要使用其他对称密钥操作加密算法实现加密和解密消息.
 *  PKIX:IETF的安全领域的公钥基础实施（PKIX）工作组正在为互联网上使用的公钥证书定义一系列的标准.
 *  digitalSignature bit:证书的数字签名位,当证书key使用扩展时,该位必须设置.
 *  keyEncipherment bit:证书的密钥加密位,当证书key使用扩展时,该位必须设置.
 *  keyAgreement bit:密钥协商位,当使用 Diffie-Hellman 类型证书时,这个位必须设置.
 *  自签名证书和CA证书:CA是公认的证书颁发机构,浏览器可以通过一定的方式去确认证书的真实性,自签名的证书是自己生成的,由于存在可能被复制的可能,可能会存在中间人攻击的危险.再一个区别是,CA证书是由权威机构发布的,可以进行注销,注销后浏览器可以得知这个证书被注销,而自签名证书是不可以注销的——因为无处注销.
 *  premaster secret:客户端和服务端最终通过对称加密端方式交互,对称加密端key被成为 master secret,其遵从一个算法,而premaster secret 是该算法的一个入参,由客户端生成,或者客户端和服务端协商生成.
 *  透明:意思是,上一层无需感知下一层的具体处理措施.只需按照规定的方式向下一层传递消息,或者从下一层接受消息.

##### 第二部分-Key Exchange 算法和对应证书类型 #####

> 证书类型和 key exchange 算法存在关联关系

<table> 
 <thead> 
  <tr> 
   <th>Key Exchange 算法</th> 
   <th>证书类型</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>RSA</td> 
   <td>RSA public key; 证书必须允许该key 被用于加密</td> 
  </tr> 
  <tr> 
   <td>RSA_EXPORT</td> 
   <td>当 RSA public key 当长度大于 512位时,可被用于数字签名;当key长度小于或者等于512位时既可以用于数字签名也可用于加密</td> 
  </tr> 
  <tr> 
   <td>DHE_DSS</td> 
   <td>DSS public key</td> 
  </tr> 
  <tr> 
   <td>DHE_DSS_EXPORT</td> 
   <td>DSS public key</td> 
  </tr> 
  <tr> 
   <td>DHE_RSA</td> 
   <td>RSA public key,可用于数字签名</td> 
  </tr> 
  <tr> 
   <td>DHE_RSA_EXPORT</td> 
   <td>RSA public key,可用于数字签名</td> 
  </tr> 
  <tr> 
   <td>DH_DSS</td> 
   <td>Diffie-Hellman key,证书的数字签名算法需要是DSS</td> 
  </tr> 
  <tr> 
   <td>DH_RSA</td> 
   <td>Diffie-Hellman key,证书的数字签名算法需要是RSA</td> 
  </tr> 
 </tbody> 
</table>

##### 第三部分-握手协议和 master key #####

> 第三部分分为两个部分  
> 第一部分是握手部分,用于客户端和服务端交换证书、互相认证、生成随机数、确定交互的算法套件(非对称加密算法、对称加密算法、数字签名算法).确定 premaster secret.  
> 第二部分将生成用于对称加密数据交互的 master key

###### 握手协议 ######

1、Hello request-可选消息:

> 可由服务端在任意时间发送,通知客户端从新发起一个 Client hello,从新开始协商过程;  
> 该消息允许客户端忽略或者 Client hello,或者 no\_renegotation alert;  
> 服务端在收到回复前,不会重复请求,直到握手协商结束,或以致命错误关闭此连接.

2、Client hello必有消息:

> 三种情况下客户端可能发送Client hello 消息:(1)当客户端第一次连接服务端时;(2)作为对服务端 Hello request 消息的回复;(3)客户端自发的向一个已存的连接从新发起安全协商.  
> Client hello 包含以下几个主要信息:(1)gmt\_unix\_time,当前系统时间(GMT19700101至今的秒数);(2)sessionID,32位,记录session,该值第一次为空,如果是重复访问可以不为空,服务端如果查询session缓存找到对应session 的话可以复用该 sessionID;(3)CipherSuites,加密套件,加密簇,加密规范,形式如TLS\_ECDHE\_ECDSA\_WITH\_AES\_128\_GCM\_SHA256 ,不止一个,表示客户端支持的加密规范,包含了协议TLS,非对称加密算法,对称加密算法和散列算法的描述;按照客户端喜好程度从前往后排序.后面服务端会依据自己的情况综合选择一个cipher suite;(4)CompressionMethod:客户端支持的压缩算法列表,供服务端选择,可以为空.(5)random 一个随机数;(6)TLS协议版本,现在一般是TLS1.2或者TLS1.3;(7)其他很多信息,比如server\_name,即域名,更多其他信息暂不介绍.

3、Server hello-必有消息:

> 当服务端收到 Client hello 并且从自己的支持的 cipher suites 中匹配到客户端 Client hello 中提供的cipher spec的中的合适的一个(至少一个),服务端就会发送 Server hello,否则服务端会返回一个握手失败异常.  
> 服务端包含的以下几个主要信息:(1)TLS版本,现在一般是tls1.2或者tls1.3;(2)random随机数,这个随机数和 Client hello中的random值不同;(3)SessionID,如果客户端Client hello中 SessionID不为空,且客户端session 缓存可以找到对应的sessionID,那么就使用客户端的值,否则就新生成一个SessionID,如果有其他策略比如客户端SessionID失效,那么服务端也会重新生成一个SessionID;(4)CipherSuite,加密规范,服务端从客户端提供的CioherSuites 中选择一个自己支持且认为性能最好的加密规范;(4)CompressionMethod,服务端从客服端提供的压缩算法中选择一个自己支持的压缩算法,可以为空.

4、Server certificate-可选消息

> 只要 key exchange 方法不是匿名的,Server certificate 就应该在Server hello 消息之后被立即发送.  
> certificate 一般是一个 X.509v3 证书,证书类型必须满足之前选择的 key exchange算法;  
> 如果没有特殊规定,证书的验签和证书的key的验签算法应该一样.

> 从消息结构上来说,有可能是一个 X.509v3证书链.该证书链遵循以下几个规则:(1)发送者的证书必须位于第一位(2)后面的证书必须证明其之前紧邻的证书(3)因为证书的验签需要 root keys被单独的传送过去,自定义根证书的自验签的证书可能被选择性的从证书链中忽略验签过程.发送证书的远程访问结束时证书应该已经被拥有了,以便于在任何时候对其进行验签.

> 需要注意的是,如果服务端对客户端发起了 certificate request 消息,并且在客户端拥有合适的证书的情况下,客户端也因该向服务端发送证书.

5、Server key exchange -可选消息

> 一般而言,客户端在验证服务端证书(自验签的根证书无需验证)的可靠性之后,客户端会使用服务端证书提供的公钥来传递自己的  
> premaster secret,但是当服务端证书提供的信息不完全充足,就需要服务端再发送一个 server key exchange 消息.  
> 这条信息包含了客户端如何向服务端发送 premaster secret 的加密信息.  
> 根据美国的出口法律,包含大于 512位的RSA加密模块的软件无法从美国出口,但是对于数字签名是没有限制的.

> 当需要发送 server key exchange 消息时,其发送顺序由两种可能:  
> (1)在 server certificate 消息被发送后,server key exchange 消息会被立即发送.  
> (2)如果客户端发起的是匿名请求无需发送 server certificate 的时候,在服务端在发送 server hello之后就应该发送 server key exchange 消息.

> key exchange 的加密方法:

<table> 
 <thead> 
  <tr> 
   <th>合法方法</th> 
   <th>不合法方法</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>RSA_EXPORT (当服务端证书的 public key 大于 512位)、DHE_DSS、DHE_DSS_EXPORT、DHE_RSA、DHE_RSA_EXPORT、DH_anon</td> 
   <td>RSA、RSA_EXPORT (当服务端证书的 public key 小于或等于 512位)、DH_DSS、DH_RSA</td> 
  </tr> 
 </tbody> 
</table>

6、Certificate request-可选消息

> 一个非匿名的服务端在选择对应 cipher suite 的情况下,可以有选择的向客户端请求一个证书.

> 如果服务端会向客户端发送 Certificate request 信息,其顺序有两种情况:(1)服务端发送 Server Key Exchange 消息之后,立即发送certificate request 消息;(2)根据 cipher suite ,服务端未必会发送 server key Exchange 消息,这个时候在服务端发送完 Server certificate 消息之后,就会立即发送Certificate request 消息.

> 该信息包含的数据结构包含下面几个要素:  
> ClientCertificateType 证书类型:rsa\_sign(1), dss\_sign(2), rsa\_fixed\_dh(3), dss\_fixed\_dh(4)

> DistinguishedName:服务端可接受认证的证书名字.这意味着服务端可以指定证书的颁发机构,比如需要被CA认证.标准遵从 X509

> 如果该请求来自一个匿名的服务端,会导致一个致命错误.  
> 客户端在收到服务端正确的的证书请求后需要发送证书给服务端,该过程参考下面论述的 Client certificate

7、Server hello done-必有消息

> 当服务端的server hello环节需要发送的消息结束的时候,服务端会向客户端发送 server hello done 消息.  
> 这一步表示服务端已客户端已经初步建立了密钥交换的渠道,服务端会等待客户端的下一步操作.

8、Client certificate-可选消息

> 只有服务端向客户端请求证书的时候,客户端才会发送该消息;而且该消息需要在客户端收到服务端的 server hello done 消息之后才会发送.

> 由于服务端指定了证书类型,在客户端没有对应类型证书的时候,客户端可以发送一个不含证书的消息,如果该证书消息是握手过程的一部分,客户端在没有可用证书的情况下可以返回一个错误.

> 消息格式和Server certificate一致.

> 客户端的证书同样需要一个验签的过程,当验签方式为基于 key exchange 的 Diffie-Hellman 时,客户端使用的方式必须匹配服务端指定的方式.

9、Client key exchange -必有消息

> 如果客户端需要向服务端发送证书,则在发送完毕证书后,会发送 client key exchange 消息;  
> 如果客户端无需发送证书,那么在收到server hello done 消息后就会发送 client key exchange 消息.

> 该消息会设置 premaster secret.传输方式有两种,一种是通过服务端证书提供的公钥使用 RSA-加密该 secret 值;第二种方法是客户端 和 服务端通过 Diffie-Hellman 方式最终共同确定 premaster secret的值.  
> 但是当客户端被请求的证书类型是DH\_RSA or DH\_DSS,并且客户端可以提供一个满足服务端要求并且包含一个Diffie-Hellman public key的证书,那么这条消息将不会携带任何消息,因为服务端可以通过客户端提供的证书的key来获取premaster secret.

> RSA encrypted premaster secret message:  
> 客户端生成一个 48字节的 premaster secret,使用服务端证书的 public key 加密该字段;或者使用在证书提供信息不足时 server key exchange message 中提供的临时 RSA key 加密该字段.

> Client Diffie-Hellman public value:  
> 当客户端证书没有提供 Diffie-Hellman public value(Yc),服务端和客户端将共同协商出 premaster secret.

10、Certificate verify-可选消息

> 当客户端发送了证书给服务端,那么在客户端发送了 client key exchange 消息之后就会发送 certificate verify 消息.  
> 只有客户端证书具备数字签字能力时本信息才会被发送(证书包含 fixed Diffie-Hellman parameters 的除外)

11、change cipher spec-必有消息

> 该消息可由客户端或者服务端向对方发送,提醒对方后面开始的信息是经过了加密处理.  
> 该消息在握手期间发送,具体时间是 双方协商好 master secret 之后,Finished 消息之前.  
> 一般客户端和服务端分别发送自己的 change cipher spec 消息,并在之后发送 Finished 消息

12、Finished-必有消息

> change cipher spec 消息用于确认 key exchange 和认证过程成功,Finished 消息就会被发送.  
> 其表示change cipher spec消息被另一个握手信息成功接收并结束.

> Finished 是第一条被使用协商好的加密算法进行拆分数据、压缩、加密处理的消息.  
> Finished 一般在change cipher spec之后被发送

> Finished 包含一个 hash 值,包括了握手期间发送方所有协议的hash(不包含 Finished),用于接收方校验握手期间数据的安全性. 此外,Change cipher spec 消息 alerts and any other 记录也不会包含在hash 计算过程中,Hello Request会被忽略,即也不会被包含.

###### 算法计算 ######

> 该部分将确定 master key 的值

1、Computing the master secret

> master secret 一般是48字节,其中 ClientHello.random 为握手协议中客户端的随机数,ServerHello.random为服务端的随机数

> master\_secret = PRF(pre\_master\_secret, “master secret”,ClientHello.random + ServerHello.random)

> 当客户端使用服务端证书提供的公钥将 premaster secret 加密RSA加密传递给服务端,服务端和客户端将通过上面的公式生成相同的 master secret.  
> 如果客户端和服务端使用 Diffie-Hellman 方式协商生成premaster secret,双方也会按照上面的公式生成 master secret  
> 二者的区别在于,RSA 方式是客户端生成 premaster secret,Diffie-Hellman 是服务端和客户端协商生成 premaster secret

2、Mandatory Cipher Suites

> 如果没有特殊额外的 cipher suite 指定的话,标准的 TLS 应用应该遵循 cipher  
> suite TLS\_DHE\_DSS\_WITH\_3DES\_EDE\_CBC\_SHA.

3、Application data protocol

> 在 TLS 协议的最用下,应用的数据信息会被 Record 层基于当前的连接状态进行运输、拆分、压缩和加密.

> 对于 Record 层来说,这些应用消息是透明的,即相互之间无需感知对方是对数据的处理细节.

##### 第四部分-一次完整的流程 #####

> 从上面的内容我们可以知道,TLS 协议规定了许多消息形式,有一些消息是必须发送的,有一些消息则是依据客户端和服务端之间的 cipher suite 而定.  
> 总体而言,TLS协议被分为两个部分,第一部分用于服务端和客户端的身份确认和 premaster secret 的生成,第二部分用于生成 master secret,最终客户端和服务端使用 master secret 对应用数据进行透明的对称加密和解密传输.当然还涉及到数据的拆分、压缩.

> 标准术语:TLS 包含两部分  
> SSL记录协议（SSL Record Protocol）：它建立在可靠的传输协议（如TCP）之上，为高层协议提供数据封装、压缩、加密等基本功能的支持。  
> SSL握手协议（SSL Handshake Protocol）：它建立在SSL记录协议之上，用于在实际的数据传输开始前，通讯双方进行身份认证、协商加密算法、交换加密密钥等。面笔者提供一个完整的交互流程

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2Jlc3RjeHg_size_16_color_FFFFFF_t_70 2]

#### 参考资料 ####

> \[1\]、[http://www.rfc-editor.org/info/rfc2246][http_www.rfc-editor.org_info_rfc2246]  
> \[2\]、[https://blog.csdn.net/enweitech/article/details/81781405][https_blog.csdn.net_enweitech_article_details_81781405]  
> \[3\]、[https://blog.csdn.net/y97523szb/article/details/48864157][https_blog.csdn.net_y97523szb_article_details_48864157]

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2Jlc3RjeHg_size_16_color_FFFFFF_t_70]: /images/20220124/d7872047b67c45d08095d02f601f00f7.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2Jlc3RjeHg_size_16_color_FFFFFF_t_70 1]: /images/20220124/9d4fc6a7b251438ca2a483bc3770b192.png
[http_www.rfc-editor.org_info_rfc2246]: http://www.rfc-editor.org/info/rfc2246
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2Jlc3RjeHg_size_16_color_FFFFFF_t_70 2]: /images/20220124/4e50b6eec6aa460fb2280740d67aa9b1.png
[https_blog.csdn.net_enweitech_article_details_81781405]: https://blog.csdn.net/enweitech/article/details/81781405
[https_blog.csdn.net_y97523szb_article_details_48864157]: https://blog.csdn.net/y97523szb/article/details/48864157