传输层的安全协议——SSL/TLS,及HTTPS的工作原理

发布于:2022-11-09 ⋅ 阅读:(11) ⋅ 点赞:(0) ⋅ 评论:(0)

一、SSL(Socket Secure Layer)/TLS(Transport Layer Security)

1. 概述

  • SSL是TLS的前身,TLS 1.0在SSL 3.0的基础上提出;
  • TLS基于TCP,建立两个应用进程之间的安全传输连接;
  • 实现服务器的身份鉴别并生成数据安全传输所需要的安全参数,此外还可以用于鉴别客户的身份。

2. TLS协议结构

  • TLS协议由两层协议组成:
    • TLS握手协议:在前半部分介绍;
    • TLS记录协议:在"第三部分——HTTPS"介绍。

在这里插入图片描述

二、TLS的握手协议

握手协议用于实现身份鉴别安全参数协商

1. 第一阶段(双方发包):双方约定算法

在这一阶段,双方对压缩算法、加密算法、MAC算法和TLS版本达成一致。

  • 客户端Client(以下简称客户C):

    客户C通过发送客户Hello消息,告知服务器自己支持的算法、TLS版本号以及一个客户随机数NonceC(在第四阶段再提及)。

  • 服务器端Server(以下简称服务器V):

    服务器C通过发送服务器Hello消息,按照自己的优先度选择一种客户C支持的算法,在双方支持的TLS版本种选择较低的版本作为双方约定的TLS版本,并且发送一个服务器随机数NonceV(在第四阶段再提及)。

在这里插入图片描述

2. 第二阶段(服务器V发包):让客户C能验证服务器证书

在这一阶段,客户C开始对服务器V做身份鉴别工作(实际存在多种鉴别服务器V身份的机制,本文仅以"证书+私钥"为例),值得注意的是,实际上该阶段并没有完成对服务器V的身份鉴别。

  • 让客户C能验证服务器证书:服务器V向客户C发送证书链,客户C可以据此来明确公钥PKV(Public Key)和域名IDV的绑定关系:即公钥PKV对应域名IDV

    那服务器V应该怎么发证书链?

    ——服务器V根据客户C的信任点来发送对应的证书链。

    在这里插入图片描述

    如上认证关系示意图,如果客户C的信任点是认证中心A,那么服务器V就应该发送(服务器V=>认证中心D=>认证中心A)的证书链:即A<<D>>,D<<服务器V>>

    但是,这还不足以鉴别服务器V的身份,只有证明服务器V拥有和公钥PKV对应的私钥SKV(Secret Key)时,才能证明服务器V拥有域名IDV

  • 此外,服务器V也可以选择在这时请求客户C发送对方的证书链(需要给出自己拥有的证书链,来供客户C发送能够使服务器V信服的证书链),以此来鉴别客户C的身份。
    在这里插入图片描述

3. 第三阶段(客户C发包):①让服务器V能鉴别客户C的身份&②生成主密钥

  • ①仅当服务器V想要鉴别客户C的身份:

    • 如果在第二阶段时,服务器V请求鉴别客户C的身份,那么此时客户C将发送能够使服务器V信服的证书链。

      如下图,假如服务器V拥有的证书链是A<<D>>,D<<服务器V>>,那么客户C必须发送A<<B>>,B<<客户C>>

在这里插入图片描述

  • 此时,服务器V已经能确定PKC和IDC之间的绑定关系,但仍然不能确定客户C拥有公钥PKC的对应私钥SKC,该怎么办呢?

    • 客户C将双方的握手协议消息P(因为此时双方都拥有相同的握手协议信息)通过报文摘要MD(Message Digest)后,用私钥SKC进行解密运算后发送给服务器V;

      P=>MD(P)=>DSKC(MD(P))

    • 服务器V收到后用公钥PKC来对其进行加密运算后,将结果与自己之前保留着的握手协议消息的报文摘要值进行比较,若相同,则认为客户C通过身份鉴别,否则反之。

      DSKC(MD(P))=>EPKC(DSKC(MD(P)))=>MD(P)

在这里插入图片描述

  • ②生成主密钥:

    • 发送加密后的预主密钥

      • 客户C选择一个预主密钥PMK(Pre-Master Key)

      • 用服务器V的公钥PKV来加密PMK,得到Y,将其发送给服务器V;

        Y = EPKV(PMS)

      • 只有在服务器V拥有公钥PKV对应的私钥SKV时,才能得到PMK,。

        PMS = DSKV(Y) = DSKV(EPKV(PMS))

    • 客户C和服务器V,根据手中的预主密钥、客户Hello、服务器Hello、客户随机数NonceC和服务器随机数NonceV来计算主密钥MK(Main Key),计算公式如下:

      MK = PRF(PMS,“Master-Secret”,NoncenC||NonceV)

      其中,PRF(Pseudo Random Function)是伪随机数生成函数:

      PRF(密钥,标签,种子) = P_MD5(S1,标签||种子) ⊕ P_SHA-1(S2,标签||种子);

      S1是密钥的前半部分,S2是密钥的后半部分;标签是任意的字符串;种子是限制报文摘要运算长度的字符串;

      在主密钥计算公司中,将预主密钥PMS作为PRF中的密钥,"Master-Secret"作为PRF的标签,将客户随机数NonceC和服务器随机数NonceV连接起来作为PRF的种子。

在这里插入图片描述

4. 第四阶段(双方发包):身份鉴别&改变密码规范

  • 身份鉴别:

    ①只要服务器V有了预主密钥PMK,就说明其有了公钥PKV对应的私钥SKV,则可以认为服务器V的通过身份鉴别;
    ②而要想确认服务器V拥有了预主密钥PMK,只需要确认其拥有正确的(与客户C相同)主密钥MK即可。

    所以在第四阶段,服务器V向客户C发送结束消息,其中包含了"PRF(MK,“server finished”,MD5(握手协议消息)||SHA-1(握手协议消息))";

    随后客户C按照同样的方式,用自己手中的MK和握手协议信息也进行PRK运算,并将运算结果与服务器V结束消息中的字段对比,若相同则则服务器V的身份得到确认。

  • 改变密码规范:

    后续双方都可以使用协商好的安全参数(如主密钥MK)来进行。

在这里插入图片描述

握手协议小结:
发送被信任的证书链=>接收方可以确定发送方的公钥和域名的绑定关系;
但只有接收方确认发送方拥有其公钥对应的私钥时,发送方才算通过身份鉴别。

三、HTTPS(HTTP over Secure socket layer)

HTTPS基于SSL/TLS

1. HTTPS工作示意

在这里插入图片描述

2. TLS记录协议

在客户端和服务端成功建立了TLS连接后,由TLS记录协议来封装上层的HTTP报文数据

  • TLS记录协议工作示意:
    在这里插入图片描述

  • 接收方只需要对TLS记录协议采取上述的逆过程即可:

    (解密=>检测数据完整性(MAC值)=>解压缩=>按序号重组HTTP报文)

  • 关于计算MAC:

    • 封装好的TLS握手协议中包含一个序号字段,会随着每次TLS记录协议报文的发送而增加1;

    • 序号参与MAC计算,则可以防止重放攻击及TLS记录报文丢失。