其他分享
首页 > 其他分享> > TLS1.2协议设计原理

TLS1.2协议设计原理

作者:互联网

参考链接:https://www.cnblogs.com/Jack-Blog/p/13170728.html

前言

最近对TLS1.2协议处理流程进行了学习及实现,本篇文章对TLS1.2的理论知识和处理流程进行分析,TLS协议的实现建议直接看The Transport Layer Security (TLS) Protocol Version 1.2

为什么需要TLS协议

通常我们使用TCP协议或UDP协议进行网络通信。TCP协议提供一种面向连接的、可靠的字节流服务。但是TCP并不提供数据的加密,也不提供数据的合法性校验。

我们通常可以对数据进行加密、签名、摘要等操作来保证数据的安全。目前常见的加密方式有对称加密和非对称加密。使用对称加密,双方使用共享密钥。


但是对于部署在互联网上的服务,如果我们为每个客户端都使用相同的对称加密密钥,那么任何人都可以将数据解密,那么数据的隐私性将得不到保障。

如果我们使用非对称密钥加密,客户端使用服务端的公钥进行公钥加密,服务端在私钥不泄露的情况下,只有服务端可以使用私钥可以对数据进行解密,从而保障数据的隐私性,但是非对称加密比对称加密的成本高得多。

20200620164047.png

我们可以采用对称加密和非对称加密相结合的方式实现数据的隐私性的同时性能又不至于太差。

  1. 首先客户端和服务端通过一个称为密钥交换的流程进行密钥协商及交换密钥所系的信息。
  2. 通过公钥加密对称密钥保证对称密钥的安全传输。
  3. 服务端使用私钥解密出对称密钥。
  4. 最后双方使用协商好的对称密钥对数据进行加解密。

TLS协议就是实现了这一过程安全协议。TLS是在TCP之上,应用层之下实现的网络安全方案。在TCP/IP四层网络模型中属于应用层协议。TLS协议在两个通信应用程序之间提供数据保密性和数据完整性,另外还提供了连接身份可靠性方案。

UDP则使用DTLS协议实现安全传输,和TLS协议类似。

发展历史

TLS协议的前身SSL协议是网景公司设计的主要用于Web的安全传输协议,这种协议在Web上获得了广泛的应用。

协议设计目标

  1. 加密安全:TLS应用于双方之间建立安全连接,通过加密,签名,数据摘要保障信息安全。
  2. 互操作性:程序员在不清楚TLS协议的情况下,只要对端代码符合RFC标准的情况下都可以实现互操作。
  3. 可扩展性:在必要时可以通过扩展机制添加新的公钥和机密方法,避免创建新协议。
  4. 相对效率:加密需要占用大量CPU,尤其是公钥操作。TLS协议握手完成后,通过对称密钥加密数据。TLS还集成了会话缓存方案,减少需要从头建立连接的情况。

记录协议

TLS协议是一个分层协议,第一层为TLS记录层协议(Record Layer Protocol),该协议用于封装各种高级协议。目前封装了4种协议:握手协议(Handshake Protocol)、改变密码标准协议(Change Cipher Spec Protocol)、应用程序数据协议(Application Data Protocol)和警报协议(Alert Protocol)。

Change Cipher Spec Protocol在TLS1.3被去除。

20200522114622.png

记录层包含协议类型、版本号、长度、以及封装的高层协议内容。记录层头部为固定5字节大小。

20200522091116.png

在TLS协议规定了,如接收到了未定义的协议协议类型,需要发送一个unexpected_message警报。

握手步骤

握手协议

TLS 握手协议允许服务端和客户端相互进行身份验证,并在应用程序协议传输或接收其第一个字节数据之前协商协议版本、会话ID、压缩方法、密钥套件、以及加密密钥。

完整的TLS握手流程,流程如下

  Client                                                       Server

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

  • 表示可选步骤或与实际握手情况相关。比如重建已有连接,服务端无需执行Certificate,再比如使用RSA公钥加密时,无需ServerKeyExchange。
    握手协议消息必须按上面流程的发送数据进行发送,否则需要以致命错误告知对方并关闭连接。

完整的握手流程有时候也被称为2-RTT流程,即完整的握手流程需要客户端和服务端交互2次才能完成握手。

交互应用请求到响应的交互时间被称为往返时间(Round-trip Time)

握手协议的结构如下,其中协议头的ContentType固定为22,接下来是TLS版本号,TLS1.2为0303,最后是用2字节表示长度。

20200525143145.png

握手协议类型包含以下:

Hello Message是具体的握手协议类型内容,不同协议内容有所不同。

Hello Request

Hello Request消息用于客户端与服务端重新协商握手,该消息可能由服务端在任何时刻发送。Hello Request消息非常简单,没有其他冗余信息。

20200525102316.png

当客户端收到了服务端的Hello Request时可以有以下4种行为:

服务端发送完HelloRequest消息,可以有以下几种行为:

Finished和Certificate的握手消息验证不包括该消息的hash。

Client Hello

当客户端首次与服务端建立连接或需要重新协商加密握手会话时,需要将Client Hello作为第一条消息发送给服务端。

Client Hello消息包含了许多重要信息,包括客户端版本号、客户端随机数、会话ID、密钥套件、压缩方式、扩展字段等。

20200619180114.png

客户端发送完 ClientHello 消息后,将等待 ServerHello 消息。 服务端返回的任何握手消息(HelloRequest 除外)将被视为致命错误。

Server Hello

当服务端接收到ClientHello,则开始TLS握手流程, 服务端需要根据客户端提供的加密套件,协商一个合适的算法簇,其中包括对称加密算法、身份验证算法、非对称加密算法以及消息摘要算法。若服务端不能找到一个合适的算法簇匹配项,则会响应握手失败的预警消息。

20200619180812.png

在Finished消息中和完整握手一样都需要校验VerifyData。

标签:TLS,协议,加密,TLS1.2,握手,密钥,原理,服务端,客户端
来源: https://blog.csdn.net/lida776537387/article/details/114325412