ssl握手数据结构

ssl握手

SSL记录头(5字节)

  • 字节0:记录内容的类型
Content Type Hex Code Description
Change_Cipher_Spec 0x14 指示加密方式的更改
Alert 0x15 发出各种类型的错误信号
Handshake 0x16 携带握手消息的记录
Application_Data 0x17 加密的应用数据
  • 字节1和2:SSL版本(TLSv1是0x0301,SSLv3是0x0300)
  • 字节3和4:记录长度(不包括前面5字节)

握手消息头(3字节)

  • 字节0:握手类型
Handshake Type Hex Code
hello_request 0x00
client_hello 0x01
server_hello 0x02
certificate 0x0b
server_key_exchange 0x0c
certificate_request 0x0d
server_hello_done 0x0e
certificate_verify 0x0f
client_key_exchange 0x10
finished 0x14
  • 字节1-3:握手消息长度(不包括前面3字节)

Client_Hello

告诉服务端客户端期望的协议版本,算法套件和压缩方法。还包括一个32字节的随机数(client_random),由4字节的GMT Unix时间(从1970年开始的秒数)和28字节的随机数组成

TLS1.2中增加了可选的Hello扩展,格式如下

struct {
ExtensionType extension_type;
opaque extension_data<0..2^16-1>;
} Extension;

扩展的类型以及对应的规范可以在此链接查看

Hello扩展类型

字节 长度 描述
00 1 16 记录内容类型 -- 握手消息
01-02 2 03 01 SSL版本 -- TLSv1
03-04 2 00 61 记录长度
05 1 01 握手类型 -- Client_Hello
06-08 3 00 00 5d 消息长度(0x61-4 = 0x5d)
09-0A 2 03 01 客户端偏向的版本 -- TLSv1
0B-0E 4 40 44 35 27 GMT Unix时间
0C-2A 28 5c ... 72 28字节随机数,和4字节的时间组成client_random
2B 1 00 Session ID长度 (恢复会话时使用)
2C-2D 2 00 36 加密套件长度 -- 27个 (每个2字节)
2E-63 54 .... 27个算法套件(TLS1.2 0xFF结尾?)
64 1 01 压缩算法长度
65 1 00 压缩算法: NULL

算法套件对应的编号可以在此链接查看

算法套件

也可以使用openssl ciphers -V ‘ECDSA+AES+SM3‘

Server_Hello

告诉客户端服务器的选择,协议版本,算法套件,压缩方法。也包括一个32字节的随机数。

字节 长度 描述
00 1 16 记录内容类型 -- 握手消息
01-02 2 03 01 SSL版本 -- TLSv1
03-04 2 00 2a 记录长度
05 1 02 握手类型 -- Server_Hello
06-08 3 00 00 26 消息长度
09-0A 2 03 01 SSL版本 -- TLSv1
0B-0E 4 40 44 35 27 GMT Unix时间
0C-2A 28 cc ... b9 28字节随机数,和4字节的时间组成server_random
2B 1 00 Session ID长度 (恢复会话时使用)
2C-2D 2 00 16 选择的加密套件
2E 1 00 选择的压缩算法NULL

扩展server hello不能出现扩展client hello中没有出现的扩展类型。

Certificate

由正确顺序的X509证书链组成,第一个是服务端证书,后续是签发服务端证书的证书。客户端使用服务端证书的公钥来加密pre_master_secret或者验证server_key_exchange。

字节 长度 描述
00 1 16 记录内容类型 -- 握手消息
01-02 2 03 01 SSL版本 -- TLSv1
03-04 2 02 05 记录长度
05 1 0b 握手类型 -- Certificate
06-08 3 00 02 01 消息长度
09-0B 3 00 01 fe 证书长度
证书

Server_Key_Exchange

Server_Hello_Done

空消息指示所有握手消息发送完毕,因为服务端可以在发送证书消息后发送一些可选的消息,所有需要。

字节 长度 描述
00 1 16 记录内容类型 -- 握手消息
01-02 2 03 01 SSL版本 -- TLSv1
03-04 2 00 04 记录长度
05 1 0e 握手类型 -- Server_Hello_Done
检查最后3字节

Client_Key_Exchange

当使用RSA密钥交换时包含pre_master_secret,包含2字节的版本和46字节的随机数

字节 长度 描述
00 1 16 记录内容类型 -- 握手消息
01-02 2 03 01 SSL版本 -- TLSv1
03-04 2 00 86 记录长度
05 1 10 握手类型 -- Client_Key_Exchange
06-08 3 00 00 82 消息长度
pre_master_secret(130字节,用服务端证书中的公钥加密)

Change_Cipher_Spec

Certificate_Verify

客户端证书地显式验证,只有当证书有签名能力时发送(除了那些包含固定DH参数的证书)

签名的数据是从Client_Hello开始所有发送和接收的握手消息(包括消息的类型和长度),但不包括本条消息

Change_Cipher_Spec

Unknown_Handshaking_Message

Finish

此消息是第一个受保护的消息,接收方必须验证内容正确。摘要计算包括所有握手消息但不包括本消息。 只是握手层可见的数据,不包括记录层头。(注意:change cipher spec, alerts和其他记录类型都不是握手消息)

    verify_data
    PRF(master_secret, finished_label, MD5(handshake_messages) +
    SHA-1(handshake_messages)) [0..11];

16 03 03 00 50 14 00 00 0c 09 ef c6 0d 6b 32 27 86 e4 73 0c b1

Application_Data

HTTP请求消息:Get /test.html HTTP/1.0

HTTP响应消息

Alert

原文地址:https://www.cnblogs.com/logchen/p/10403061.html

时间: 2024-10-06 17:46:37

ssl握手数据结构的相关文章

OkHttp还处理了代理服务器问题和SSL握手失败问题

Android系统提供了两种HTTP通信类,HttpURLConnection和HttpClient,HttpURLConnection相对来说比HttpClient难用,google自从2.3版本之后一直推荐使用HttpURLConnection,并且在6.0版本的sdk中直接删掉了HttpClient类. 但是, 上面两个类库和OkHttp比起来就弱爆了, 因为OkHttp不仅具有高效的请求效率,并且节省宽带, 还提供了很多开箱即用的网络疑难杂症解决方案.(据说Android4.4的源码中可

SSL握手过程

一.SSL握手有三个目的:1. 客户端与服务器需要就一组用于保护数据的算法达成一致:2. 它们需要确立一组由那些算法所使用的加密密钥:3. 握手还可以选择对客户端进行认证. 二.SSL握手过程:1. 客户端将它所支持的算法列表和一个用作产生密钥的随机数发送给服务器:2. 服务器从算法列表中选择一种加密算法,并将它和一份包含服务器公用密钥的证书发送给客户端:该证书还包含了用于认证目的的服务器标识,服务器同时还提供了一个用作产生密钥的随机数:3. 客户端对服务器的证书进行验证(有关验证证书,可以参考

无效session ticket导致的SSL握手协商失败

SSL session ticket记录了加密参数,用于后续请求,减少握手次数,降低反复握手请求导致的高延迟. 如上截图,在SSL 握手完成之后,服务器生成session ticket.请求关闭后,如果客户端发起后续连接(超时时间内),可以随client hello复用这个session ticket,可以加快协商速度,如下截图:

CentOS6.5环境下OpenSSL实战:自己搭建CA中心,申请,签发,吊销,导入证书,SSL 握手详解

CentOS6.5环境下OpenSSL实战: 自己搭建CA中心,申请,签发,吊销,导入证书,SSL 握手详解

SSL握手

一.SSL握手有三个目的:1. 客户端与服务器需要就一组用于保护数据的算法达成一致:2. 它们需要确立一组由那些算法所使用的加密密钥:3. 握手还可以选择对客户端进行认证. 二.SSL握手过程:1. 客户端将它所支持的算法列表和一个用作产生密钥的随机数发送给服务器:2. 服务器从算法列表中选择一种加密算法,并将它和一份包含服务器公用密钥的证书发送给客户端:该证书还包含了用于认证目的的服务器标识,服务器同时还提供了一个用作产生密钥的随机数:3. 客户端对服务器的证书进行验证(有关验证证书,可以参考

捉虫记:QT5.2 SSL握手失败问题

最近在测试项目的时候,出现了这样一个bug:在某些win7和 win8主机上,我们的客户端使用paypal进行付款时,出现SSL握手失败的问题. 项目使用QT5.2.1开发,由于QT移植了开源的webkit,我们在项目中内置了一个浏览器,用来完成商品浏览和付款. 问题来了,当然需要进行"捉虫"了. 自从上次OpenSSL爆出"心脏出血"(见wiki),我们也使用了最新的openssl代码. 首先,需要定位问题出现的位置具体在哪里. 好在QT是开源的,方便我们定位问题

SSL握手流程

一.SSL是什么? 安全套接字(SSL)协议是Web浏览器和Web服务器之间安全交换信息的协议. SSL介于应用层和TCP层之间,应用层数据不再直接传递给传输层,而是传递给SSL层,SSL层对从应用层收到的数据进行加密,并增加自己的SSL头. History: 1994年,NetScape公司设计了SSL协议(Secure Sockets Layer)的1.0版,但是未发布. 1995年,NetScape公司发布SSL 2.0版,很快发现有严重漏洞. 1996年,SSL 3.0版问世,得到大规模

ssl握手协议中的CipherSuite

下面是一个ssl握手的过程,没有进行客户端验证: 1.C-S:ClientHello---cipher-suit-list 2.S-C:ServerHello---selected-cipher-suit 3.S-C:ServerKeyExchange 4.S-C:ServerHelloDone 5.C-S:ClientKeyExchange 6.C-S:完成 7.S-C:完成 第3步是否发送要看c和s协商的cipher-suit是什么,cipher-suit包含四个部分(将摘要算法并入认证算法

加密、签名和SSL握手机制细节

1.1 背景知识 对称加密     :加密解密使用同一密钥,加解密速度快.随着人数增多,密钥数量急增n(n-1)/2. 非对称加密 :使用公私钥配对加解密,速度慢.公钥是从私钥中提取出来的,一般拿对方公钥加密来保证数据安全性,拿自己的私钥加密来证明数据来源的身份. 单向加密     :不算是加密,也常称为散列运算,用于生成独一无二的校验码(或称为指纹.特征码)来保证数据的完整性和一致性,如MD5.SHA.具有雪崩效应,任何一点数据的改变,生成的校验码值变化非常大. 互联网数据安全可靠的条件: 1