TLS协议分析 (三) record协议

转自:http://chuansong.me/n/1268791552834

4. record 协议

record协议做应用数据的对称加密传输,占据一个TLS连接的绝大多数流量,因此,先看看record协议
图片来自网络:

Record 协议 — 从应用层接受数据,并且做:

  1. 分片,逆向是重组

  2. 生成序列号,为每个数据块生成唯一编号,防止被重放或被重排序

  3. 压缩,可选步骤,使用握手协议协商出的压缩算法做压缩

  4. 加密,使用握手协议协商出来的key做加密/解密

  5. 算HMAC,对数据计算HMAC,并且验证收到的数据包的HMAC正确性

  6. 发给tcp/ip,把数据发送给 TCP/IP 做传输(或其它ipc机制)。

4.1. SecurityParameters

record层的上述处理,完全依据下面这个SecurityParameters里面的参数进行:

struct {
    ConnectionEnd  entity;
    PRFAlgorithm   prf_algorithm;
    BulkCipherAlgorithm    bulk_cipher_algorithm;
    CipherType     cipher_type;
    uint8          enc_key_length;
    uint8          block_length;
    uint8          fixed_iv_length;
    uint8          record_iv_length;
    MACAlgorithm   mac_algorithm;
    uint8          mac_length;
    uint8          mac_key_length;
    CompressionMethod  compression_algorithm;
    opaque         master_secret[48];
    opaque         client_random[32];
    opaque         server_random[32];
} SecurityParameters;

record 层使用上面的SecurityParameters生成下面的6个参数(不是所有的CipherSuite都需要全部6个,如果不需要,那就是空):

 client write MAC key
 server write MAC key
 client write encryption key
 server write encryption key
 client write IV
 server write IV

当handshake完成,上述6个参数生成完成之后,就可以建立连接状态,连接状态除了上面的SecurityParameters,还有下面几个参数,并且随着数据的发送/接收,更新下面的参数:

  • compression state
    :      当前压缩算法的状态。

  • cipher state
    :     加密算法的当前状态,对块加密算法比如aes,包含密码预处理生成的轮密钥(感谢温博士指出) “round key”,还有IV等;对于流加密,包含能让流加密持续进行加解密的状态信息

  • sequence number
    :    每个连接状态都包含一个sequence number,并且读和写状态有不同的sequence number。当连接开始传输数据时,sequence number必须置为0.  sequence number 是uint64类型的,并且不得超过 $ 2^{64}-1$ 。s.  Sequence number不得回绕。如果一个TLS实现无法避开回绕一个sequence number,必须进行重协商。sequence number在每个record被发送时都增加1。并且传输的第1个Record必须使用0作为sequence number。

此处有几个问题值得思考:

(1).  为什么MAC key , encryption key, IV 要分别不同?

在密码学中,对称加密算法一般需要encryption key,IV两个参数,MAC算法需要MAC key参数,因此这3个key用于不同的用途。
当然,不是所有的算法都一定会用到这3个参数,例如新的aead型算法,就不需要MAC key。

(2). 为什么client和server要使用不同的key
如果TLS的双方使用相同的key,那么当使用stream cipher加密应用数据的时候,stream cipher的字节流在两个方向是一样的,如果攻击者知道TLS数据流一个方向的部分明文(比如协议里面的固定值),那么对2个方向的密文做一下xor,就能得到另一个方向对应部分的明文了。

还有,当使用 aead 比如 aes-gcm 做加密的时候,aead标准严格要求,绝对不能用相同的 key+nonce 加密不同的明文,故如果TLS双方使用相同的key,又从相同的数字开始给nonce递增,那就不符合规定,会直接导致 aes-gcm 被攻破。

参考:
http://crypto.stackexchange.com/questions/2878/separate-read-and-write-keys-in-tls-key-material

4.2. record层分段

如上图所示,对要发送的数据流,首先分段,分段成如下格式:

struct {
    uint8 major;
    uint8 minor;
} ProtocolVersion;
enum
{    change_cipher_spec(20), alert(21), handshake(22),    application_data(23), (255) } ContentType;
struct
{    ContentType type;    ProtocolVersion version;    uint16 length;    opaque fragment[TLSPlaintext.length]; } TLSPlaintext;
  • version字段
    :  ,定义当前协商出来的TLS协议版本,例如 TLS  1.2   version 是 { 3, 3 }

  • length字段
    :  即长度,tls协议规定length必须小于 214,一般我们不希望length过长,因为解密方需要收完整个record,才能解密,length过长会导致解密方需要等待更多的rtt,增大latency,破坏用户体验,参考 [Web性能权威指南] 链接 http://book.douban.com/subject/25856314/ TLS那一章。

  • type字段
    :  ,用来标识当前record是4种协议中的哪一种,

record压缩 :  TLS协议定义了可选的压缩,但是,由于压缩导致了 2012 年被爆出[CRIME攻击,BREACH攻击] 链接 https://en.wikipedia.org/wiki/CRIME  ,所以在实际部署中,一定要禁用压缩
 http://www.unclekevin.org/?p=640
 http://www.freebuf.com/articles/web/5636.html

4.3. record层的密码学保护

record层的密码学保护:

经过处理后的包格式定义如下:

struct {
    ContentType type;
    ProtocolVersion version;
    uint16 length;
   select (SecurityParameters.cipher_type) {            case stream: GenericStreamCipher;                case block:  GenericBlockCipher;                case aead:   GenericAEADCipher;    } fragment; } TLSCiphertext;

TLS协议设计目标中的 1.保密(encryption) 2.完整性(authentication) ,和防重放就在这里实现。
实现方式有3类:

  1. Block Cipher (CBC mode of operation) + HMAC:例如 aes-128-cbc+hmac-sha256

  2. Stream Cipher (RC4) + HMAC

  3. Authenticated-Encryption using block cipher (GCM/CCM 模式):例如 aes-128-gcm

1.Block Cipher+HMAC 和 2.Stream Cipher + HMAC 的各类算法目前(2015年)都已经爆出各种漏洞(后文解释),目前最可靠的是 3.Authenticated-Encryption 类的算法,主要就是aes-gcm,下一代的TLS v1.3干脆只保留了3.Authenticated-Encryption,把1和2直接禁止了(所以。。。你真的还要继续用aes-cbc吗?)。

GCM模式是AEAD的,所以不需要MAC算法。
GCM模式是AEAD的一种,AEAD 的 作用类似于  Encrypt-then-HMAC ,例如 Sha256 + Salt + AES + IV

此处需要介绍一个陷阱
在密码学历史上,出现过3种加密和认证的组合方式:

  1. Encrypt-and-MAC

  2. MAC-then-Encrypt

  3. Encrypt-then-MAC

在TLS协议初定的那个年代,人们还没意识到这3种组合方式的安全性有什么差别,所以TLS协议规定使用 2.MAC-then-Encrypt,即先计算MAC,然后把 “明文+MAC” 再加密(块加密或者流加密)的方式,做流加密+MAC,和块加密+MAC。
但是,悲剧的是,近些年,人们发现 MAC-then-Encrypt 这种结构导致了 很容易构造padding oracle 相关的攻击,例如这在TLS中,间接形成被攻击者利用,这间接导致了 BEAST 攻击 , Lucky 13攻击 (CVE-2013-0169), 和 POODLE 攻击 (CVE-2014-3566).

目前因此,学术界已经一致同意: Encrypt-then-MAC 才是最安全的!
tls使用的是 MAC-then-Encrypt 的模式,导致了一些问题。
具体比较,参见:
http://cseweb.ucsd.edu/~mihir/papers/oem.pdf
https://www.iacr.org/archive/crypto2001/21390309.pdf
http://crypto.stackexchange.com/questions/202/should-we-mac-then-encrypt-or-encrypt-then-mac
https://news.ycombinator.com/item?id=4779015
http://tozny.com/blog/encrypting-strings-in-android-lets-make-better-mistakes/

鉴于这个陷阱如此险恶,学术界有人就提出了,干脆把Encrypt和MAC直接集成为一个算法,在算法内部解决好安全问题,不再让码农选择,避免众码农再被这个陷阱坑害,这就是AEAD(Authenticated-Encryption With Addtional data)类的算法,GCM模式就是AEAD最重要的一种。

4.4. record层的密码学保护—MAC

TLS record 层 MAC的计算方法:

MAC(MAC_write_key, seq_num +
        TLSCompressed.type +
        TLSCompressed.version +
        TLSCompressed.length +
        TLSCompressed.fragment);

其中的seq_num是当前record的 sequence number,每条record都会++,
可以看到把 seq_num,以及record essay-header里面的几个字段也算进来了,这样解决了防重放问题,并且保证record的任何字段都不能被篡改。

算完MAC,格式如下:

stream-ciphered struct {
    opaque content[TLSCompressed.length];
    opaque MAC[SecurityParameters.mac_length];
} GenericStreamCipher;

然后根据SecurityParameters.cipher_type,选择对应的对称加密算法进行加密,分类解说如下:

4.5. record层的密码学保护—stream cipher

stream cipher:
算stream cipher,stream cipher的状态在连续的record之间会复用。
stream cipher的主力是RC4,但是目前RC4已经爆出多个漏洞,所以实际中基本不使用流加密没法,详情请见:

https://tools.ietf.org/html/rfc7457#section-2.5

[[FreeBuf] RC4加密已不再安全,破解效率极高] 链接 http://www.freebuf.com/news/72622.html

http://www.imperva.com/docs/HII_Attacking_SSL_when_using_RC4.pdf

4.6. record层的密码学保护— CBC block cipher

CBC模式块加密
TLS目前靠得住的的块加密cipher也不多,基本就是AES(最靠谱,最主流),Camellia,SEED,(3DES,IDEA之类已经显得老旧,DES请禁用),加密完的格式如下:

struct {
  opaque IV[SecurityParameters.record_iv_length];
  block-ciphered struct {
      opaque content[TLSCompressed.length];
      opaque MAC[SecurityParameters.mac_length];
      uint8 padding[GenericBlockCipher.padding_length];
      uint8 padding_length;
  };
} GenericBlockCipher;

这个值得说道说道,因为我们码农平常在业界还能看到很多用AES-CBC的地方,其中的几个参数:

IV
: : 要求必须用密码学安全的伪随机数生成器(CSPRNG)生成,并且必须是不可预测的,在Linux下,就是用用/dev/urandom,或者用 openssl 库的 RAND_bytes()。

注意:TLS 在 1.1版本之前,没有这个IV字段,前一个record的最后一个block被当成下一个record的IV来用,然后粗大事了,这导致了 [BEAST攻击] 链接 http://www.openssl.org/~bodo/tls-cbc.txt  。
  所以,TLS1.2改成了这样。
  (还在使用CBC的各位,建议关注一下自己的IV字段是怎么生成出来的。如果要用,最好和TLS1.2的做法保持一致)。

其中  SecurityParameters.record_iv_length 一定等于    SecurityParameters.block_size.
  例如 AES-256-CBC的 IV 一定是16字节长的,因为AES 128/192/256 的block size都是16字节。

padding
:   使用CBC常用的PKCS 7 padding(在block size=16字节这种情况下,和pkcs 5的算法是一回事,java代码里面就可以这么用这个case里,和pkcs 5的结果是一样的)

padding_length
:   就是PKCS 7 padding的最后一个字节

注意2个险恶的陷阱:

  1. 实现的代码必须在收到全部明文之后才能传输密文,否则可能会有BEAST攻击

  2. 实现上,根据MAC计算的时间,可能进行时间侧通道攻击,因此必须确保—运行时间和padding是否正确无关

4.7. record层的密码学保护— AEAD cipher

AEAD
到了我们重点关注的AEAD,AEAD是新兴的主流加密模式,是目前最重要的模式,其中主流的AEAD模式是 aes-gcm-128/aes-gcm-256/chacha20-poly1305

AEAD加密完的格式是:

struct {
   opaque nonce_explicit[SecurityParameters.record_iv_length];
   aead-ciphered struct {
       opaque content[TLSCompressed.length];
   };
} GenericAEADCipher;

AEAD ciphers的输入是: key,nonce, 明文,和 “additional data”.
  key是   client_write_key 或者 the server_write_key.  不需要使用 MAC key.

每一个AEAD算法都要指定不同的nonce构造算法,并指定 GenericAEADCipher.nonce_explicit 的长度.
  在TLS 1.2中,规定很多情况下,可以按照rfc5116 section 3.2.1的技术来做。其中record_iv_length是nonce的显式部分的长度,nonce的隐式部分从key_block作为  client_write_iv和 and server_write_iv得出,并且把显式部分放在 GenericAEAEDCipher.nonce_explicit 里.

在TLS 1.3 draft中,做了更改:

  1. 规定 AEAD算法的 nonce的长度规定为 max(8 bytes, N_MIN),即如果N_MIN比8大,就用N_MIN; 如果比8小,就用8。

  2. 并且规定 N_MAX小于8字节的AEAD不得用于TLS。

  3. 规定TLS AEAD中每条record的nonce通过下面的方法构造出来:
    64bit的sequence number的右侧填充0,直到长度达到iv_length。然后把填充过的sequence number和静态的 client_write_iv或 server_write_iv (根据发送端选择)做异或(XOR)。异或完成后,得到的 iv_length 的nonce就可以做每条record的nonce用了。

    AEAD输入的明文就是  TLSCompressed.fragment (记得上面的介绍吗?AEAD是MAC和encrypt的集成,所以输入数据不需要在算MAC了).

    AEAD输入的additional_data 是:

additional_data = seq_num + TLSCompressed.type +
    TLSCompressed.version + TLSCompressed.length;

“+” 表示字符串拼接。
   可以看到,此处类似上面的MAC计算,算入了seq_num来防重放,type,version,length等字段防止这些元数据被篡改。

AEADEncrypted = AEAD-Encrypt(write_key, nonce, plaintext,
    additional_data)

解密+验证完整性:

TLSCompressed.fragment = AEAD-Decrypt(write_key, nonce,
    AEADEncrypted,
    additional_data)

如果解密/验证完整性失败,就回复一条 fatal bad_record_mac alert 消息.

aes-gcm的iv长度,nonce长度,nonce构成等,后续再深入探讨。

4.8. record层的密码学保护— Key扩展

Key 扩展

TLS握手生成的master_secret只有48字节,2组encryption key, MAC key, IV加起来,长度一般都超过48,(例如 AES_256_CBC_SHA256 需要 128字节),所以,TLS里面用1个函数,来把48字节延长到需要的长度,称为PRF:

key_block = PRF(SecurityParameters.master_secret,    "key expansion",
    SecurityParameters.server_random +
    SecurityParameters.client_random);

然后,key_block像下面这样被分割:

client_write_MAC_key[SecurityParameters.mac_key_length]
server_write_MAC_key[SecurityParameters.mac_key_length]
client_write_key[SecurityParameters.enc_key_length]
server_write_key[SecurityParameters.enc_key_length]
client_write_IV[SecurityParameters.fixed_iv_length]
server_write_IV[SecurityParameters.fixed_iv_length]

TLS使用HMAC结构,和在CipherSuite中指定的hash函数(安全等级起码是SHA256的水平)
 来构造PRF,

首先定义P_hash,把(secret,seed)扩展成无限长的字节流:

P_hash(secret, seed) = HMAC_hash(secret, A(1) + seed) +
    HMAC_hash(secret, A(2) + seed) +
    HMAC_hash(secret, A(3) + seed) + ...

其中”+”表示字符串拼接。
 A() 定义为:

A(0) = seed
A(i) = HMAC_hash(secret, A(i-1))

TLS的 PRF 就是把 P_hash 应用在secret上:

 PRF(secret, label, seed) = P_(secret, label + seed)

其中 label 是一个协议规定的,固定的 ASCII string.

要注意的是,TLS 1.3里面已经废弃了这种方式,改为使用更靠谱的 HKDF,HKDF 也是 html5的WebCryptoAPI的标准算法之一。

你可能感兴趣的:(SSL/TLS)