TLS 握手过程介绍

已于 2024-03-20 15:39:57 修改
阅读量172 收藏 3
点赞数 1
分类专栏： 数字证书&通讯安全 文章标签： TLS SSL 网络安全 数字证书
于 2023-03-30 10:33:57 首次发布
原文链接：https://cloud.tencent.com/developer/article/1593352
版权

文章目录

一、SSL 和 TSL 介绍

SSL（Secure Sockets Layer）和TLS（Transport Layer Security）是用于加密通信的安全协议。TLS实际上是SSL的继任者，由于SSL存在一些安全漏洞，因此TLS被设计用来取代SSL并提供更强大的安全性。

1. SSL（Secure Sockets Layer）

  • 历史：SSL最早由网景公司（Netscape）开发，用于保护Web通信的安全性。最初版本为SSL 1.0和SSL 2.0，但由于安全漏洞，SSL 2.0很快被SSL 3.0取代。SSL 3.0在1996年发布。
  • 版本：SSL 3.0是最后一个版本的SSL，目前已被广泛淘汰，不再被推荐使用。

2. TLS（Transport Layer Security）

  • 历史：TLS是在SSL 3.0的基础上发展而来的，旨在解决SSL存在的安全问题。TLS 1.0在2006年成为RFC标准，它基本上与SSL 3.0兼容，但做了一些改进以提高安全性。目前较新的版本有TLS 1.1、TLS 1.2和TLS 1.3。
  • 版本：
    • TLS 1.0（2006年）：基本与SSL 3.0兼容，但做了安全性方面的改进。
    • TLS 1.1（2006年）：进一步增强了安全性，修复了一些TLS 1.0中的缺陷。
    • TLS 1.2（2008年）：增加了更强的加密算法和协议套件，提供更安全的通信。
    • TLS 1.3（2018年）：进一步提升了安全性和性能，简化了握手过程，并移除了一些不安全的特性。

总的来说，TLS版本的更新主要是为了提高安全性、性能和协议效率，以适应不断发展的网络环境和安全需求。建议尽可能使用较新版本的TLS来确保通信的安全性。

1.2 疑问和问题

  1. 双向认证：ca.crt、client.crt、client.key
    • ca.crt：mqtt client 端用来判断 server 给的公钥证书对不对
    • client.crt：mqtt client 发送给server，server判断对不对，并且用来加密
    • client.key：用来解密
  2. 双向认证：详细过程
  3. 单向认证：ca.crt
  4. 单向认证：详细过程
  5. TLS1.2 和TLS1.3 区别

1.3 TSL 握手失败原因

在这里插入图片描述

遇到过的问题：

  • 系统时间不正确
    • 相同程序在不同设备上，一个TLS 1.2认证通过、一个认证不通过：设备时间不一致（设备时间不在证书有效期范围内）

二、TLS 握手过程和内容

2.1 图解TLS握手连接

SSL：（Secure Socket Layer，安全套接字层），位于可靠的面向连接的网络层协议和应用层协议之间的一种协议层。SSL通过互相认证、使用数字签名确保完整性、使用加密确保私密性，以实现客户端和服务器之间的安全通讯。该协议由两层组成：SSL记录协议和SSL握手协议。

TLS：(Transport Layer Security，传输层安全协议)，用于两个应用程序之间提供保密性和数据完整性。该协议由两层组成：TLS记录协议和TLS握手协议。（在TCP传输层之上、应用层之间）

TLS是在SSL的基础上标准化的产物，目前SSL3.0与TLS1.0保持一致的，二者是并列关系，只是大家习惯称呼SSL。注明的web服务nginx默认支持的就是TLS1.0、TLS1.1、TLS1.2协议。

说明了SSL和TLS的区别后，我们通过wireshark对TLS的每一个byte进行分析。先来一张握手图：
在这里插入图片描述
在这里插入图片描述

对应的wireshake中的握手记录
在这里插入图片描述

2.1.1 Client Hello

会话从client说“hello”开始, client提供以下数据：

  • 协议版本
  • 客户端随机数(之后会在握手中使用到)
  • 一个用来恢复的可选session id
  • 密码套件列表
  • 压缩方法列表
  • 扩展列表

1.1 Record Header

16 03 01 02 00

16 - 表示ContentType指示SSL通信处于握手(handshake)阶段

03 01 - 表示TLS的版本是 TLS1.0

02 00 - 表示512字节的握手消息

在这里插入图片描述
1.2 Handshake Header

每个握手消息都以类型和长度开始。

01 00 01 fc

01 - 表示握手消息的类型为 client hello

00 01 fc - 表示握手消息的长度

在这里插入图片描述

1.3 客户端TLS版本

给出了协议版本“3,3”(即TLS 1.2)。不寻常的版本号(“3,3”表示TLS 1.2)是由于TLS 1.0是SSL 3.0协议的一个小修订。因此，TLS 1.0用“3,1”表示，TLS 1.1用“3,2”表示，依此类推。

03 03

可见上图

1.4 客户端随机数

74 ac 35 84 e3 0b d2 a4 63 75 1e a9 94 d2 43 94

6b bf 67 ab f9 a6 8e c7 0b e6 cb ab f0 91 bc db

客户端提供32字节的随机数据。在本例中，我们将随机数据设置为可预测的字符串。TLS 1.2规范说，前4个字节应该是当前时间.

在握手时，客户端和服务器都会提供随机数。这种随机性对每次握手都是独一无二的，在身份验证中骑着举足轻重的作用。它可以防止重放攻击，并确认初始数据交换的完整性。

在这里插入图片描述
1.5 会话ID

在第一次连接时，会话ID（Session ID）字段是空的，这表示客户端并不希望恢复某个已存在的会话。在后续的连接中，这个字段可以保持会话的唯一标识。服务器可以借助会话ID在自己的缓存中找到对应的会话状态。典型的会话ID包含32自己随机生成的数据，这些数据本身没有什么价值。
在这里插入图片描述
1.6 加密套件

客户端提供一个有序的列表，其中列出了它将支持的密钥交换、密钥加密和消息身份验证的加密方法。该列表是按优先级顺序排列的。

在这里插入图片描述

1.7 压缩方法

客户端可以提交一个或多个支持压缩的方法。默认的压缩是null，代表没有压缩。这种压缩将在加密之前应用(因为加密的数据通常是不可压缩的)。压缩具有削弱加密数据安全性的特征(参见CRIME)。因此，这个特性已经从未来的TLS协议中删除。

  • 01 - 压缩方法的长度
  • 00 - 使用的哪种压缩方法, 00代表未使用任何压缩方式

在这里插入图片描述
1.8 Extensions长度

Extensions是由任意数量的扩展组成。这些扩展会携带额外数据。

  • 00 58 - the extensions will take 0x58 (88) bytes of data

每个扩展都以两个字节开始，表示它是哪个扩展，然后是一个双字节内容长度字段，然后是扩展的内容。

1.9 Extension - Server Name

客户端提供了它所联系的服务器的名称，也称为SNI(服务器名称指示)。

如果没有这个扩展，HTTPS服务器将无法为单个IP地址(虚拟主机)上的多个主机名提供服务，因为它无法知道要发送哪个主机名的证书，直到经过TLS会话协商并发出HTTP请求之后才知道.

  • 00 00 - 这个值表示扩展名为‘Server Name’

  • 00 13 - Extension Length

  • 00 11 - Server Name list length

  • 00 - list entry is type 0x00 “DNS hostname”

  • 00 0e - Server Name Length

  • 65 78 61 … 6e 65 74 - 表示服务器名

在这里插入图片描述
1.10 Extension - Status Request

客户端为服务器提供在其响应中提供OCSP信息的权限。OCSP可用于检查证书是否已被撤销。客户端发送空扩展的这种形式是必要的，因为服务器使用客户端首先没有提供的扩展进行应答是一个致命错误。因此，客户端发送一个空形式的扩展，而服务器用填充了数据的扩展进行应答。
在这里插入图片描述
00 05 00 05 01 00 00 00 00

  • 00 05 - 表示该extension为 “status request”
  • 00 05 - 表示该扩展的长度
  • 01 - 表示certificate status type: OCSP
  • 00 00 - 表示Responder ID list length
  • 00 00 - 表示Request Extensions Length

1.11 Extension - Supported Groups

客户端表示支持4条曲线的椭圆曲线加密。这个扩展最初被命名为“椭圆曲线”，但现在被重命名为“受支持的组”，以便与其他加密类型通用。

00 0a - assigned value for extension “supported groups”
00 0a - 0xA (10) bytes of “supported groups” extension data follows
00 08 - 0x8 (8) bytes of data are in the curves list
00 1d - assigned value for the curve “x25519”
00 17 - assigned value for the curve “secp256r1”
00 18 - assigned value for the curve “secp384r1”
00 19 - assigned value for the curve “secp521r1”
在这里插入图片描述
1.12 Extension - EC Point Formats

在椭圆曲线(EC)加密期间，客户机和服务器将以压缩或未压缩的形式交换所选点上的信息。这个扩展表明客户机只能解析来自服务器的未压缩信息。在下一版本的TLS中，不存在协商点的能力(而是为每个曲线预先选择了一个点)，因此不会发送此扩展。

00 0b - assigned value for extension “EC points format”
00 02 - 0x2 (2) bytes of “EC points format” extension data follows
01 - 0x1 (1) bytes of data are in the supported formats list
00 - assigned value for uncompressed form

在这里插入图片描述

1.13 Extension - Signature Algorithms
随着TLS的发展，有必要支持更强大的签名算法，如SHA-256，同时仍然支持使用MD5和SHA1的早期实现。此扩展指示客户机能够理解哪些签名算法，并可能影响服务器发送给客户机的证书的选择。

00 0d - assigned value for extension “Signature Algorithms”
00 12 - 0x12 (18) bytes of “Signature Algorithms” extension data follows
00 10 - 0x10 (16) bytes of data are in the following list of algorithms
04 01 - assigned value for RSA/PKCS1/SHA256
04 03 - assigned value for ECDSA/SECP256r1/SHA256
05 01 - assigned value for RSA/PKCS1/SHA386
05 03 - assigned value for ECDSA/SECP384r1/SHA384
06 01 - assigned value for RSA/PKCS1/SHA512
06 03 - assigned value for ECDSA/SECP521r1/SHA512
02 01 - assigned value for RSA/PKCS1/SHA1
02 03 - assigned value for ECDSA/SHA1
在这里插入图片描述
1.14 Extension - Renegotiation Info
该扩展的存在防止了使用TLS重新协商执行的攻击类型。重新协商连接的能力已经从该协议的下一个版本(TLS 1.3)中移除，因此将来不再需要这个扩展。

ff 01 - assigned value for extension “Renegotiation Info”
00 01 - 0x1 (1) bytes of “Renegotiation Info” extension data follows
00 - 重新协商数据的长度为零，因为这是一个新连接
在这里插入图片描述
1.15 Extension - SCT

客户端为服务器提供返回签名证书时间戳的权限。客户端发送空扩展的这种形式是必要的，因为服务器使用客户端首先没有提供的扩展进行应答是一个致命错误。因此，客户端发送一个空形式的扩展，服务器使用填充了数据的扩展进行响应，或者根据发送扩展的客户端更改行为。

00 12 - assigned value for extension “signed certificate timestamp”
00 00 - 0x0 (0) bytes of “signed certificate timestamp” extension data follows

2.1.2 Server Hello

服务器回以“你好”。服务器提供以下信息:

选择的协议版本
服务器随机数据(稍后在握手中使用)
会话id
选定的密码套件
选择的压缩方法
扩展列表

2.1 Record Header

TLS会话被分解为“记录”的发送和接收，“记录”是具有类型、协议版本和长度的数据块。

16 -类型是0x16(握手记录)
03 03 -协议版本是“3,3”(TLS 1.2)
00 31 - 0x31(49)字节的握手消息

2.2 Handshake Header

每个握手消息都以类型和长度开始。

02 -握手消息类型0x02(服务器你好)
00 00 2d - 接下来是服务器hello数据的0x2D(45)字节

2.3 服务器TLS版本

给出了协议版本“3,3”(TLS 1.2)。不寻常的版本号(“3,3”表示TLS 1.2)是由于TLS 1.0是SSL 3.0协议的一个小修订。

03 03 - TLS Version = 1.2

2.4 服务器随机数

服务器提供32字节的随机数据。在本例中，我们将随机数据设置为可预测的字符串。

在这里插入图片描述
2.5 会话ID

服务器可以为这个会话提供一个ID，客户机可以在以后的会话协商中提供这个ID，以便重用关键数据并跳过大多数TLS协商过程。为了使其工作，服务器和客户端都将来自前一个连接的密钥信息存储在内存中。恢复连接可以节省大量的计算和网络往返时间，因此只要有可能就会执行连接。

00 - length of zero (没有选择任何会话ID)

2.6 服务器选择的加密方式

服务器从客户机提供的选项列表中选择了密码套件0xC02F (TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256)。

其中SHA256就是客户端和服务端使用的HMAC算法

在这里插入图片描述

2.7 服务器选择的压缩方式

服务器从客户机提供的选项列表中选择了压缩方法0x00(“Null”，它不执行压缩)。

在这里插入图片描述
2.8 Extension长度

服务器向客户端返回了一个扩展列表。由于禁止服务器使用客户机没有发送其hello消息的扩展进行应答，所以服务器知道客户机将支持列出的所有扩展。

00 05 -扩展将占用0x5(5)字节的数据

在这里插入图片描述
2.9 Extension - Renegotiation Info

该扩展的存在防止了使用TLS重新协商执行的攻击类型。重新协商连接的能力已经从该协议的下一个版本(TLS 1.3)中移除，因此将来不再需要这个扩展。

ff 01 -为扩展分配值“重新协商信息”
00 01 - 0x1(1)字节的“重协商信息”
00 00 - 扩展数据如下重新协商数据的长度为零，因为这是一个新的连接

在这里插入图片描述

2.10 Extended Master Secret

无“Extended Master Secret”

master_secret = PRF(pre_master_secret, “主秘钥”, ClientHello.random + ServerHello.random)[0…47]

具有“Extended Master Secret”

master_secret = PRF(pre_master_secret，“扩展的主密钥”，session_hash)[0…47];

session_hash = hash(handshake_message)

2.1.3 Server Certificate

服务器提供一个包含以下内容的证书:

  • 服务器的主机名
  • 此服务器使用的公钥
  • 来自可信第三方的证据，证明此主机名的所有者持有此公钥的私钥

这里先介绍下证书认证的过程：

1). 服务器发送给浏览器端的证书只有public key, 服务器端保存着private key。
2). client随机生成一串数，用server这里的public key加密，发给server
3). server用private key解密后返回给client
4). client与原文比较，如果一致，则说明server拥有private key，也就说明与client通信的正是证书的拥有者，因为public key加密的数据，只有private key才能解密

3.1 Record Heade

TLS会话被分解为“记录”的发送和接收，“记录”是具有类型、协议版本和长度的数据块。

16 -类型是0x16(握手记录)
03 03 -协议版本是“3,3”(TLS 1.2)
03 2f - 0x31(49)字节的握手消息

3.2 Handshaker Heade
每个握手消息都以类型和长度开始。

02 -握手消息类型0x02(服务器你好)
00 00 2d - 接下来是服务器hello数据的0x2D(45)字节

3.3 Certificate Length
证书消息以随后的所有证书数据的长度开始。

  • 00 03 28 - 0x328 (808) bytes of certificate list follows

3.4 Certificate
证书采用ASN.1 DER二进制编码。这种编码由以下序列中的记录组成:类型标记、长度、数据。

type标签包含以下信息:

type class (2 bits):通用的、应用程序的、特定于上下文的或私有的

constructed (1 bit):如果记录由更小的记录组成，则设置

type (5 bits):如果类型类是通用类型，那么类型表示整数、ASCII字符串、对象ID等。

在这里插入图片描述
https://tls.ulfheim.net/certificate.html

4. Server Key Exchange

服务器提供了密钥交换信息。作为密钥交换过程的一部分，客户端需要拥有一组公钥+私钥，公钥用于加密发送的数据, 私钥用于解密服务器发送过来的数据。并且将互相发送对方的公钥。然后，将使用各方的私钥和另一方的公钥的组合生成共享加密密钥。

双方同意使用ECDHE密码套件,这意味着密钥对将基于选择的椭圆曲线,diffie - hellman,密钥对都是暂时的(为每个连接生成),而不是使用的公钥/私钥证书。

4.1 Record Header && HandShaker Header
略

4.2 Curve info
服务器选择椭圆曲线, 椭圆曲线上的所有点。

03 - assigned value for “named_curve”: 曲线类型
00 1d - curve 0x001d (“curve x25519”)

在这里插入图片描述
4.3 Public Key

服务器端提供的公钥来自于之前的步骤 “Server Key Exchange Generation”.

20 - length of 0x20 (32) bytes
9f d7 … b6 15 - public key

在这里插入图片描述
4.4 Signature

因为服务器正在生成临时密钥，所以它没有使用服务器证书中提供的公钥。为了证明服务器拥有服务器证书(在TLS会话中提供证书有效性)，它使用证书的私钥签署临时公钥。可以使用证书的公钥验证此签名。

  • 04 01 - reserved value for RSA signature with SHA256 hash
  • 01 00 - length of signature (0x100 or 256 bytes)
  • 04 02 b6 … ac 41 fb - the computed signature for SHA256(client_hello_random + server_hello_random + curve_info + public_key)
    我们可以自己计算签名使用服务器的私钥.

2.2 SSL 和 TLS 历史和详细区别

SSL（Secure Sockets Layer）和TLS（Transport Layer Security）都是用于加密通信的协议，主要目的是保护数据在网络上传输时的安全性和隐私性。它们之间的关系可以简单理解为TLS是SSL的继任者，TLS 1.0实际上是基于SSL 3.0进行发展和完善的。

下面是SSL和TLS之间的一些历史和详细区别：

  1. 发展历程：

    • SSL：SSL最早由网景公司开发，推出了SSL 1.0、SSL 2.0、SSL 3.0等版本。SSL 3.0发布后，由于存在一些安全性漏洞（什么漏洞？），后来被TLS取代。
    • TLS：TLS最早由互联网工程任务组（IETF）开发，旨在修复SSL 3.0中的安全漏洞。TLS 1.0被设计为与SSL 3.0兼容，且具有更强的安全性。

  2. 版本：

    • SSL：主要版本包括SSL 2.0和SSL 3.0。SSL 3.0存在一些安全漏洞，因此不再被广泛使用。
    • TLS：主要版本包括TLS 1.0、TLS 1.1、TLS 1.2和TLS 1.3等。TLS 1.2和TLS 1.3是目前广泛使用的版本，具有更强的安全性和性能优化。

  3. 加密算法：

    • SSL：SSL主要使用的是对称加密算法和非对称加密算法。
    • TLS：TLS也支持对称加密和非对称加密，同时引入了更多的加密算法和安全性机制，如更安全的密钥交换算法、强大的身份验证机制等。

  4. 安全性：

    • TLS比SSL更加安全，因为TLS在设计上修复了SSL中存在的一些漏洞和弱点，提供了更强的安全性保障。

总的来说，TLS是SSL的升级版本，更安全、更稳定，因此在实际应用中，一般建议使用TLS而不是SSL来保障网络通信的安全。

三、TLS Record Layer 类型 和 Alert 协议

3.1 TLS Record Layer 取值类型

TLS Record Layer 中常见的记录类型有四种：

  1. ChangeCipherSpec(20)：用于通知对方当前会话密钥协商已经完成，可以开始使用新密钥进行加密通信。

  2. Alert(21)：用于传递警报消息，可以分为严重级别和警告级别。常见的警报类型有致命警报和警告警报，用于指示协议错误或警告。

  3. Handshake(22)：用于建立连接时进行协商的消息类型，包括客户端和服务器之间的协商参数、密钥协商、身份验证等。

  4. Application Data(23)：用于承载应用层数据的类型，包括实际传输的应用数据，如网页内容、文件传输等。

这些记录类型在 TLS Record Layer 中起到不同的作用，通过这些类型的交互，TLS 协议可以确保通信的安全性和完整性。

3.2 TLS Alert 协议

本章重点介绍SSL/TLS Record Layer类型：Alert (21)

在这里插入图片描述

协议说明

作用：SSL/TLS协议在握手协商过程，出现任何问题诸如：客户端收到服务端证书为不信任证书时，SSL/TLS会直接中断连接。由客户端发出Alert信息通知服务端。

协议字段

Alert Message字段及说明：

  1. Alert Level： warning(1); Fatal(2); (255)

  2. Description: 如下表（标红字段为TLS 1.3 新增）

在这里插入图片描述
参考：RFC5246，RFC8446

五、参考资料

mayue_csdn
关注
  • 1
    点赞
  • 踩
  • 3
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
【计算机网络】TLS四次握手过程
qq_53715003的博客
01-03 5683
我们都知道HTTP是明文传输，所以存在窃听、篡改和伪装等风险。为了解决这些问题，https出现了，https在http的应用层和传输层之间增加了一个SSL/TLS层，建立连接时增加了TLS层的四次握手，实现了信息加密、报文校验和身份证书等功能。 今天，我们就来探讨一下，TLS层的信息加密是如何实现的。 https的信息加密是混合加密，也就是对称加密与非对称加密。双方通通信开始前要协商密钥，密钥协商时采用的是非对称加密，进行通信时使用的对称加密。 在密钥协商阶段主要用到以下几种算法： RSA算法 D
TLS握手过程
沙沙罗曼的专栏
03-16 2951
TLS握手过程 客户端与服务器商议通信密钥的过程称为TLS握手，在握手阶段，通信内容虽然都是明文，但要保证最终商量的密钥只有客户端和服务器知道，其他中间节点无从得知。 RSA握手过程 RSA握手过程说明： “Client Hello”，客户端向服务器发送一个随机数R1 “Server Hello”，服务器给客户端回复一个随机数R2与包含公钥的证书 “Client Key Exch...
网络|使用 Wireshark 分析 TLS/SSL 协议
thlzjfefe的博客
09-19 4721
第一个阶段是客户端发给服务端请求连接 Client Hello第二个阶段就是服务端回复客户端对应的证书、公钥信息、加密压缩算法第三个阶段是客户端告诉服务端自己的证书和公钥信息第四个阶段确认好对应的对称密钥后，让其生效测试下好不好使。握手的目的是协商对称加密密钥，由于加密前数据包都是明文，所以如果一开始就亮出密钥就不安全，所以握手期间是通过非对称加密的方式进行协商密钥。单向认证握手流程双向认证握手流程如下图所示：单向认证比双向认证少了 服务端对客户端进行认证的阶段。作者：高冷的白帽子。
「TLS/SSL」- 握手过程简述 @20210220
k4nz
02-20 409
该笔记将记录：简述 TLS handshake 过程，以及熟悉调试处理 TLS 问题的方法。 握手流程概述 握手过程可以分为以下步骤： 第一步、协议协商 Client 与 Server 将协商要使用的协议版本。例如：决定使用 TLSv1.1 协议，还是 TLSv1.3 协议 第二步、选择算法 选择加密算法。 第三步、证书验证 通过 Server 的公钥 和 SSL 证书的 CA 的数字签名 来验证 Server 的身份。 第四步、数据传输 使用「非对称加密」技术生成「共享密钥」，避免密.
SSL/TLS协议详解(下)——TLS握手协议
m0_45079966的博客
09-19 2092
SSL/TLS协议详解(下)——TLS握手协议 本文翻译自：https://www.wst.space/ssl-part-4-tls-handshake-protocol/ 在博客系列的第2部分中,对证书颁发机构进行了深入的讨论.在这篇文章中，将会探索整个SSL/TLS握手过程，在此之前，先简述下最后这块内容的关键要点： TLS适用于对称密钥 对称密钥可以通过安全密钥交换算法共享 如果请求被截获，...
TLS 1.0 至 1.3 握手流程详解【转】
llzhang_fly的博客
08-29 4650
TLS 全称为 Transport Layer Security（传输层安全），其前身是 SSL，全称为 Secure Sockets Layer（安全套接字层），它的作用是为上层的应用协议提供安全的通信，比如众所周知的 HTTP + TLS = HTTPS。SSL 2.0 是该协议的第一个公开发布的版本，由于其存在的安全问题很快被升级到了 SSL 3.0，并且在 1999 年，IETF 小组将该协议标准化，因此 TLS 1.0 诞生了。...
SSL/TSL握手解析
十三阿哥的博客
12-12 605
SSL/TLS握手过程
SSL/TLS 握手过程详解
OceanWaves1993的博客
01-04 2735
SSL 和 TLS 这两个术语可以互换使用，因为这些协议以相同的方式加密信息，并且在最基本的层面上执行相同的操作。并且，如果客户端猜对了并且两者已就相同的 AEAD 协议达成一致，则服务器会发送自己的密钥共享部分，计算会话密钥并以服务器完成消息结束。4、为了提供身份验证，服务器获取客户端和服务器的随机数以及将用于计算会话密钥的 DH 参数，并使用其私钥对其进行加密。这是极其重要的一步。在此示例中，我们将研究 RSA，因此客户端将生成称为预主密钥的随机字节字符串，然后使用服务器的公钥对其进行加密并传输。
TSL握手过程
庸才
10-09 428
     Client Hello 由客户端发起，主要包含SSL version、Random1、Support Suites以及Session ID    Server Hello 服务器返回，主要包含Random2、Cipher Suite              Certificate 服务器下放给客户端的证书   Server Key Exch...
以太网TLS原理ppt介绍
06-26
1. **保密性(message privacy)**：TLS通过使用加密技术，确保数据在传输过程中不被未经授权的第三方窃取或解读。所有信息都会经过加密处理，只有拥有正确密钥的发送方和接收方才能解密。 2. **完整性(message ...
HTTPS协议详解(四)：TLS:SSL握手过程1
08-03
本文将详细讲解TLS/SSL握手过程，主要包括握手与密钥协商过程、会话缓存握手过程以及重建连接。 1. 握手与密钥协商过程 TLS/SSL握手过程是建立安全连接的关键步骤，它涉及到双方身份验证、协议版本选择、加密套件...
HTTPS中TLS和TCP可以同时握手吗 607 - 616
05-15
一般情况下，TLS握手过程需要四次，也就是需要经过2-RTT才能完成握手，然后才能发送请求。 但是，TLSv1.3版本只需要1-RTT就能完成TLS握手，如下图所示。那么，面试官说的"HTTPS中的TLS握手过程可以同时进行三次握手...
tls.rar_TLS
09-23
这通常涉及到客户端（如浏览器）与服务器之间的握手过程，其中客户端会询问服务器支持的最高TLS版本，然后选择两者都支持的最低版本进行通信。 在实际应用中，TLS版本的检查和设置是非常关键的，因为它有助于防止与...
openssl握手过程
02-25
### 二、SSL/TLS握手过程的重要性 握手协议是SSL/TLS协议的核心组成部分，其主要功能是在客户端与服务器之间建立安全连接。这一过程涉及多个步骤，包括密钥交换、身份验证以及加密算法的协商等。握手协议的成功完成...
TLS握手流程分析
最新发布
weixin_43894455的博客
01-15 1891
客户端发送：用于初始化会话消息，该消息主要包含如下信息：: 客户端发送它所支持的最高 SSL/TLS 版本；：一个 32 字节的客户端随机数，该随机数被服务端生成通信用的对称密钥（master secret）；：session ID 被客户端用于恢复之前的会话: 客户端发送它所支持的加密套件列表服务端发送：服务端发送双方所支持的最高的 SSL/TLS 版本；：一个 32 字节的服务端随机数，被客户端用于生成通信用的对称密钥（master secret）；：用于会话恢复；
Https工作原理＆TLS握手机制
lzf的博客
04-07 1099
HTTPS 概念 HTTPS 就是一个有安全保障的 HTTP 通信，我们都知道，http 是明文传输的，http 报文是人肉眼就可识别的 ASCII 码，在通信过程中，http 报文很容易被黑客窃听、篡改、伪造，而在互联网交易中，我们必须保证通信安全，所以就需要像 https 这样有安全层的协议。 那么，https是怎么保障通信安全的呢？什么样的通信可以被称为是安全的，安全的定义是什么？ 通常，如果通信过程具备了四个特性，就可以认为是“安全”的，这四个特性是：机密性、完整性，身份认证和不可否认。而HT
学习笔记|一篇文章带你全面了解TLS 协议的全流程
Jum的博客
06-29 3718
TLS（英语：Transport Layer Security，缩写作TLS）传输层安全性协议，及其前身安全套接层（Secure Sockets Layer，缩写作SSL）是一种安全协议，目的是为互联网通信提供安全及数据完整性保障。网景公司（Netscape）在1994年推出首版网页浏览器，网景导航者时，推出HTTPS协议，以SSL进行加密，这是SSL的起源。IETF将SSL进行标准化，1999年公布第一版TLS标准文件。随后又公布RFC 5246 （2008年8月）与RFC 6176（2011年3月）
这么理解TLS协议，以及TLS协议的握手过程
吴就业
05-29 4325
如今HTTPS已被广泛使用，但作为程序员的我们，真的理解这个'S'了吗？如果还没有，这篇入门级介绍或许能帮到你。在TLS（更早期的版本是SSL）出现之前，很多公司为了保证自家产品客户端与服务端信令交互数据安全，或通过基于TCP协议，自定义支持加解密的二进制应用协议（用于APP），或通过加密HTTP协议请求&响应的Body以确保数据安全。无论哪种，通常都是采用对称加...
SSL/TLS认证握手过程
团长的专栏
05-23 2699
client读取证书中的相关的明文信息，采用相同的散列函数计算得到信息摘要，然后，利用对应 CA的公钥解密签名数据，对比证书的信息摘要，如果一致，则可以确认证书的合法性，即公钥合法。客户端会内置信任CA的证书信息(包含公钥)，如果CA不被信任，则找不到对应 CA的证书，证书也会被判定非法。哈，有人的地方就有江湖，有江湖的地方就没有绝对的安全。但SSL/TLS确实可以极大程度保证信息安全。签名的产生算法：首先，使用散列函数计算公开的明文信息的信息摘要，然后，采用 CA的私钥对信息摘要进行加密，密文即签名。
tls 握手 签名和验签
08-31
在TLS握手过程中，签名和验签是非常重要的步骤。在引用中提到的TLS握手过程中，服务器和客户端会向CA机构发送申请证书文件，并分别得到各自的证书。这些证书包含了公钥和其他相关信息。在握手过程中，服务器和客户端会互相验证对方的身份并交换公钥。 在握手过程的某个阶段，引用中提到的certificate_verify步骤会发送使用客户端证书的签名结果。这个签名结果是对之前在握手过程中收到和发送的所有握手消息进行签名得到的。这样，服务器可以通过验证签名来确认客户端的身份和完整性。 数字签名是一种通过使用私钥对数据进行加密得到的签名，而验签则是通过使用公钥对签名进行解密和验证的过程。在TLS握手中，签名会被用来保证消息的完整性和身份的真实性。通过验证签名，服务器和客户端可以确保握手消息没有被篡改，并且可以信任对方的身份。 总结来说，TLS握手过程中的签名和验签是为了确保消息的完整性和身份的真实性。通过使用数字证书和数字签名，服务器和客户端可以相互验证对方的身份，并确保握手消息没有被篡改。<span class="em">1</span><span class="em">2</span><span class="em">3</span> #### 引用[.reference_title] - *1* *3* [数字签名、服务器和客户端认证过程、TLS握手](https://blog.csdn.net/qq_43598865/article/details/120127173)[target="_blank" data-report-click={"spm":"1018.2226.3001.9630","extra":{"utm_source":"vip_chatgpt_common_search_pc_result","utm_medium":"distribute.pc_search_result.none-task-cask-2~all~insert_cask~default-1-null.142^v93^chatsearchT3_2"}}] [.reference_item style="max-width: 50%"] - *2* [使用wireshark观察SSL/TLS握手过程--双向认证/单向认证](https://blog.csdn.net/weixin_29187895/article/details/117219168)[target="_blank" data-report-click={"spm":"1018.2226.3001.9630","extra":{"utm_source":"vip_chatgpt_common_search_pc_result","utm_medium":"distribute.pc_search_result.none-task-cask-2~all~insert_cask~default-1-null.142^v93^chatsearchT3_2"}}] [.reference_item style="max-width: 50%"] [ .reference_list ]
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值