TLS协议分析 (六) handshake协议扩展 im

5.11. handshake — Finished
在 ChangeCipherSpec 消息之后，应该立即发送 Finished 消息，来确认密钥交换和认证过程已经成功了。ChangeCipherSpec 必须在其它握手消息和 Finished 消息之间。
Finished 消息是第一条用刚刚协商出来的参数保护的消息。接收方必须确认Finished消息的内容是正确的。一旦某一方发送了，并且确认了对端发来的Finished消息，就可以开始在连接上发送和接收应用数据了。
消息结构：

struct { opaque verify_data[verify_data_length]; } Finished; verify_data PRF(master_secret, finished_label,Hash(handshake_messages)) [0..verify_data_length-1]; finished_label 对客户端发的Finished消息来说，固定是字符串 "client finished". 对服务器发的Finished消息来说，固定是字符串 "server finished".1.2.3.4.5.6.7.8.9.10.11.

Hash表示握手消息的hash。hash函数是前文 PRF 的hash 函数。或者 CipherSuite 规定的用于 Finished 计算的hash函数。
在TLS的之前版本中，verify_data 总是 12 字节。在TLS 1.2中，这取决于CipherSuite。如果CipherSuite没有显式规定 verify_data_length ，就当成12字节处理。将来的CipherSuite可能会规定别的长度，但是不能小于12字节。
【TLS协议分析 (六) handshake协议扩展】Finished 消息必须跟在 ChangeCipherSpec 消息之后，如果顺序错乱，就是 fatal error.
handshake_message 的内容包含从 ClientHello开始，直到本条Finished之前的所有消息，只包含handshake层的消息体，不包含record层的几个消息头字段。包括CertificateVerify 消息。同时，对客户端和服务器来说，handshake_message 的内容不同，后发送者必须包含前发送者的 Finished 消息。
注意：ChangeCipherSpec 消息，alert，和其它的record 类型不是握手消息，不包含在 hash计算中。同时，HelloRequest 消息也不算在内。
5.12. handshake — NewSessionTicket
SessionTicket 定义在 RFC5077 标准里面，2008年发布。
SessionTicket是一种不需要服务器端状态的，恢复TLS session的方式。
SessionTicket可以用于任何CipherSuite。 TLS 1.0, TLS 1.1, TLS 1.2 都适用。
在下面这些场景下，尤其有用：
用户量巨大，session id的方式耗费服务器内存过多
服务器希望长时间缓存session
服务器有多台，不希望服务器间有共享状态
服务器内存不足
客户端在 ClientHello中设置一个 SessionTicket 扩展来标识自己支持 SessionTicket。如果客户端本地没有存之前收到的ticket，就把这个扩展设为空。
如果服务器希望使用 SessionTicket 机制，服务器把本地的 session 状态存入一个ticket中，ticket会被加密，并被MAC保护，无法篡改，加密和算MAC用的key只有服务器知道。
加密并MAC过的ticket用 NewSessionTicket 消息分发给客户端，NewSessionTicket 消息应该在 ChangeCipherSpec 消息之前，在服务器验证通过客户端的Finished消息之后发送。

ClientServer ClientHello (empty SessionTicket extension)-------> ServerHello (empty SessionTicket extension) Certificate* ServerKeyExchange* CertificateRequest* <--------ServerHelloDone Certificate* ClientKeyExchange CertificateVerify* [ChangeCipherSpec] Finished--------> NewSessionTicket [ChangeCipherSpec] <--------Finished Application Data<------->Application DataFigure 1: Message flow for full handshake issuing new session ticket1.2.3.4.5.6.7.8.9.10.11.12.13.14.15.16.17.18.19.20.

客户端把收到的ticket和master secret等其它与当前session有关的参数一起，缓存起来。
单客户端希望恢复会话时，就把ticket包含在 ClientHello 的 SessionTicket 扩展中发给服务器。
服务器收到后，解密ticket，算MAC确认ticket没有被篡改过，然后从解密的内容里面，获取session 状态，用来恢复会话。如果服务器成功地验证了ticket，可以在 ServerHello 之后返回一个 NewSessionTicket 消息来更新ticket。
显然，这种情况下，相比完整握手，可以省掉1个RTT。如下图：

ClientServer ClientHello (SessionTicket extension)--------> ServerHello (empty SessionTicket extension) NewSessionTicket [ChangeCipherSpec] <--------Finished [ChangeCipherSpec] Finished--------> Application Data<------->Application Data Figure 2: Message flow for abbreviated handshake using new session ticket1.2.3.4.5.6.7.8.9.10.11.12.13.

如果服务器不能，或者不想使用客户端发来的ticket，那服务器可以忽略ticket，启动一个完整的握手流程。
如果服务器此时不希望下发新的ticket，那就可以不回复 SessionTicket 扩展，或者不回复 NewSessionTicket 消息。
此时除了 ClientHello里面的 SessionTicket扩展，就和一般的TLS流程一样了。
如果服务器拒绝收到的ticket，服务器可能仍然希望在完整的握手之后，下发新的ticket。
此时流程和全新 ticket 生成下发的区别，就是ClientHello的SessionTicket不是空的。
NewSessionTicket 消息
服务器在握手过程中，发ChangeCipherSpec之前发送NewSessionTicket消息。
如果服务器在ServerHello中包含了一个SessionTicket扩展，那就必须发送NewSessionTicket消息。
如果服务器没有包含SessionTicket扩展，那绝对不能发送NewSessionTicket消息。
如果服务器在包含了SessionTicket扩展之后，不想发送ticket，那可以发送一个长度为0的NewSessionTicket消息。
在完整握手的情况下，客户端必须在确认服务器的Finished消息正确之后，才能认为NewSessionTicket 里面的ticket合法。
服务器可以NewSessionTicket消息中更新 ticket。
ticket_lifetime_hint 字段包含一个服务器的提示，提示客户端本ticket应该存多长时间就失效。单位是秒，网络字节序。当时间到期时，客户端应该删掉ticket和关联的状态。客户端也可以提前删除。服务器端也可以提前认为ticket失效。

struct { uint32 ticket_lifetime_hint; opaque ticket<0..2^16-1>; } NewSessionTicket; 1.2.3.4.

SessionTicket 和 Session ID 之间的关系比较繁琐。感兴趣的自行去看RFC吧。
对于客户端来说，ticket就是一块二进制buffer，客户端并不管里面的内容。所以ticket具体怎么加密加MAC服务器可以为所欲为，无需顾及客户端的感受。
RFC5077中推荐了一种ticket的加密保护方法：
服务器使用2个key，一个 aes-128-cbc的key，一个 HMAC-SHA-256 的key。
ticket的格式像这样：

struct { opaque key_name[16]; opaque iv[16]; opaque encrypted_state<0..2^16-1>; opaque mac[32]; } ticket; 1.2.3.4.5.6.

其中，key_name 用来标识一组key，这样服务器端就可以使用多组key。
加密过程，首先随机生成IV，然后用 aes-128-cbc 加密 session 的序列化结果，
然后用 HMAC-SHA-256 对 key_name,IV,encrypted_data 的长度（2字节），encrypted_data 计算MAC。
最好把各个字段填入上面ticket结构体。
显然，此处是 Encrypt-then-MAC的方式，是最安全的。
实际在openssl 中的session，用asn1格式序列化保存了下面这些字段：

typedef struct ssl_session_asn1_st { ASN1_INTEGER version; ASN1_INTEGER ssl_version; ASN1_OCTET_STRING cipher; ASN1_OCTET_STRING master_key; ASN1_OCTET_STRING session_id; ASN1_OCTET_STRING session_id_context; ASN1_INTEGER time; ASN1_INTEGER timeout; ASN1_INTEGER verify_result; ASN1_OCTET_STRING tlsext_hostname; ASN1_INTEGER tlsext_tick_lifetime; ASN1_OCTET_STRING tlsext_tick; } SSL_SESSION_ASN1; 1.2.3.4.5.6.7.8.9.10.11.12.13.14.

6. ChangeCipherSpec 协议 ChangeCipherSpec用来通知对端，开始启用协商好的Connection State做对称加密，内容只有1个字节。
这个协议是冗余的，在TLS 1.3里面直接被删除了。
changeCipherSpec协议抓包：

文章图片

7. Alert 协议一种返回码机制，简单

enum { warning(1), fatal(2), (255) } AlertLevel; struct { AlertLevel level; AlertDescription description; } Alert; 1.2.3.4.5.6.

其中level是等级，不同等级要求不同的处理。
其中有一种：close_notify，用来通知对端，我不会再发送更多数据了。这个可以让对端主动close fd，这样可以减少我方tcp timewait状态的socket 量。
alert协议：

文章图片

8. application data协议 application data协议，就是把应用数据直接输入record层，做分段，算MAC，加密，传输。
抓包举例如下：

文章图片

? 本文转自微信后台团队,如有侵犯,请联系我们立即删除
OpenIMgithub开源地址：
https://github.com/OpenIMSDK/...
OpenIM官网： https://www.rentsoft.cn
OpenIM官方论坛：https://forum.rentsoft.cn/
更多技术文章：
开源OpenIM：高性能、可伸缩、易扩展的即时通讯架构
https://forum.rentsoft.cn/thr...
【OpenIM原创】简单轻松入门一文讲解WebRTC实现1对1音视频通信原理
https://forum.rentsoft.cn/thr...
【OpenIM原创】开源OpenIM：轻量、高效、实时、可靠、低成本的消息模型
https://forum.rentsoft.cn/thr...