怎么设置自己做的网站,青岛模板化网站建设,wordpress小程序配置,电商类网站有几个主流程TSL由多个协议组成的两层协议集合#xff0c;工作与应用层和传输层之间。
TLS协议包含两层协议#xff1a;记录层协议#xff08;TLS Record Protocol协议#xff09;和 握手协议#xff08;TLS Handshake Protocol协议#xff09;#xff0c;底层采用可靠传输协议工作与应用层和传输层之间。
TLS协议包含两层协议记录层协议TLS Record Protocol协议和 握手协议TLS Handshake Protocol协议底层采用可靠传输协议如TCP
之所以选取这两个子协议是因为记录层协议发挥了TLS“承上启下”的作用它对从上层应用接收到的待传输数据进行分块、压缩、封装等处理而后将处理后的数据传输给下层再传输给通信的另一方而握手协议是通信双方准备建立TLS连接通信时用到的第一个子协议他是TLS协议中最复杂、涉及密码技术最多的协议。
注出于安全考虑TLS 1.3已取消压缩
记录层协议通过如下方式实现数据的安全传输
链路是私有的使用对称加密方式对应用数据进行加密。对每条链路来说对称加密使用的密钥是各自独立的(通过握手协议协商得到)。记录层协议也可以用于非加密场景链路是可靠的。使用消息认证码MAC来对消息完整性进行校验MAC使用哈希函数SHA-1、SHA-256、SM3等进行运算。记录层协议可以不使用MAC但通常仅限于使用记录层协议作为底层协议来传输协商使用的安全参数。
记录层协议用于封装多种上层协议如握手协议用于在传输/接收应用数据前进行相互认证并协商出加密算法以及使用的密钥。
握手协议使用如下三种方式提供数据的安全传输
对端身份可以通过非对称算法或公钥加密RSA、DSA、SM2等等进行认证。该认证是可选的但通常要求至少通过一种认证方式对对端进行认证协商的共享密钥的过程是安全的窃听者无法获取协商的密钥协商是可靠的攻击者无法在不被链路探测到的情况下修改协商报文。
使用TLS的好处是它与应用层协议是相互独立的上层协议运行在TLS协议之上。TLS协议没有指出如何添加协议来对链路进行安全加固。如何初始化TLS握手以及如何使用认证的证书这些交由TLS之上的协议设计者来实现。
1.HMAC and the Pseudorandom Function带密钥哈希消息认证码伪随机函数
TLS使用MAC来保证消息的合法性。本协议使用的密码套件cipher suites使用了HMAC它的实现基于hsah函数其他密码套件可能使用其他形式的MAC。
注在TLS 1.3之前密码套件的名称是以协商安全设置时使用的身份验证、加密、消息认证码和密钥交换算法组成。TLS 1.3中的密码套件格式已经修改。在TLS 1.3草案文档中密码套件仅用于协商加密和HMAC算法。
除此之外还需要一种在生成或校验密钥时将密钥扩展为数据块的方式。伪随机函数pseudorandom functionPRF可以通过输入密钥、种子、认证的标签即预主密钥、客户端随机数、服务端随机数、常量字符串之后给出任意长度的输出。伪随机函数基于HMAC。本文档所有密码套件使用的的伪随机函数均采用SHA-256的哈希函数。新的密码套件必须明确规定伪随机函数并使用SHA-256或更健壮的hash函数。
密码套件规定了如何使用伪随机函数生成密钥材料key material块加密算法AES等以及MAC算法HMAC-SHA1。
每个密码套件的名称例如TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256定义密钥交换算法、批量加密算法、消息认证码算法以及一个伪随机函数。
密钥交换算法例如ECDHE_RSA用于决定客户端与服务器之间在握手时如何身份验证。批量加密算法例如AES_128_GCM用于加密消息流。它还包括密钥大小及显式和隐式初始化向量密码学随机数的长度。消息认证码算法例如SHA256用于创建消息摘要消息流每个数据块的加密散列。伪随机函数例如TLS 1.2的伪随机函数使用MAC算法的散列函数来创建一个主密钥——连接双方共享的一个48字节368比特的私钥。主密钥在创建会话密钥例如创建MAC时作为一个熵来源。
使用伪随机函数首先需要定义一个扩展密钥的函数P_hash(secretdata)该函数用于扩展密钥长度
P_hash(secret, seed) HMAC_hash(secret, A(1) seed) HMAC_hash(secret, A(2) seed) HMAC_hash(secret, A(3) seed) ...
其中
secret是进行计算所需要的密钥seed是进行计算所需要的数据A(0) seedA(i) HMAC(secretA(i-1))P_hash 能够反复迭代知道产生要求长度的数据
P_hash可以迭代多次来生成所需要的数据。如使用p_SHA256来生成80字节的数据则需要迭代3次(32bytes * 3 96bytes)来生成96字节的数据保留前面80字节后16字节的数据会被丢弃。
使用P_hash生成伪随机函数的方式如下
PRF(secret, label, seed) P_hash(secret, label seed)
label是ASCII字符串如字符串 “slithy toves” 使用时应该为ASCII73 6C 69 74 68 79 20 74 6F 76 65 73 2.The TLS Record Protocol记录层协议
记录层协议是一个层级协议每一层消息可能包括长度length、描述description和内容content字段。记录层协议负责将需要传输的数据分布到管理的块block中可能会对数据进行压缩可选在使用MAC和加密后传输结果。接收端接收到消息之后需要进行解密校验和解压可选操作然后传递到上层业务。当接收到未知的Record类型后必须发送意外消息警报unexpected_message alert。
本文档定义了4种使用记录层协议协议的协议握手handshake协议、报警alert协议、密码规格变更change cipher spec协议、应用数据application data协议。 2.1 Connection States连接状态
记录层协议使用连接状态TLS connection state作为运行环境连接状态指定了压缩算法、加密算法以及MAC算法且拥有消息认证码密钥MAC key和批量加密密钥bulk encryption keys相关的参数。记录层协议始终保持4个连接状态当前读current read、当前写current write、挂起读pending read、挂起写pending write。其中读表示接收数据写表示发送数据。所有的记录都在当前读和当前写状态下处理。挂起状态pending state可以被握手协议修改而密码规格变更消息可以选择性地将挂起状态变为当前状态current state此时挂起状态初始化为空状态empty state。给未初始化的状态配置参数并使之变为当前状态的方式是非法的。除了最初的当前状态外当前状态必须包含经过协商的安全参数。初始的当前状态没有使用加密、压缩、MAC。
连接状态用于跟踪加密状态。写密钥write key用来发送数据读密钥read key用来接收数据。挂起状态用来保存新的加密密钥可以由握手协议生成以及初始向量而当前状态则表示当前使用的密钥当接受到密码规格变更消息时会将挂起状态的密钥覆盖当前状态的密钥这样就会使用更新的密钥进行数据的收发。当更多关于连接状态的介绍可以参考What are read state and write state in SSL connections
连接状态的结构如下
TLS1.1 struct {连接端(ConnectionEnd) 实体(entity)----标识接入的实体为客户端或服务端enum{server, client} ConnectionEnd批量密码算法(BulkCipherAlgorithm) bulk_cipher_algorithm----加解密密码算法enum{null, 对称算法} ConnectionEnd密码类型(CipherType) cipher_type----表示密码算法的类型enum {block} CipherTypeuint8 key_size----密钥长度uint8 key_material_length----密钥材料长度MAC算法(MACAlgorithm) mac_algorithm----用于计算和校验的密码杂凑算法enum{杂凑算法}MACAlgorithmuint8 hash_size----杂凑长度压缩方法(CompressionMethod) compression_algorithm----数据压缩算法enum{null(0), (255)} CompressionMethodopaque master_secret[48]----在协商过程中由预主密钥、客户端随机数、服务端随机数计算出的 48 字节密钥opaque client_random[32]----由客户端产生的32字节opaque server_random[32]----由服务端产生的32字节 } 安全参数(SecurityParameters)
TLS1.1记录层使用安全参数来生成如下6项内容
客户端写校验密钥client write MAC secret服务端写校验密钥server write MAC secret客户端写密钥client write key服务端写密钥server write key
GMSSL struct {连接端(ConnectionEnd) 实体(entity)----标识接入的实体为客户端或服务端enum{server, client} ConnectionEnd批量密码算法(BulkCipherAlgorithm) bulk_cipher_algorithm----加解密密码算法enum{null, sm1, sm4} ConnectionEnd密码类型(CipherType) cipher_type----表示密码算法的类型enum {block} CipherTypeuint8 key_size----密钥长度uint8 key_material_length----密钥材料长度MAC算法(MACAlgorithm) mac_algorithm----用于计算和校验的密码杂凑算法enum{sha1, sm3}MACAlgorithmuint8 hash_size----杂凑长度压缩方法(CompressionMethod) compression_algorithm----数据压缩算法enum{null(0), (255)} CompressionMethodopaque master_secret[48]----在协商过程中由预主密钥、客户端随机数、服务端随机数计算出的 48 字节密钥opaque client_random[32]----由客户端产生的32字节opaque server_random[32]----由服务端产生的32字节unit8 record_iv_length----记录IV长度unit8 mac_length----MAC长度 } 安全参数(SecurityParameters)
GMTLS记录层使用安全参数来生成如下4项内容
客户端写校验密钥client write MAC secret服务端写校验密钥server write MAC secret客户端写密钥client write key服务端写密钥server write key
TLS 1.2 struct {连接端(ConnectionEnd) entity----标识接入的实体为客户端或服务端enum{server, client} ConnectionEnd伪随机算法(PRFAlgorithm) prf_algorithm----通过主密钥(master secret)生成密钥的算法enum {tls_prf_sha256}PRFAlgorithm批量密码算法(BulkCipherAlgorithm) bulk_cipher_algorithm----加解密密码算法enum{null, 对称算法} ConnectionEnd密码类型(CipherType) cipher_type----表示密码算法的类型enum {block} CipherTypeuint8 enc_key_length----加密密钥长度uint8 block_length----块长度uint8 fixed_iv_length----固定IV长度uint8 record_iv_length----记录IV长度MAC算法(MACAlgorithm) mac_algorithm----用于计算和校验的密码杂凑算法enum{杂凑算法}MACAlgorithmuint8 mac_length----MAC长度uint8 mac_key_length----MAC密钥长度压缩方法(CompressionMethod) compression_algorithm----数据压缩算法enum{null(0), (255)} CompressionMethodopaque master_secret[48]----在协商过程中由预主密钥、客户端随机数、服务端随机数计算出的 48 字节密钥opaque client_random[32]----由客户端产生的32字节opaque server_random[32]----由服务端产生的32字节 } 安全参数(SecurityParameters)
TLS 1.2记录层使用安全参数来生成如下6项内容
客户端写校验密钥client write MAC key服务端写校验密钥server write MAC key客户端写加密密钥client write encryption key服务端写加密密钥server write encryption key客户端写初始向量client write IV服务端写初始向量server write IV
key_block PRF(SecurityParameters.master_secret,key expansion,SecurityParameters.server_random SecurityParameters.client_random);
客户端写入client write参数由服务器在接收和处理记录时使用反之亦然。2.3介绍了根据安全参数生成这些项目的算法。
一旦设置了安全参数并生成了密钥就可以通过将连接状态设置为当前状态来实例化连接状态。必须为处理的每个记录更新这些当前状态。每个连接状态都包括以下元素
压缩状态compression state压缩算法的当前状态。密码状态cipher state加密算法的当前状态。这将包括该连接的计划密钥。对于流密码它还将包含允许流继续加密或解密数据所需的任何状态信息。校验密钥MAC key连接的校验密钥序列号sequence number每个连接状态都包含一个序列号且分别由读和写状态维护。当一个连接状态connection state变为活动状态active state时必须置为0。序列号会在每个记录中递增。
2.2Record Layer记录层
2.2.1Fragmentation分段
记录层将数据分成字节或者更小的片段。
每个片段结果如下
struct {内容类型(ContentType) type----上层协议的类型用于处理封装片段fragment结构详见①协议版本(ProtocolVersion) version----协议采用的版本结构详见②uint16 length----TLS明文片段TLSPlaintext fragment的长度不能大于opaque fragment[TLSPlaintext.length]----将传输的应用数据由上层协议处理的特定类型的数据记录层协议不关心具体数据内容 } TLS明文(TLSPlaintext)
enum {密钥规格变更(change_cipher_spec20)报警(alert21)握手(handshake22)应用数据(application_data23)(255) } ①内容类型(ContentType)
struct {uint8 major----主版本uint8 minor----次版本 } ②协议版本(ProtocolVersion) 不能发送零长度的握手、报警、密钥交换数据。但可以发送零长度的应用数据可能用于链路探测。
在TLS记录层协议中应用数据处理的优先级很低一般在上层协议握手协议处理完成后发送。
2.2.2Record Compression and Decompression记录压缩和解缩
所有的记录record都使用当前状态current state中定义的压缩算法进行压缩。初始的压缩算法为CompressionMethod.null任何时候都有一个激活的压缩算法。压缩算法将TLS明文TLSPlaintext结构转换为TLS压缩TLSCompressed结构。当连接状态connection state变为激活态active时压缩算法会使用默认状态信息进行初始化。压缩算法不能造成数据丢失且内容长度不能超过1024字节当解缩函数解缩压缩片段TLSCompressed.fragment时如果数据大于字节必须返回解压失败decompression failure的致命错误。
压缩后数据结构如下
struct {内容类型(ContentType) type----结构详见2.2.1①协议版本(ProtocolVersion) version----结构详见2.2.1②uint16 length----以字节为单位的TLS压缩片段TLSCompressed.fragment的长度不大于字节opaque fragment[TLSPlaintext.length]----TLS明文片段TLSPlaintext.fragment的压缩形式 } TLS压缩(TLSCompressed)
解压缩函数必须保证不能造成缓存buffer溢出实际使用中一般禁用压缩
2.2.3Record Payload Protection记录有效载荷保护
加密和MAC函数会将TLSCompressed结构转化为TLSCiphertext结构解密函数则反转上述过程。record的MAC包含序列号因此能够探测到重复多余缺失消息的场景。
struct {内容类型(ContentType) type----结构详见2.2.1①协议版本(ProtocolVersion) version----结构详见2.2.1②uint16 length----以字节为单位的TLS密文片段TLSCiphertext.fragment的长度不大于字节select安全参数密码类型(SecurityParameters.cipher_type) { case streamGenericStreamCipher---通用流密码 case blockGenericBlockCipher---通用分组密码 case aeadGenericAEADCipher---通用AEAD(Authenticated Encryption with Associated Data,关联数据的身份验证加密)密码 }fragment----带校验码MAC的TLSCompressed.fragment加密形式 } TLS密文(TLSCiphertext)
2.2.3.1 Null or Standard Stream Cipher空和流密码
流密码将TLS压缩片段TLSCompressed.fragment结构转换为TLS密文片段TLSCiphertext.fragment的流stream结构如下
stream-ciphered struct{opaque content [TLSCompressed.length]---TLS压缩TLSCompressed长度opaque MAC [SecurityParameters.mac_length]---安全参数校验码算法SecurityParameters.mac_algorithm指定的MAC算法 }通用流加密GenericStreamCipher
MAC的生成方式如下其中“”表示串联
MAC(MAC_write_key, seq_num(序列号) TLSCompressed.type TLSCompressed.version TLSCompressed.length TLSCompressed.fragment);seq_num序列号。每一个读写状态都分别维持一个单调递增序列号。序列号的类型为uint64序列号初始值为零最大不能超出。序列号不能回绕。如果序列号溢出那就必须重新开始握手。
MAC必须在被加密前计算出来流密码对包括MAC在内的整个块进行加密。对于不使用同步向量synchronization vector的流密码如RC4从一个记录末尾开始的流密码状态仅用于后续数据包。如果密码套件为TLS_NULL_WITH_NULL_NULL加密方式则由操作类型组成如数据没有被加密MAC为0即NULL的定义。对于空null和流密码stream ciphers来说TLS密文长度(TLSCiphertext.length) TLS压缩长度(TLSCompressed.length) 安全参数校验码长度(SecurityParameters.mac_length)
2.2.3.2 CBC Block Cipher密文分组链接分组密码
CBC模式的全称是Cipher Block Chaining模式密文分组链接模式
分组密码3DES、AES、SM4使用加密和MAC函数将TLS压缩片段TLSCompressed.fragment结构转换为TLS密文片段TLSCiphertext.fragment的块block结构如下
struct {opaque IV [SecurityParameters.record_iv_length]----通用分组加密GenericBlockCipher中传输的初始化向量必须随机生成block-ciphered struct { ---分组加密结构 opaque content [TLSCompressed.length] ---TLS压缩TLSCompressed长度 opaque MAC [SecurityParameters.mac_length]---IV的长度其正确值与使用的密码套件相关 uint8 padding[GenericBlockCipher.padding_length]---填充的数据详见① uint8 padding_length---填充长度该长度不包括填充长度本身 } } 通用分组加密GenericBlockCipher
①padding填充的数据在数据加密前需要将数据填充为密码算法分组长度的整数倍填充的长度不能超过255个字节。填充的每个字节的内容是填充的字节数。接收者应检查这个填充如果出错发送无效的记录MACbad_record_mac报警消息。
组对于CBC模式下的块密码密码块链在传输任何密文之前了解记录的整个明文是至关重要的。否则攻击者有可能发起[CCBATT]中描述的攻击。Canvel等人[CCBCTIME]已经证明了基于计算MAC所需时间的CBC填充的定时攻击。为了抵御这种攻击实现必须确保记录处理时间基本相同无论填充是否正确。通常最好的方法是计算MAC即使填充不正确然后才拒绝数据包。例如如果填充pad看起来不正确则实现可能假设为零长度的填充然后计算MAC。这留下了一个小的定时信道因为MAC性能在某种程度上取决于数据片段的大小但由于现有MAC的大块大小和定时信号的小大小它被认为不够大而不可利用。
2.2.3.3 AEAD Ciphers关联数据的身份验证加密密码
关联数据的身份验证加密密码AEAD Cipher如CCM或GCM函数将TLS压缩片段TLSCompressed.fragment结构转换为TLS密文片段TLSCiphertext.fragment的AEADSecurityParameters.mac_algorithm结构如下
struct {opaque nonce_explicit [SecurityParameters.record_iv_length]----随机数aead-ciphered struct { ---AEAD加密结构 opaque content [TLSCompressed.length] ---TLS压缩TLSCompressed长度 } } 通用AEAD加密GenericAEADCipher
AEAD使用密钥key、随机数nonce明文plaintext和additional data作为输入进行身份认证。密钥key可以是客户端写密钥client_write_key或服务端写密钥server_write_key没有用到校验码密钥MAC key。明文为TLS压缩片段TLSCompressed.fragment。额外的认证数据也被称为附加数据additional_data定义如下
additional_data seq_num TLSCompressed.type TLSCompressed.version TLSCompressed.length
AEAD输出aead_output包括AEAD加密操作的密文其长度通常大于TLS压缩长度TLSCompressed.length但会随着AEAD密码AEAD cipher变化。由于密码ciphers可能会包含填充padding数量可能会随着TLS压缩长度的不同而不同。每个AEAD密码的输出不能大于1024字节。
AEADEncrypted AEAD-Encrypt(write_key, nonce, plaintext,additional_data)
为了加密和验证AEAD密码AEAD cipher会采用密钥key随机数nonce和additional data以及AEAD加密值AEADEncrypted value。输出为明文或错误信息没有完整性校验。如果解密失败则发出无效的记录MACbad_record_mac报警消息。
TLSCompressed.fragment AEAD-Decrypt(write_key, nonce,AEADEncrypted,additional_data)
2.3 Key Calculation密钥计算
记录层协议使用算法结合握手协议提供的安全参数来生成当前状态current state需要的密钥keys。主密钥master secret被分割为客户端写校验码密钥client write MAC key、服务端写校验码密钥server write MAC key、客户端写加密密钥client write encryption key和服务端写加密密钥server write encryption key这四个密钥按照字节顺序分割未使用的值为空。一些AEAD密码会使用到客户端写初始向量client write IV和服务端写初始向量server write IV。
当密钥和校验码密钥MAC keys生成后主密钥作为熵。此处使用伪随机函数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] ----服务端写初始向量
当前客户端写初始向量和服务端写初始向量仅用于AEAD密码
主密钥算法如下
master_secret PRF(pre_master_secret, ----预主密钥master secret,ClientHello.random ----客户端随机数ServerHello.random ----服务端随机数
)[0..47];记录层协议使用连接状态connection state来维护加密状态它使用握手协议来获取安全参数并生成相应的密钥最后对数据进行加密传输。 3 The TLS Handshaking ProtocolsTLS握手协议
TLS有三个子协议用于为记录层提供安全参数进行相互认证初始化协商以及报告错误。
握手协议handshake Protocols用来协商会话session包含以下项目
会话标识符session identifier服务端选择的随机序列号用于标记激活的或是重用的会话对等方证书peer certificates对端的X509 v3证书。压缩方法compression method加密前使用的压缩算法密码规范cipher spec指定用于生成密钥的伪随机函数块加密算法null、AES、SM4等和MAC算法(如HMAC-SHA1、HMAC-SM3)。主密钥master secret客户端和服务端的48字节的共享密钥是否重用is resumable用于标记该会话是否能被重用
这些参数用来生成安全参数。可以通过握手协议的重用特性使用相同的会话来初始化链接。
3.1 Change Cipher Spec Protocol密码规格变更协议
密码规格变更协议change cipher spec Protocol主要用于通知密码规格cipher spec的改变即通知对方使用刚协商好的安全参数来保护接下来的数据。该消息用当前的压缩算法压缩并用当前的密码规格加密如果是首次协商该消息为明文。
该消息的长度为一个字节其值为1。客户端和服务端都要在安全参数协商完毕之后完成Finished消息前、握手结束消息之前发送此消息。
对于刚协商好的密钥写密钥在此消息发送之后立即启用读密钥在收到吃消息之后立即启用。
密码变更消息结构定义如下
struct { enum { change_cipher_spec(1), (255) } type }ChangeCipherSpec
客户端或服务端通过发送密码规格变更ChangeCipherSpec消息来通知对端后续记录records将使用新协商的密码规格和密钥加密保护。接收端接收到该消息后会通知记录层将读挂起状态read pending state中的内容拷贝到读当前状态read current state中。在发送完该消息之后发送端必须将写挂起状态write pending state中的内容拷贝到写激活状态write active state中。
协商好的安全参数会保存在写挂起状态中当一端需要使用新的加密算法时会发送密码规格变更消息并立即将写挂起状态中的内容覆盖到写当前状态write current state中接收端则修改读状态read state的内容。
如果在数据传输过程中出现了重握手双方仍然可以使用旧的密码规格CipherSpec。但是当收到密码规格变更消息时必须使用新的密码规格。发送密码规格变更的一段并不知道对端是否已经计算出了新的密钥因此在接收端可能需要一小段时间来缓存接收到的数据。
3.2 Alert Protocol警报协议
报警alert表达了该消息的严重性并描述了该报警。致命fatal级别的报警会导致直接断开链路在这种情况下该会话session的其他链路可能会继续连接但该会话编号session id会被标记为不可用用来防止重建链接。跟其他消息一样报警也会被压缩并加密。
struct {AlertLevel level----报警级别结构详见①AlertDescription description ----报警说明结构详见② } Alert
enum {warning (1) ----警告fatal (20) ----致命(255) } ①报警等级AlertLevel
enum{close_notify (0)----关闭通知unexpected_message (10) ----意外信息bad_record_mac (20) ----无效的记录消息校验码decryption_failed_RESERVED (21) ----解密失败 - 保留字段record_overflow (22) ----记录溢出decompression_failure (30) ----解压失败handshake_failure (40) ----握手失败no_certificate_RESERVED (41) ----无证书 - 保留字段bad_certificate (42) ----无效证书unsupported_certificate (43) ----不支持的证书certificate_revoked (44) ----证书已撤销certificate_expired (45) ----证书已过期certificate_unknown (46) ----未知证书illegal_parameter (47) ----非法参数unknown_ca (48) ----未知证书颁发机构access_denied (49) ----拒绝访问decode_error (50) ----解码错误decrypt_error (51) ----解密错误export_restriction_RESERVED (60) ----导出限制 - 保留字段protocol_version (70) ----协议版本insufficient_security (71) ----安全性不足internal_error (80) ----内部错误user_canceled (90) ----用户取消no_renegotiation (100) ----禁止重新协商unsupported_extension (110) ----不支持的扩展(255) } ②报警说明AlertDescription
3.2.1 Closure Alerts关闭报警
除非出现致命报警客户端和服务端任何一方在结束连接之前都应发送关闭通知信息。对于该消息的发出方该消息通知对方不再发送任何数据可以等待接收方回应的关闭通知消息后关闭本次连接也可以立即关闭本次连接。对于接收方收到该消息后应回应一个关闭通知消息任何关闭本次连接不再接收和发送数据。
3.2.2. Error Alerts错误报警
TLS握手协议处理错误的方式很简单当一方发现错误时会将该消息发往对端。当发送或接收该消息时两端必须立即断开链接并删除所有与链接相关的会话信息密钥等。任何被致命报警fatal alert关闭的链接都不能重用。
当遇到无法判定的报警alert级别的错误发送端可能会选择将其作为致命fatal级别的错误处理。如果实现中发送报警的目的是为了关闭链接则必须发送致命级别的报警。
当接收到警告warning级别的报警通常可以继续保持链接。作为发送端由于通常无法判断接收端接收到警告级别的报警的动作因此通常警告的报警作用不大。 错误报警表 2.3 Handshake Protocol Overview握手协议概述
TLS握手产生会话状态session state所需要的加密参数。当客户端和服务端开始通信时会协商产生版本号加密算法可能会进行相互认证以及使用公钥生成共享密钥。
TLS握手涉及如下过程
交换hello消息来协商密码套件交换随机数决定是否会话session重用交换必要的参数协商预主密钥交换证书或链间通信协议IBC用来验证对方使用预主密钥premaster secret和交换的随机数生成主密钥master secret给记录层提供安全参数验证双方计算的安全参数的一致性、握手过程的真实性和完整性。
需要注意的是上层协议不能过度依赖于TLS可以始终提供健壮的安全链接。实际上有很多中间人攻击可以导致两端切换到它们所支持的最不安全方法。TLS协议用来最小化攻击但实际中存在很多可能的攻击方式例如攻击者可以阻止对运行安全服务的端口的访问或者试图让对等方协商未经身份验证的连接。使用TLS的基本原则是上层协议必须知道所需要的安全需求并且不能在低于安全需求的链路上传输信息。因此在使用满足需求的密码套件cipher suite前提下可以认为链路是安全的。
握手过程如下客户端发送客户端问候ClientHello消息给服务端服务端应回应服务端问候ServerHello消息否则产生一个致命错误并且断开连接。客户端问候ClientHello和服务端问候ServerHello用于在客户端和服务端进行基于 RSA、ECC或IBC的密码算法协商以及确定安全传输能力包括协议版本、会话标识、密码套件等属性并且产生和交换随机数。
实际交换密钥key需要用到4个消息服务端证书server Certificate、服务端密钥交换ServerKeyExchange、客户端证书client Certificate、客户端密钥交换ClientKeyExchange。可以通过定义这些消息的格式以及消息的用途来实现交换密钥的方法最终客户端和服务端协商出共享密钥。该密钥必须足够长当前的密钥交换方式交换的密钥长度在46字节以上。
在服务端发送完hello消息之后接着发送自己的证书消息、服务端密钥交换消息。如果服务端需要验证客户端的身份则向客户端发送证书请求CertificateRequest消息。然后发送服务端 hello完成消息表示hello消息阶段已经结束服务端等待客户端的返回消息。如果服务端发送了一个证书请求消息客户端必须返回一个证书消息。然后客户端发送密钥交换消息消息内容取决于客户端问候ClientHello消息和服务端问候ServerHello消息协商出的密钥交换算法。如果客户端发送了证书消息那么也应发送一个带数字签名的证书验证消息供服务端验证客户端的身份。
接着客户端发送密码规格变更ChangeCipherSpec消息此时客户端会将挂起状态pending state中的密码规范Cipher Spec拷贝到当前状态Current state中然后客户端立即使用刚协商的算法和密钥keys secrets加密并发送握手结束Finished消息。服务端则回应密码规格变更消息使用刚协商的算法和密钥加密并发送握手结束消息。至此握手过程结束服务端和客户端可以开始数据安全传输。应用数据不能先于首次握手非TLS_NULL_WITH_NULL_NULL的密码套件发送。 Client ServerClientHello --------ServerHelloCertificate*ServerKeyExchange*CertificateRequest*-------- ServerHelloDoneCertificate*ClientKeyExchangeCertificateVerify*[ChangeCipherSpec]Finished --------[ChangeCipherSpec]-------- FinishedApplication Data ------- Application Data* 表示可选或依赖于上下文关系的消息不是每次都发送
[]不属于握手协议消息
服务端密钥交换是独立的TLS消息不属于握手消息的一部分
如果客户端和服务端决定重用之前的会话可不必重新协商安全参数。客户端发送客户端问候ClientHello消息并且带上要重用的会话标识Session ID。如果服务端有匹配的会话存在服务端则使用相应的会话状态接受连接发送一个具有相同会话标识的服务端问候ServerHello消息。然后客户端和服务端各自发送密码规格变更消息和握手结束消息。至此握手过程结束服务端和客户端可以开始数据安全传输。如果服务端没有匹配的会话标识,服务端会生成一个新的会话标识进行一个完整的握手过程。 Client ServerClientHello --------ServerHello[ChangeCipherSpec]-------- Finished[ChangeCipherSpec]Finished --------Application Data ------- Application Data
2.4 Handshake Protocol握手协议
TLS握手协议属于TLS握手协议的上层协议。该协议用于协商会话session的安全属性。握手(Handshake)消息在TLS记录(record)层之下运行被封装成一个或多个TLS明文TLSPlaintext结构并被当前会话的状态state处理。
握手协议消息的发送顺序必须遵从如下规则乱序的握手消息会导致致命fatal错误不需要的握手消息可以被忽略唯一一个不需要受发送顺序限制的消息是问候请求HelloRequest但客户端端进行握手过程中接收到后应该忽略该消息。
2.4.1 Hello Messages问候消息
问候hello阶段用来建立安全加密的能力。当新建一个会话session的时候记录record层连接状态connection state的加密哈希和压缩算法都初始化为空null。
2.4.1.1. Hello Request问候请求
服务端可以在任何时候发送问候请求HelloReques消息。
该消息用来通知客户端进行协商客户端会发送客户端问候ClientHello消息进行响应。该消息不能用于判定哪一端开始建立链接仅用于初始化协商。如果客户端正在握手协商中或者客户端不同意建立链接客户端会发送禁止重新协商no_renegotiation警告alert。如果服务端发送问候请求HelloRequest并没有受到任何响应服务端可能会关闭链接并发送致命报警fatal alert。
此消息不得包含在整个握手过程中维护的消息哈希中并在完成finished消息和证书验证certificate verify消息中使用。
2.4.1.2 Client Hello客户端问候
客户端发送客户端问候ClientHello消息来初始化握手协商ClientHello也用于响应服务端发送的问候请求HelloRequest消息。
struct {ProtocolVersion client_version----客户端在这个会话中使用的协议版本详见①Random random----客户端产生的随机信息结构详见②SessionID session_id----客户端在连接中使用的会话标识定义为opaque SessionID0..32详见③CipherSuite cipher_suites-2----密码套件列表定义为unit8 CipherSuite[8]详见④CompressionMethod compression_methods -1----压缩算法列表定义为enum{null(0), (255)}CompressionMethodselectextensions_present { ---客户端可能会通过扩展字段来请求服务端的扩展功能 case false struct { } case true Extension extensions-1---扩展功能详见⑤ } } 客户端问候ClientHello
①client_version客户端建议的最低版本且服务端支持的最高版本。TLS 1.2中如果服务端不支持该版本会返回带有低版本的ServerHello如果客户端同意使用该低版本则使用该版本进行协商否则客户端返回协议版本报警protocol_version alert并关闭链接。如果服务端接收到的ClientHello携带了高于服务端支持的最高版本的版本则必须返回服务端所支持的最高版当服务端接收的ClientHello中的版本低于服务端所支持的最高版本如果服务端同意使用该低版本则会选择不高于ClientHello.client_version中定义的最高版本(如服务端支持TLS1.0、TLS1.1、TLS1.2client_version为TLS 1.0则服务端会使用TLS1.0处理)反之返回协议版本报警protocol_version alert。
②客户端问候ClientHello包含一个随机数的结构体。如下
struct { uint32 gmt_unix_time ----标准unix 32位格式的发送端的内部时钟时间未规定该时钟的精度。 opaque random_bytes[28]----生成的28字节的安全随机数随机数并不是会话标识session ID } 随机数Random
③session_idsession_id是一个可变长字段其值有服务端决定。如果没有可以重用的会话标识或希望协商安全参数该字段应为空。如果该字段非空该值表示了服务端需要重用的会话此时会话标识可以来自于①先前的连接标识②当前的连接标识③其他处于连接状态的连接标识。第2种用于当客户端仅需要更新随机数的场景第3种用于建立独立的安全链接而无需进行完整的握手过程。当握手协商通过交换完成Finished后保存的会话标识超时或遇到致命fatal错误时会话标识会变为无效状态。会话标识的实际内容由服务端定义。会话标识生成后应一致保持到被超时删除或与这个会话相关的连接遇到致命错误被关闭。一个会话失效或被关闭时则与其相关的连接都应被强制关闭。
注由于会话标识的传输没有经过加密或MAC保护因为此时加密参数还未协商出来服务端端不能在会话标识中放置敏感字段否则可能导致安全攻击。在握手结束后的消息含完成(Finished)消息中的会话标识会被加密保护。
④cipher_suites客户端问候ClientHello中的密码套件cipher suite列表给出了客户端支持的加密算法并按照客户端偏好排序。每个密码套件包含一个密钥key交换算法、一个加密算法、一个校验MAC算法和PRF。服务端会选择一个合适的密码套件如果没有合适的则会发送握手失败警告handshake failure alert并关闭链接。如果密码套件中包含服务端无法识别的项服务端必须忽略这些密码套件并处理剩余的密码套件。
⑤extensionsClientHello通过判断在compression_method之后是否有多余的字节来确定是否由存在扩展字段。当客户端使用扩展请求额外的功能但服务端不支持时客户端可能会断开握手。服务端必须接收带或不带扩展字段的ClientHello并解析这些扩展字段如果发现无法解析的字段则必须返回解码错误警报decode_error alert。
客户端发送完ClientHello后会等待服务端的ServerHello非ServerHelloHelloRequest除外的消息会被认为致命fatal错误。
2.4.1.3 Server Hello服务端问候
在服务端接收到客户端问候ClientHello且能够接受其中列出的cipher suite时会发送ServerHello
struct {ProtocolVersion server_version----服务端在这个会话中使用的协议版本Random random----服务端产生的随机信息结构与客户端随机数相同SessionID session_idCipherSuite cipher_suitesCompressionMethod compression_methods -1selectextensions_present { case false struct { } case true Extension extensions-1 } } 服务端问候ServerHello
注服务端可能会发送空的会话标识session id表示会话session不会被缓存且不会被重用。
2.4.1.4 Hello Extensions问候扩展
扩展字段的格式如下
struct { ExtensionType extension_type----特定的扩展类型 opaque extension_data0..-1----特定的扩展的信息 }扩展Extension
enum { signature_algorithms(13)(65535) }扩展类型ExtensionType
IANA维护的扩展参见Section 12
只有在ClientHello中出现的扩展才能出现在ServerHello中。如果客户端接收到的ServerHello中出现了ClientHello中不相关的扩展则客户端必须断开链接并发送不支持的扩展致命警告unsupported_extension fatal alert。未来可能会实现面向服务端server-oriented的扩展参见Hello Extensions
当ClientHello或ServerHello消息中存在多个扩展时扩展的可以以任意顺序存在但不能出现同一扩展类型的多个实例。
扩展可以在初始化新的会话session或重用会话时发送。在客户端请求重用会话时由于它并不知道服务端是否会支持不同的扩展这种情况下客户端会发送之前发送过的扩展。
每个扩展类型需要规定在完整的握手和会话重用场景下的作用。目前大部分TLS 扩展的实现中仅关注会话初始化当重用先前会话的时候服务端不会处理ClientHello中的扩展也不会将他们保存在ServerHello中。
开发extension的注意点参见Hello Extensions
2.4.1.4.1 Signature Algorithms签名算法
客户端使用签名算法signature_algorithm扩展来告诉服务端用于数字签名时使用的签名/哈希signature/hash算法对。该扩展的扩展数据extension_data字段包含支持的签名算法supported_signature_algorithms值。
enum { none(0)md5(1)sha1(2)sha224(3)sha256(4)sha384(5)sha512(6)(255) }哈希算法HashAlgorithm
enum { anonymous(0)rsa(1)dsa(2)ecdsa(3)(255) }签名算法SignatureAlgorithm
struct { HashAlgorithm hash----表明需要使用的哈希算法 SignatureAlgorithm signature----表明需要使用的签名算法 }签名和哈希算法SignatureAndHashAlgorithm
SignatureAndHashAlgorithmsupported_signature_algorithms2..-2----支持的签名算法 每个签名和哈希算法SignatureAndHashAlgorithm列表包含一个签名/哈希signature/hash对按照偏好排序。
注不是所有的哈希Hash和签名Signature都能配对
由于密码套件Cipher Suite中也定义了允许的签名算法但没有定义哈希算法因此在结合该扩展使用时会变得比较复杂参见2.4.2和2.4.3章节
如果客户端仅支持默认的哈希和签名算法则可能忽略签名算法signature_algorithm扩展。如果客户端不支持默认算法或支持其他签名/哈希signature/hash算法则必须发送签名算法扩展并列出接受的算法。
如果客户端没有发送签名算法扩展则服务端必须
如果协商的密钥交换算法为RSADHE_RSADH_RSARSA_PSKECDH_RSAECDHE_RSA其中之一则认为客户端发送了{ sha1rsa }如果协商的密钥交换算法为DHE_DSSDH_DSS其中之一则认为客户端发送了{ sha1dsa }如果协商的密钥交换算法为ECDH_ECDSAECDHE_ECDSA其中之一则认为客户端发送了{ sha1ecdsa }
TLS1.2之前的版本无法识别该扩展。
服务端不能发送该扩展但服务端必须支持接收该扩展。
当重用会话session时ServerHello中不能包含该扩展且server忽略ClientHello中的该扩展。
2.4.2 Server Certificate服务端证书 当两端需要使用基于证书的认证时服务端端必须发送证书Certificate消息。该消息总是紧跟在ServerHello消息之后。当选中的密码套件使用RSA或ECC基于椭圆曲线数学的公开密钥加密算法或ECDHE短暂椭圆曲线迪菲-赫尔曼算法算法时本消息的内容为服务端的签名证书和加密证书当选中的密码套件使用IBC基于标识的密码或IBSDH基于标识的超奇异迪菲-赫尔曼算法算法时本消息的内容为服务端表示和IBC公共参数用于客户端和服务端协商IBC公共参数。
证书消息会发送服务端的证书链certificate chain。证书必须符合协商出来的密钥交换算法和扩展。
证书消息结构如下
opaque ASN.1Cert1..-1struct { ASN.1Cert certificate_list0..-1----证书序列链签名证书在前加密证书在后详见① }数字证书Certificate
opaque ASN.1IBCParam1..-1struct { opaque ibc_id0..-1----服务端标识 ASN.1IBCParam ibc_parameter----IBC公共参数遵循ASN.1编码 }数字证书Certificate
①certificate_list这是一个证书序列链。发件人的证书必须位于列表的第一位。以下每个证书都必须直接验证其前面的证书。因为证书验证要求独立分发根密钥root keys因此在假设远程端必须已经拥有该证书才能在任何情况下对其进行验证的情况下指定根证书颁发机构root certificate authority的自签名证书可能会从链中省略。
客户端响应证书请求certificate request消息的消息类型和结构与服务端相同。当客户端没有合适的证书时可能不会发送证书。
证书必须是X509v3除非明确协商使用其他类型的证书证书类型必须能适用于已经确定的密钥交换算法。密钥交换算法和证书密钥类型的关系如下所示 TLS1.2密钥交换算法与证书密钥类型关系表密钥交换算法 | 证书key类型
--------------------|-------------------------------------------------------------------------------------------------
RSA/RSA_PSK | RSA公钥证书必须能够用于加密(当出现密钥使用(key esage)扩展时则必须设置密钥加密(keyEncipherment)位)
DHE_RSA/ECDHE_RSA | RSA公钥证书必须能够用于签名(当出现密钥使用(key esage)扩展时则必须设置数字签名(digitalSignature)位)
DHE_DSS | DSA公钥证书必须能够用于签名(结合服务端密钥交换(server key exchange)消息中出现的哈希算法)
DH_DSS/DH_RSA | Diffie-Hellman公钥(当出现密钥使用(key esage)扩展时则必须设置密钥协议(keyAggrement)位)
ECDH_ECDSA/ECDH_RSA | ECDH-capable公钥该公钥必须使用客户端支持的曲线(curve)和点(point)格式
ECDHE_ECDSA | ECDSA-capable公钥证书必须允许密钥用于使用将在服务端密钥交换(server key exchange)消息中使用的哈希| 算法进行签名。该公钥必须使用客户端支持的曲线(curve)和点(point)格式 GMTLS密钥交换算法与证书密钥类型关系表密钥交换算法 | 证书key类型
-----------------------|------------------------------------------RSA | RSA公钥必须使用加密证书中的公钥IBC | 服务端标识和IBC公共参数IBSDH | 服务端标识和IBC公共参数ECC | ECC公钥必须使用加密证书中的公钥ECDHE | ECC公钥必须使用加密证书中的公钥注ECDHElliptic Curve Diffie-Hellman具备椭圆曲线迪菲-赫尔曼ECDSAElliptic Curve Digital Signature Algorithm椭圆曲线数字签名算法
server_name和trusted_ca_keys扩展用于指导证书选择。
如果客户端提供了签名算法signature_algorithm扩展那么服务端提供的所有证书都必须使用该扩展中出现的哈希/签名hash/signature算法对进行数字签名请注意这意味着可以使用不同的签名算法例如使用DSA密钥签名的RSA密钥对包含一个签名算法的密钥的证书进行签名。这也是与TLS1.1不同的地方后者要求算法相同。注意这也意味着DH_DSS、DH_RSA、ECDH_ECDSA和ECDH_RSA密钥交换算法不限制用于签署证书的算法。固定DH证书可以使用扩展中出现的任何哈希/签名算法对进行签名。
如果服务端拥有多个证书客户端会根据上述标准以及其他标准如传输层端点、本地配置和首选项等挑选其中一个进行验证如果服务端只有一个证书则必须满足所有标准。
注有些证书使用当前无法与TLS一起使用的算法和/或and/or算法组合。例如不能使用具有RSASSA-PSS签名密钥的证书SubjectPublicKeyInfo中的id-RSASSA-PSS OID因为TLS没有定义相应的签名算法。
由于为TLS协议指定了指定新密钥交换方法的密码套件因此它们将包含证书格式和所需的编码密钥信息。
2.4.3 Server Key Exchange Message服务器密钥交换消息
该消息会在服务端证书server certificate之后发送且仅在服务端证书消息不足以提供用于客户端交换预主密钥premaster secret的数据时服务端才会发送服务端密钥交换ServerKeyExchange消息。密钥交换算法会发送该消息DHE_DSS、DHE_RSA、DH_anon
以下密钥交换方法发送服务端密钥交换消息是不合法的RSA、DH_DSS、DH_RSA
此消息传递密码信息以允许客户端传递预主密钥迪菲-赫尔曼Diffie-Hellman公钥客户端可以使用该公钥完成密钥交换结果是预主密钥或其他算法的公钥。
TLS 1.2 服务端密钥交换消息结构如下
enum {dhe_dssdhe_rsadh_anonrsadh_dssdh_rsa/* may be extended, e.g., for ECDH -- see [TLSECC] */} 密钥交换算法KeyExchangeAlgorithm
struct {opaque dh_p 1..-1----用于迪菲-赫尔曼运算的素数模opaque dh_g 1..-1----用于迪菲-赫尔曼操作的生成器opaque dh_Ys 1..-1----服务端迪菲-赫尔曼公共值mod p} 服务端DH参数ServerDHParams----短暂迪菲-赫尔曼参数Ephemeral DH parameters
struct { selectKeyExchangeAlgorithm { case dh_anon ServerDHParams params----服务端的密钥交换参数 case dhe_dss case dhe_rsa ServerDHParams params digitally-signed struct { opaque client_random [32] opaque server_random [32] ServerDHParams params } signed_params----对于非匿名密钥交换服务端的密钥交换参数上的签名 case rsa case dh_dss case dh_rsa struct {} } } 服务端密钥交换ServerKeyExchange
注signed_params的签名内容包含客户端和服务端的随机数以及交换算法的参数。
如果客户端提供了签名算法signature_algorithm扩展则该消息中必须使用客户端的签名算法扩展中出现的哈希/签名hash/signature算法对。但在实际使用中会出现不一致的情况如客户端提供了DHE_DSS密钥交换但在签名算法扩展中却忽略所有的DSA即扩展中忽略了密码套件cipher suite中定义的签名算法。为了能够正确地协商服务端必须在选择前校验所有的密码套件与签名算法扩展即密码套件中的签名算法与扩展不一致时。除此之外哈希/签名算法必须与服务端证书中的密钥key相匹配。RSA密钥可能与任何哈希算法兼容签名与哈希组合的方式受限于证书。 GMTLS 服务端密钥交换消息结构如下
enum { ECDHEECCIBSDHIBCRSA} 密钥交换算法KeyExchangeAlgorithm
struct { selectKeyExchangeAlgorithm { case ECDHE ServerECDHEParams params---服务端的密钥交换参数详见① digitally-signed struct { opaque client_random [32] opaque server_random [32] ServerECDHEParams params } signed_params case ECC digitally-signed struct { opaque client_random [32] opaque server_random [32] opaque ASN.1Cert1..-1 } signed_params case IBSDH ServerIBSDHParams params---服务端的密钥交换参数密钥交换参数格式参见SM9算法 digitally-signed struct { opaque client_random [32] opaque server_random [32] ServerIBSDHParams params } signed_params case IBC ServerIBCParams params---服务端的密钥交换参数密钥交换参数格式参见SM9算法 digitally-signed struct { opaque client_random [32] opaque server_random [32] ServerIBCParams params opaque IBCEncryptionKey[1024]---服务端的加密公钥长度为1024字节 } signed_params case RSA digitally-signed struct { opaque client_random [32] opaque server_random [32] opaque ASN.1Cert1..-1 } signed_params---详见② } } 服务端密钥交换ServerKeyExchange
①ServerECDHEParams服务端的密钥交换参数当使用SM2算法时交换的参数见GM/T 0009其中服务端的公钥不需要交换客户端直接从服务端的加密证书中获取。
②签名参数signed_params当密钥交换方法为ECDHE、IBSDH和IBC时签名参数是服务端对双方随机数和服务端密钥交换参数的签名当密钥交换方法为ECC和RSA时signed_params是服务端对双方随机数和服务端加密证书的签名。
2.4.4 Certificate Request证书请求 当非匿名服务端需要对客户端进行认证则应发送此消息要求客户端发送自己的证书。
该消息紧跟在服务端密钥交换ServerKeyExchange之后。
enum { rsa_sign(1)----包含RSA密钥的证书 dss_sign(2)----包含DSA密钥的证书 rsa_fixed_dh(3)----包含static DH密钥的证书详见① dss_fixed_dh(4)----包含static DH密钥的证书详见① rsa_ephemeral_dh_RESERVED(5) dss_ephemeral_dh_RESERVED(6) fortezza_dms_RESERVED(20) ecdsa_sign(64) ibc_params(80)(255)} 客户端证书类型ClientCertificateType
opaque DistinguishedName1..-1
struct { ClientCertificateType certificate_types1..-1----要求客户端提供证书类型的列表 SignatureAndHashAlgorithm supported_signature_algorithms-1 DistinguishedName certificate_authorities0..-1;} 证书请求CertificateRequest
①静态DH算法static DH静态DH算法是一种有一方的私钥是静态的也就是每次密钥协商的时候有一方的私钥都是一样的密钥交换算法。这种算法通常用于服务器方固定而客户端的私钥则是随机生成的。在静态DH算法中DH交换密钥只有客户端的公钥是变化的而服务端公钥是不变的。然而这种方法已经被废弃了因为它不具备前向安全性。随着时间延长黑客可能会截获海量的密钥协商过程的数据并利用这些数据暴力破解出服务器的私钥从而计算出会话密钥导致之前截获的加密数据被破解。
支持的签名算法supported_signature_algorithms服务端支持的哈希/签名hash/signature算法按偏好排序。
证书认证机构certificate_authorities即CA可接受的CA的可分辨名称distinguished names即DNDER编码格式。这些DN字段可能会指定一个根CAroot CA或从属CAsubordinate CA期望的DN因此该消息可以用来描述已知的根以及期望的授权范围。如果证书认证机构certificate_authorities列表为空则客户端可能会选择发送合适的客户端证书类型ClientCertificateType类型的证书。
证书类型certificate_types和支持的签名算法supported_signature_algorithms字段交互比较复杂证书类型在SSLv3版本中出现但仍然待确定它的大部分功能被supported_signature_algorithms取代。规则如下
客户端提供的证书必须使用支持的签名算法中定义的哈希/签名hash/signature算法进行签名
客户端提供的证书必须包含于证书类型兼容的密钥key如果密钥是一个签名密钥则该密钥必须能配合支持的签名算法中的哈希/签名算法使用。
由于历史原因一些客户端证书类型包含用于签名这些证书的算法。如在早期的TLS版本中rsa_fixed_dh表示使用RSA签名的证书且该证书包含一个static DH密钥。在TLS 1.2中该功能被支持的签名算法supported_signature_algorithms废弃证书类型不再限制用于签名证书的算法。如服务端发送的dss_fixed_dh类型的证书以及{{sha1dsa}{sha1rsa}}的签名类型客户端可能会回复带DH密钥的证书使用RSA-SHA1签名。 2.4.5 Server Hello Done服务端问候结束
服务端发送该消息用来表示完成了密钥交换key exchange消息的交互客户端可以进入密钥交换阶段。客户端在接收到服务端问候结束ServerHelloDone消息后会对服务端提供的证书进行校验如果证书校验通过则继续对服务端的问候Hello参数进行校验。 2.4.6 Client Certificate客户端证书
该消息是客户端接收到服务端问候结束ServerHelloDone消息之后发送的第一个消息且只在服务端请求证书时发送。如果没有合适的证书客户端也必须发送该消息消息中不包含任何证书即证书列表certificate_list长度为0。如果客户端没有发送任何证书服务端可能会握手(不对客户端进行认证)也可能会返回握手失败致命报警handshake_faiure fatal alert。如果证书链的某些地方不可接受如签名的CA不可知服务端可能会继续握手或返回致命报警fatal alert。
该消息会传递客户端的证书链服务端会使用该消息来校验证书认证CertificateVertify消息或采用非短暂迪菲-赫尔曼算法non-ephemeral Diffie-Hellman计算预主密钥premaster secret(non-ephemeral Diffie-Hellman)。证书必须匹配协商的密码套件cipher suite的密钥交换算法以及扩展。
证书类型必须是X509v3除非明确指出使用其他类型的证书。
客户端证书必须于证书请求CertificateRequest中的证书类型匹配。 TLS1.2密钥交换算法与证书密钥类型关系表密钥交换算法 | 证书key类型
--------------------------|-------------------------------------------------------------------------------------------------
rsa_sign | RSA公钥证书必须能够用于签名(结合证书验证(certificate verify)消息中的哈希签名(hashsignature)算法)
dss_sign | DSA公钥证书必须能够用于签名(结合证书验证(certificate verify)消息中的哈希签名(hashsignature)算法)
ecdsa_sign | ECDSA-capable公钥证书必须能够用于签名(结合证书验证(certificate verify)消息中的哈希签名| (hashSignature)算法)公钥必须使用服务端支持的曲线(curve)和点(point)格式
rsa_fixed_dh/dss_fixed_dh | Diffie_Hellman公钥必须与服务端密钥(server key)的预主密钥(premaster)相同
ECDH_ECDSA/ECDH_RSA | ECDH-capable公钥该公钥必须使用客户端支持的曲线(curve)和点(point)格式
rsa_fixed_ecdh/ | ECDH-capable公钥必须与服务端密钥(server key)的曲线(curve)相同必须使用服务端支持的点(point)格式
ecdsa_fixed_ecdh | GMTLS密钥交换算法与证书密钥类型关系表密钥交换算法 | 证书key类型
-----------------------|------------------------------------------RSA | RSA公钥必须使用加密证书中的公钥IBC | 服务端标识和IBC公共参数IBSDH | 服务端标识和IBC公共参数ECC | ECC公钥必须使用加密证书中的公钥ECDHE | ECC公钥必须使用加密证书中的公钥
如果证书请求Certificate Request消息中的证书认证机构certificate_authorities列表不为空则证书链中的一个证书应由其中一个列出的CA颁发。
证书必须使用可接受的哈希/签名算法对hash/signature algorithm pair进行签名这放宽了以前版本的TLS中对证书签名算法的限制。
2.4.7 Client Key Exchange Message客户端密钥交换消息
如果服务端请求客户端证书本消息紧跟于客户端证书Client Certificate消息之后否则本消息是客户端己收到服务端问候完成Server Hello Done消息后所发送的第一条消息。
发送该消息表示预主密钥premaster secret已经生成通过RSA加密后直接传输或通过Diffie-Hellman参数的传输来设置预主秘密该参数将允许每一方同意相同的预主秘密。
如果密钥交换算法使用RSA算法、ECC算法和IBC算法本消息中包含预主密钥该预主密钥由客户端产生采用服务端的加密公钥进行加密。当服务端收到加密后的预主密钥后利用相应的私钥进行解密获取所述预主密钥的明文。如果是IBC算法客户端利用获取的服务端标识和IBC公开参数产生服务端公钥。如果是RSA算法建议使用PKCS#1 版本1.5对RSA加密后的密文进行编码。若甫哦密钥交换算法使用ECDHE算法或IBSDH算法本消息中包含计算预主密钥的客户端密钥交换参数。
当客户端使用短暂的Diffie-Hellman指数时则此消息包含客户端的Diffie-Hellman公共值。如果客户端正在发送包含静态DH指数static DH exponent的证书即它正在进行fixed_DH客户端身份验证则此消息必须发送但必须为空。 struct { selectKeyExchangeAlgorithm { case rsa EncryptedPreMasterSecret----加密的预主密钥 case dhe_dss case dhe_rsa case dh_dss case dh_rsa case dh_anon ClientDiffieHellmanPublic----客户端的Diffie-Hellman公钥 }exchange_keys } 客户端密钥交换ClientKeyExchange GMTLS 服务端密钥交换消息结构如下
struct { selectKeyExchangeAlgorithm { case ECDHE Opaque ClientECDHEParams1..-1----客户端ECDHE参数详见① case IBSDH Opaque ClientIBSDHParams1..-1----使用IBSDH算法时客户端的密钥交换参数 case ECC opaque ECCEncryptedPreMasterSecret0..-1----使用ECC加密算法时用服务端加密公钥加密的预主密钥 case IBC opaque IBCEncryptedPreMasterSecret0..-1----使用IBC加密算法时用服务端加密公钥加密的预主密钥 case RSA opaque RSAEncryptedPreMasterSecret0..-1----RSA加密的预主密钥详见② }exchange_keys } 服务端密钥交换ServerKeyExchange
①ClientECDHEParams使用ECDHE算法时要求客户端发送证书。客户端的密钥交换参数当使用SM2算法时交换的参数见GM/T 0009。其结构如下struct { ECParameters curve_params----EC参数 ECPoint public----EC点} 客户端ECDHE参数ClientECDHEParams如果使用SM2算法第一个参数不校验。
②RSAEncryptedPreMasterSecret使用RSA加密算法时用服务端加密公钥加密的预主密钥。预主密钥的数据结构如下struct { ProtocolVersion client_version----客户端所支持的版本号。服务端要检查这个值是否与客户端问候ClientHello中所发送的值相匹配 opaque random[46]----46字节的随机数} 预主密钥PreMasterSecret
2.4.7.1 RSA-Encrypted Premaster Secret Message
RSA用于密钥协商和认证客户端会生成48字节的预主密钥premaster secret并将预主密钥使用服务端证书提供的公钥进行加密最后发送到服务端。该结构是客户端密钥交换ClientKeyExchange的变种且不是一个独立的消息。
struct { ProtocolVersion client_version----客户端所支持的版本号。服务端要检查这个值是否与客户端问候ClientHello中所发送的值相匹配 opaque random[46]----46字节的随机数} 预主密钥PreMasterSecret
struct { public-key-encrypted PreMasterSecret pre_master_secret----客户端用于生成主密钥master secret的随机值详见①} 加密预主密钥EncryptedPreMasterSecret ①pre_master_secret预主密钥PremasterSecret中的版本号由ClientHello.client_version提供而非协商的链路版本该设计用于防止回滚rollback攻击。不幸的是有些老的实现会使用协商出的版本号与这些实现交互时可能会失败。
客户端的实现中必须在预主密钥中发送正确的版本号。如果ClientHello.client_version为TLS1.1或更高服务端的实现中必须检查该版本号如果版本号为1.0或更早服务端可能会检查版本号也可能不检查。
TLS 服务端在加密预主密钥失败或遇到非期望的版本号时不能发送报警alert而应该使用一个随机生成的预主密钥进行握手。
公钥加密的数据是一个0~-1长度的不透明向量opaque vector因此客户端密钥交换ClientKeyExchange中使用RSA加密的预主密钥PreMasterSecret之前为2个字节的长度字段表示其可变长度大小。加密预主密钥EncryptedPreMasterSecret是客户端密钥交换的唯一数据。
2.4.7.2 Client Diffie-Hellman Public Value客户端DH公钥值
当客户端的数字证书certificate中没有出现迪菲-赫尔曼公钥Diffie-Hellman public的值时发送该消息是客户端密钥交换的变体。当数字证书中已经包含合适的迪菲-赫尔曼密钥Diffie-Hellman key用于固定DHfixed_dh客户端认证此时必须于发送客户端密钥交换client key exchange消息但必须为空。
2.4.8 Certificate Verify证书验证
该消息用于提供客户端证书的校验证明客户端拥有这些证书的私钥。仅在客户端证书client certificate由签名功能时发送除了包含fixed Diffie-Hellman参数的证书跟在客户端密钥交换client key exchange消息之后发送。
TLS1.2 Certificate Verify结构
struct { digitally-signed struct { opaque handshake_messages [handshake_messages_length] }} 证书验证CertificateVerify
这里的握手消息handshake_messages表示从客户端问候ClientHello开始的所有接收和发送的握手消息不包含本消息该消息级联了所有握手消息结构如下
struct { HandshakeType msg_type----握手类型handshake type uint24 length ----消息中的字节 selectHandshakeType { case hello_request : HelloRequest case client_hello : ClientHello case server_hello : ServerHello case certificate : Certificate case server_key_exchange : ServerKeyExchange case certificate_request : CertificateRequest case server_hello_done : ServerHelloDone case certificate_verify : CertificateVerify case client_key_exchange : ClientKeyExchange case finished : Finished } body } 握手Handshake
该实现会要求两端缓存该消息或计算出到接收到证书验证CertificateVerity为止的所有可能的哈希算法。服务端可以通过在证书请求CertificateRequest中设置限制来减小运算。
签名的哈希/签名算法hash/signature algorithm必须是证书请求消息中提供的。除此之外哈希/签名算法必须与客户端端的数字证书兼容。
GMSSL Certificate Verify结构
struct { Signature signature } 证书验证CertificateVerify
Signature 的结构如下
enum { rsa_sha1rsa_sm3ecc_sm3 ibs_sm3} 签名算法SignatureAlgorithmstruct { selectSignature Algorithm{ case rsa_sha1 : digitally-signed struct { opaque sha1_hash [20] } case rsa_sm3 : digitally-signed struct { opaque sm3_hash [32] } case ecc_sm3 : digitally-signed struct { opaque sm3_hash [32] } case ibs_sm3 : digitally-signed struct { opaque sm3_hash [32] } } body } 签名Signature
sm3_hash和sha1_hash是指哈希运算的结果运算的内容是值客户端问候ClientHello开始直到本消息为止不包括本消息的所有握手有关的消息加密证书要包在签名计算中包括握手消息的类型和长度域。
2.4.9 Finished结束
服务端和客户端各自在密码规格变更ChangeCipherSpec消息之后发送本消息用于验证密钥交换过程是否成功并校验握手过程的完整性。
本消息用本次握手过程协商出的算法和密钥保护。
本消息的接收方必须校验消息内容的正确性。一旦一方发送了握手结束消息并且接收到了对方握手结束消息并通过校验。就可以使用该连接进行数据安全传输。
struct { opaque verify_data [ verify_data_length ]----校验数据详见①} 结束Finished
①verify_data该数据产生方法如下PRF(master_secretfinished_labelHash( handshake_messages )) [0..verify_data_length-1] 在旧版本中的TLSverify_data为12字节octets当前版本则却决于使用的密码套件。任何没有明确指定验证数据长度verify_data_length的默认为12字节。
1 octet 8 bit
finished_label客户端发送的结束消息相关的字符串为“client finished”服务端发送的为“server finished”
Hash表示握手消息的哈希该哈希与伪随机算法PRF使用的哈希相同。密码套件定义的PRF必须定义用于结束计算的Hash若为GMSSL则哈希算法为SM3
handshake_messages指自客户端问候Client Hello开始直到本消息为止不包括本消息、密码规格变更消息ChangeCipherSpec的所有与握手有关的消息包括握手消息的类型和长度域。不包含记录Record类型、问候请求HelloRequest的消息。
在握手过程中如果没有在合适的时机处理结束Finished消息则返回致命fatal错误。
A.5 The Cipher Suite密码套件
本节定义了客户端问候ClientHello和服务端问候ServerHello使用的密码套件cipher suite。TLS初始化的密码套件为TLS_NULL_WITH_NULL_NULL但不能使用该值进行协商(没有提供任何保护)
CipherSuite TLS_NULL_WITH_NULL_NULL { 0x00,0x00 };
如下密码套件需要服务端提供用于密钥交换的RSA证书。服务端可能会在证书请求CertificateReuqest中请求具有签名的能力或功能的证书signature-capable certificate。
CipherSuite TLS_RSA_WITH_NULL_MD5 { 0x00,0x01 };
CipherSuite TLS_RSA_WITH_NULL_SHA { 0x00,0x02 };
CipherSuite TLS_RSA_WITH_NULL_SHA256 { 0x00,0x3B };
CipherSuite TLS_RSA_WITH_RC4_128_MD5 { 0x00,0x04 };
CipherSuite TLS_RSA_WITH_RC4_128_SHA { 0x00,0x05 };
CipherSuite TLS_RSA_WITH_3DES_EDE_CBC_SHA { 0x00,0x0A };
CipherSuite TLS_RSA_WITH_AES_128_CBC_SHA { 0x00,0x2F };
CipherSuite TLS_RSA_WITH_AES_256_CBC_SHA { 0x00,0x35 };
CipherSuite TLS_RSA_WITH_AES_128_CBC_SHA256 { 0x00,0x3C };
CipherSuite TLS_RSA_WITH_AES_256_CBC_SHA256 { 0x00,0x3D };
如下密码套件用于。DH表示服务端的证书包含CA签名的迪菲-赫尔曼算法Diffie-Hellman参数。DHE表示短暂迪菲-赫尔曼算法ephemeral Diffie-Hellman此时使用具有签名的能力或功能的证书signature-capable certificate该证书也被CA签名签名迪菲-赫尔曼算法参数。服务端使用的签名算法在密码套件的DHE名字之后。
CipherSuite TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA { 0x00,0x0D };
CipherSuite TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA { 0x00,0x10 };
CipherSuite TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA { 0x00,0x13 };
CipherSuite TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA { 0x00,0x16 };
CipherSuite TLS_DH_DSS_WITH_AES_128_CBC_SHA { 0x00,0x30 };
CipherSuite TLS_DH_RSA_WITH_AES_128_CBC_SHA { 0x00,0x31 };
CipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA { 0x00,0x32 };
CipherSuite TLS_DHE_RSA_WITH_AES_128_CBC_SHA { 0x00,0x33 };
CipherSuite TLS_DH_DSS_WITH_AES_256_CBC_SHA { 0x00,0x36 };
CipherSuite TLS_DH_RSA_WITH_AES_256_CBC_SHA { 0x00,0x37 };
CipherSuite TLS_DHE_DSS_WITH_AES_256_CBC_SHA { 0x00,0x38 };
CipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA { 0x00,0x39 };
CipherSuite TLS_DH_DSS_WITH_AES_128_CBC_SHA256 { 0x00,0x3E };
CipherSuite TLS_DH_RSA_WITH_AES_128_CBC_SHA256 { 0x00,0x3F };
CipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 { 0x00,0x40 };
CipherSuite TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 { 0x00,0x67 };
CipherSuite TLS_DH_DSS_WITH_AES_256_CBC_SHA256 { 0x00,0x68 };
CipherSuite TLS_DH_RSA_WITH_AES_256_CBC_SHA256 { 0x00,0x69 };
CipherSuite TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 { 0x00,0x6A };
CipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 { 0x00,0x6B };
服务端可以向客户端请求具有签名的能力或功能的证书signature-capable certificate或DH证书来对客户端进行认证。客户端提供的所有Diffie-Hellman证书必须使用服务端提供或生成的参数
如下密码套件用于在两端都没有认证情况下的匿名Diffie-Hellman交互。该模式容易遭中间人攻击因此使用场景比较有限。该模式不能用于TLS1.2的实现中除非明确指出允许匿名密钥交互。
CipherSuite TLS_DH_anon_WITH_RC4_128_MD5 { 0x00,0x18 };
CipherSuite TLS_DH_anon_WITH_3DES_EDE_CBC_SHA { 0x00,0x1B };
CipherSuite TLS_DH_anon_WITH_AES_128_CBC_SHA { 0x00,0x34 };
CipherSuite TLS_DH_anon_WITH_AES_256_CBC_SHA { 0x00,0x3A };
CipherSuite TLS_DH_anon_WITH_AES_128_CBC_SHA256 { 0x00,0x6C };
CipherSuite TLS_DH_anon_WITH_AES_256_CBC_SHA256 { 0x00,0x6D };
目前使用最多的密码套件TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256解析如下
ECDHE为密钥交互算法RSA为签名算法AES_123_GCM为使用GCM模式下的128位AEAD加密算法SHA256为创建消息摘要的MAC算法
密码套件的详细定义可以参考Cipher suite definitionsTLS密码套件cipher suite-CSDN博客Cipher suite definitions
B. 术语表
Advanced Encryption Standard (AES)高级加密标准对称加密算法块加密。TLS当前仅支持128-和256-位长度的AES
authenticated encryption with additional data (AEAD)使用附加数据进行身份验证加密对称加密算法
block_cipher块加密作用于一组比特位的纯文本算法之前使用64bit目前使用128bit通用的块大小
cipher block chaining (CBC)密文分组链接模式在每个纯文本块加密前会于前面一个纯文本第一个块与初始化向量-IV 进行运算进行异或运算。解码时首先进行解密再与前面文本块进行异或运算 Digital Signature Standard (DSS)数字签名标准数字签名算法
digital signature数字签名使用公钥和单向哈希函数来产生签名数据。
Data Encryption StandardDES数据加密标准普遍使用的对称加密算法
Initialization Vector (IV)初始向量当块加密使用CBC时首个文本块会与IV进行异或运算。
client write key用于加密客户端的数据
client write MAC key用于认证客户端的数据
Message Authentication Code (MAC)消息认证码单向哈希处理的数据生成消息摘要。
master secret主密钥用于生成用于数据加密和完整性校验的会话密钥
RC4流加密。
session会话定义了可与多个链接共享的安全参数。用来避免为每个链接进行安全参数协商造成的消耗。
stream cipher流加密将一个密钥加密为密钥流keystream并与文本进行异或运算。
F.1.1.2 RSA Key Exchange and AuthenticationRSA密钥交换和身份验证
使用RSA密钥交换key exchange和服务端认证可以同时进行。服务端的证书中包含了公钥。注意使用静态的RSA密钥可能导致该静态密钥保护的所有会话session失效。
客户端验证完服务端的证书后会使用证书中的公钥对预主密钥pre_master_secret加密。服务端成功解密预主密钥之后会并处理结束Finished消息之后服务端认为客户端对服务端的认证成功。
当使用RSA进行密钥协商时客户端通过证书验证certificate verify消息进行认证。客户端会对所有处理的握手消息进行签名这些握手消息包括服务端证书该消息使用的签名与服务端相关以及服务端问候随机数ServerHello.random该数值与当前握手交互使用的签名相关。
F.1.1.3 Diffie-Hellman Key Exchange with Authentication带身份验证的迪菲-赫尔曼密钥交换
当使用Diffie-Hellman密钥交换时服务端可以提供包含固定DHfixed Diffie-Hellman参数的证书或使用服务端密钥交换ServerKeyExchange消息发送一系列使用DSA或RSA签名的临时DH参数。这些临时参数在签名前会使用问候随机数hello.random进行哈希用以防止攻击者使用老参数进行攻击。其他场景下客户端可以通过验证证书和签名来确保该消息来自服务端。
如果客户端有包含固定DHfixed Diffie-Hellman参数的证书该证书中的信息可以用于完成密钥交互。这种情况下客户端和服务端会生成相同的DH结果即预主密钥pre_master_secret。为了防止预主密钥过长地滞留在内存中在完成它的计算后应该尽快将其转化为主密钥master secret。客户端的DH参数必须兼容服务端的DH参数。
如果客户端使用DSA或RSA证书或其未被认证它会在客户端密钥交换clientKeyExchange消息中发送临时的参数后续可能使用证书验证certificate verify消息对其进行认证。
如果使用DH密钥对进行多个握手由于客户端和服务端都拥有一个包含固定DHfixed Diffie-Hellman密钥对的证书或服务端重用DH密钥需要注意方式子群攻击Subgroup attack。
小型的子群攻击攻击可以通过使用DHE密码套件DHE cipher suite并未每个握手生成新的DH私钥来解决。 由于TLS允许服务端提供任意的DH组DH groups客户端应该对DH组进行校验与本地策略比较。
F.1.3 Detecting Attacks Against the Handshake Protocol检测针对握手协议的攻击
攻击者可能会通过握手消息来修改两端使用的加密算法。因此攻击者必须修改握手过程中的一个或多个消息当发生这种情况的时候客户端和服务端会计算出不同的哈希值消息摘要改变此时两端不会接受对端的结束Finished消息。由于无法获取主密钥master_secret攻击者无法修改结束Finished消息这样就可以发现攻击。
F.1.4 Resuming Sessions重用会话 当需要重用会话session来建立链接时会使会话的主密钥master secret生成新的ClientHello.random和SeverHello.random。
只有在客户端和服务端双方同意的情况下才能重用会话。如果一端拒绝或证书过期或被撤销此时应该进行完整的握手。
F.2 Protecting Application Data保护应用程序数据
使用使用ClientHello.random和ServerHello.random生成的主密钥master secret用于生成用于数据加密和完整性校验的会话密钥
master_secret PRF(pre_master_secret, master secret,ClientHello.random ServerHello.random)
使用MAC保护发送的数据。为了方式消息重复和篡改使用MAC key序列号消息长度消息内容以及2个固定字符串生成MAC。消息类型字段用来确保该消息服务于某个TLS记录Record层。序列号用来确保能够感知到消息的删除和重复。由于序列号为64位长度可以保证数值不会被溢出。由于使用了独立的消息认证码密钥MAC key一方的消息不能插入到另一方的输出中插入后MAC会错误。类似地由于客户端写密钥clientwrite keys和服务端写密钥server write keys是独立的因此只会用到一次流加密密钥。
MAC(MAC_write_key, seq_num TLSCompressed.type TLSCompressed.version TLSCompressed.length TLSCompressed.fragment);
如果攻击者获取了加密密钥那么所有的加密消息都会被读取。类似地泄露消息认证码密钥会导致消息篡改message-modification攻击。由于MAC是加密的消息篡改同时也需要突破对MAC的加密算法。
F.4 Security of Composite Cipher Modes复合密码模式的安全性
TLS使用密码套件cipher suite中定义的对称加密和认证函数对传输的应用数据进行保护目的是防止网络攻击造成数据的篡改。
当前最健壮的方式称为加密再认证encrypt-then-authenticate首先对数据进行加密然后对密文使用MAC计算消息摘要。该方法使用加密和MAC函数保证数据的加密防护和完整性。前者用于防止针对明文的攻击信息泄露后者用于防止针对消息的攻击链路攻击。其次TLS使用其他方式称为认证再加密authenticate-then-encrypt首先先对明文使用MAC然后对整个数据明文MAC进行加密。这种方式已经通过使用特定加密函数和MAC函数的组合证明了其安全能力但通常不能保证安全。特别地在使用当前非常好的加密函数再结合某个MAC函数的情况下无法很好地防御主动攻击。 目前已经证明在某些情况下更加适合使用认证再加密。其中一种情况是使用流加密时消息MAC的长度不可知的情况另一种时在CBC模式下使用块加密。这些情况下安全能力可以通过一方对明文MAC使用CBC加密以及对每个明文和MAC使用(新的独立的不可预测的IV体现出来。
TLS使用块加密HMAC流加密HMAC以及AEAD(Authenticated-Encryption With Additional data附加数据的身份验证加密)来保证数据的完整和安全。TLS1.3中废除了除AEAD外的加密方式
注
实际中基本不使用流加密方式密钥交换key exchange的目的是生成预主密钥pre_master_secret最终生成主密钥master secret通过结束Finished来校验预主密钥的正确性。数字签名过程为发送端首先使用哈希算法生成消息摘要然后使用签名算法生成数字签名接收端为上述逆过程 参考
https://www.cnblogs.com/charlieroro/p/10714783.html
【精选】《商用密码应用与安全性评估》第一章 密码基础知识-小结_商用密码应用安全性评估-CSDN博客
RFC 5246 TLS1.2
中华人民共和国密码行业标准 GM/T 0024-2014 SSL VPN 技术规范
百度百科相关词条
TLS密码套件cipher suite-CSDN博客
IBM Documentation
