TLS/SSL协议格式(一)

2017-01-18  本文已影响0人  allanYan

概述

TLS/SSL协议实际上是分层的,类似IP/TCP协议;

record.png

TLS Record Protocol

上图为一个TLS Record Layer包,可用看到其结构为:

  1. ContentType(1byte)

Record类型:

  1. ProtocolVersion(2bytes)
    TLS/SSL协议版本号,例如0301表示TLS1.0,0302表示TLS1.1,0303表示TLS1.2;

  2. length(2bytes)
    Body数据的长度,最大为2^14;

  3. Body
    消息体,具体的格式由ContentType、是否压缩、是否加密决定;

TCP包中除了TLS Record Layer外,可以看到前面还有部分内容,这是因为按照网络协议七层规范,层次关系为数据链路层-》网络层-》传输层-》TLS/SSL;
其中数据链路层的结构为目的地址+源地址+类型,对应到图上:

Handshake Protocol

TLS Record Protocol的ContentType=22时,Body的内容采用Handshake Protocol;

  1. HandshakeType:
    握手类型,包括:
  1. length
    消息长度,占用3bytes;

Hello request

概述

Hello request消息由服务端发送给客户端,通过客户端重新开始SSL握手;

消息格式

消息体为空;

Client hello

概述

客户端发送Client hello消息开始SSL握手;

消息格式

  1. ProtocolVersion

    2bytes,客户端希望使用的SSL/TLS协议版本号,一般而言应该是客户端支持的最大版本号;

  2. Random

    • GMT Unix timstamp

      4bytes,标准的UNIX 32位时间格式,表示距离1970年1月1号的秒数;

  1. SessionId

    SessionId可为空,长度不固定,编码方式采用长度+内容,用1byte表示长度,读取时先读取长度,然后根据长度读取内容;

  2. CipherSuiteList
    编码方式采用长度+内容,用2bytes表示长度,读取时先读取长度,然后根据长度读取内容;每个CipherSuite占用2bytes;例如0xc030表示TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384;具体可参见RFC5246;

  3. CompressionMethod
    压缩方法,编码方式采用长度+内容,用1byte表示长度,读取时先读取长度,然后根据长度读取内容;

  4. Extensions
    编码方式采用长度+内容,用2bytes表示长度,读取时先读取长度,然后根据长度读取内容;
    每个Extension的格式为:

    type(2bytes)+length(2bytes)+extension body
    

    Extension的type定义请参见RFC 3546,列举部分如下:

    • server_name(0)
    • max_fragment_length(1)
    • client_certificate_url(2)
    • trusted_ca_keys(3)
    • truncated_hmac(4)
    • status_request(5)

server hello

概述

Server hello消息由服务端发送给客户端,作为Client hello的响应;如果服务端无法找到匹配的SSL/TLS版本或CipherSuits,会返回handshake failure alert;

消息格式

  1. ProtocolVersion

    2bytes,服务端根据客户端的ProtocolVersion和自己支持的版本,协商出来的版本号;

  2. Random

    • GMT Unix timstamp

      4bytes,标准的UNIX 32位时间格式,表示距离1970年1月1号的秒数;

  1. SessionId

    SessionId可为空,长度不固定,编码方式采用长度+内容,用1byte表示长度,读取时先读取长度,然后根据长度读取内容;

  2. CipherSuite
    服务端选用的CipherSuite,占用2bytes;例如0xc030表示TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384;具体可参见RFC5246;

  3. CompressionMethod
    占用1byte,服务端选用的压缩算法;

  4. Extensions
    编码方式采用长度+内容,用2bytes表示长度,读取时先读取长度,然后根据长度读取内容;
    每个Extension的格式为:

    type(2bytes)+length(2bytes)+extension body
    

    Extension的type定义请参见RFC 3546,列举部分如下:

    • server_name(0)
    • max_fragment_length(1)
    • client_certificate_url(2)
    • trusted_ca_keys(3)
    • truncated_hmac(4)
    • status_request(5)

Server certificate

概述

服务端发送证书到客户端,客户端据此验证服务端身份;一般而言,该消息紧跟着Server hello消息;

消息格式

  1. Certificate Chain length

证书链所占用的字节,用3bytes表示;

  1. X509 Certificate Lists
    列表中的第一个证书为TLS/SSL会话采用的证书,从该证书从获取公钥作为会话的公钥;每个Certificate的格式为:

Server key exchange

概述

该消息一般紧接着Server certificate消息;该消息并不是必须的,取决于协商出的key交换算法;如果Server certificate并不包含计算premaster的所有参数,则必须发送该消息;
采用如下算法需要发送Server certificate消息:

采用如下算法不需要发送Server certificate消息:

由于目前使用较多的是ECDHE,本文只介绍该格式:

消息格式

  1. Curve Type

1byte,目前为常量0x03;

  1. Curve Id
    2bytes,列举部分如下,例如0x0017(23)表示secp256r1;
  1. Pubkey length
    1byte,
  2. Pubkey content
    长度由Pubkey length指定;

Certificate request

概述

该消息是可选的,如果服务端需要验证客户端身份,可以通过该消息要求客户端提供证书;

消息格式

  1. Certificate Type
    证书类型,包含下述类型:
  1. Algorithms

哈希和签名算法列表,从TLS1.2开始,之前版本不存在该字段;用2bytes存储算法列表占用的字节数;
每个Algorithm由hash(1byte)+signature(1byte)组成;

  1. Certificate authority List
    可指定root CA;用2bytes存储长度,每个Certificate authoritylength(2bytes)+content(长度由length确定)组成;

Client certificate

Server certificate相同

Ceritificate verify

概述

该消息由客户端发送到服务端,校验证书

消息格式

  1. protocolVersion>=TLS1.2
Hash Algorithm(1byte)+Sgin Algorithm(1byte)+signature length(2bytes)+signature content
  1. protocolVersion<TLS1.2
length(2bytes)+signature content
上一篇下一篇

猜你喜欢

热点阅读