本博客是对下面博客连接上的原文进行梳理+自己在其他方面资料做个整理
一个正常的TLS1.3 握手顺序是按照下面的顺序进行：
- 客户端发送Client Hello（CH）报文，包含有关密钥协商以及其他与TLS连接建立有关的扩展给服务端。
- 服务端发送Server Hello（SH）报文，包含有关密钥协商的扩展返还给客户端，双方根据CH和SH的协商结果可以得出密钥材料。
- 如果客户端发送的CH报文不满足服务端的需要（如：不包含服务端支持的DH组件），服务端会发送一个Hello Retry Request报文给客户端，要求客户端重新发送符合要求的CH报文。
- 利用密钥材料和前两个报文的哈希值，使用HKDF可以计算出一个handshake_key，此后握手阶段的信息受该密钥保护。
- 服务端发送Encypted Extension（EE）报文，包含其他与密钥协商无关的扩展数据给客户端。
- 如果使用公钥证书进行身份认证，服务端发送Certificate报文（传递自己的证书信息），和Certificate Verify(CV)报文（使用自己的证书私钥对之前的报文进行HMAC签名证明自己持有该证书）给客户端。
- 如果需要对客户端身份进行认证，服务端还需要发送Certificate Request（CR）报文给对方请求客户端发送证书。
- 服务端发送Finished报文。表明服务端到客户端信道的握手阶段结束，理论上不得再由该信道发送任何握手报文。
- 如果客户端收到了服务端的CR报文，返回自己的Certificate报文和CV报文。
- 客户端发送Finished报文，表明握手阶段结束，可以正式开始会话通讯。Finished报文使用会话密钥对上述所有握手信息进行HMAC签名，校验签名可以检验握手阶段的完整性，也可以验证双方是否协商出了一致的密钥。
TLS1.3最大的特点就是对不同的报文使用多种不同的秘钥，TLS1.2中只使用两种秘钥，一个事用于完整性校验，另一个是用于报文加密，同一个连接中不同方向的加密秘钥不一样，TLS1.3使用AEAD机制不再使用MAC_key来进行完整性校验，同时由于其他各种用途的加密需要，TLS1.3的实施过程使用一下几种key：
handshake_key early_traffic_key resumption_key exporter_key（导出秘钥，用户自定义的其他用途）
这些秘钥都是由之前协商的秘钥材料计算而出，区别在于HKDF的计算次数不同，HKDF计算使用的哈希值不同，以会话秘钥application_key为例子，以整个握手阶段的报文作为输入，计算四次HKDF导出最终使用的秘钥，同时，当加密的报文长度达到一定的长度的时候，双方发送的KU报文重新计算application_key
数据发送出去之后，recod层会在密报文头部加上一小段的明文信息来标识解密后明文的长度信息，对方的让recod 层收到消息之后，通过逆过程解密密文后转发给上层协议，
同时TLS1.3协议版本允许在末尾添加八字节整数倍的全为0的二进制数据，对方收到该消息之后，解密从末尾开始去掉0 ，当搜索到第一个不全为0的八字节的时候结束。
总的概括： TLS1.3协议版本 使用的更加 复杂额秘钥导出过程，增强了最终使用秘钥的安全性，同时简化了所使用的加密秘钥，删除了RC4 3DES SHA1 AES-CBC 等加密算法，删除了加密前压缩，重新协商等具有的漏洞，精简了协议 内容，
在TLS1.2中记录协议record，占据一个TLS连接的绝大数的数据流量，
分片，逆向是重组
生成序列号，为每个数据块生成唯一编号，防止被重放或被重排序
压缩，可选步骤，使用握手协议协商出的压缩算法做压缩
加密，使用握手协议协商出来的key做加密/解密
算HMAC，对数据计算HMAC，并且验证收到的数据包的HMAC正确性
发给tcp/ip，把数据发送给 TCP/IP 做传输(或其它ipc机制)。
下面对TLS协议秘钥协商的过程的分析
基于RSA握手和秘钥交换的客户端验证服务器为示例如下
下面是上网的握手过程的时序图
下面对上面的协商过程解释：
（1）Client-Hello 客户端发送请求，以明文传输信息，包含版本信息，加密候选列表，候选算法列表，随机数，扩展字段等信息，
客户端支持加密套件 cipher suite列表，注意，每一个加密条件对应前面TLS原理中的四个功能的组合，认证算法Au（身份验证），秘钥交换算法 （keyExchange 秘钥协商），对称加密算法Enc(信息加密)，信息摘要MAc（完整性验证）。在TLS1.2 中支持压缩算法，Client-Hello 中包含压缩算法列表，用于后后续的压缩阶段使用。另外还有随机数 randmo_c 用于后续秘钥的生成。最后还包括扩展字段 extension 支持协议相关算法的参数以及其他辅助信息。
（2）Server-Hello +Server_cerficate+ server_hello_done
server_hello 服务端返回协商的信息结果，包括使用的协议版本，选择的加密套件，以及使用的压缩算法 随机数（随机数用于后续的秘钥协商）
server_certificate 服务器端配置对应的证书链，用于身份验证和秘钥交换
server_Hellodone 通知客户端 server_hello 信息发送结束
（3）证书校验
客户端证书的合法性，如果验证通过才会进行后续的通信，合法性验证主要包括下面的环节：
证书链的可信任、证书是否吊销、证书是否在有效期内、域名，核实证书的域名是否是当前访问的域名相匹配。
（4）Client_key_excahage+ change_chiper_spec+encrypted_handshake_message
client_key_exchage 合法性验证通过之后，客户端计算产生随机数 pre-master ,并用证书的Pk 加密发送给服务器。
当客户端获取全部的计算协商秘钥需要的信息： 两个明文随机数 Radmon_c 和 Radmon-S 和自己计算产生的 pre-master 计算得到协商秘钥
enc_key=fuc(randmo_C,randmo_s,pre-Master)
change_chiper_spec,客户端通知服务器后续的通信都采用协商的通信加密秘钥和加密算法进行加密通信，
encrypted_handshake_message 结合前面所有的通信参数的hash值和其相关的信生成一段数据，采用协商的 session-secret 与算法进行加密之后发送给服务器用于数据与握手验证
5）Change_ciper_spec +encrypted_handshake_message
服务器使用私钥解密加密的per-master 数据，基于之前交换的两个明文随机书卷 Random_c 和 random_S 计算协商秘钥 enc_key=fuc(randmo_C,randmo_s,pre-Master)
计算之前所接受信息的hash 值，然后解密客户端发送 encrypted_handshake_message 验证数据和秘钥的正确性
encrypted_handshake_message验证完之后，服务器结同样发送 change_cipher_spec以告知客户端后续的通信采用协商秘钥与算法加密通信
encrypted_handshake_message服务器结合当前所有的通信参数生成一段数据并采用协商秘钥 session secret 与算法加密并发到客户端
（6）结束握手
客户端计算所有接受到的信息的hash值，并采用协商秘钥解密 encrypted_handshake_message 验证服务器发送的数据和秘钥，验证通过则完成握手。
（7）加密通信
开始使用协商秘钥与算法进行加密通信
对TLS协议进行形式化分析的思维导图
下面是对 论文形式化工具Scyther 优化实例分析的关于 TSL的整理
作者对TLS的形式化过程中的涉及到如何将角色模型转化成安全模型的并没有说明， 只是将TSL.spdl执行的结果 截图，然后说明TLS是存在安全隐患的，分别在强安全模型和DY模型下面进行了低手的攻击测试
另外， 作者对攻击的轨迹路径没有说明。对存在的多种的轨迹路径只是截了一张图来简单的说明 确实存在安全的问题
Client Hello
握手第一步是客户端向服务端发送 Client Hello 消息，这个消息里包含了一个客户端生成的随机数 Random1、客户端支持的加密套件（Support Ciphers）和 SSL Version 等信息。通过 Wireshark 抓包，我们可以看到如下信息：
Wireshark 抓包的用法可以参考这篇文章
Server Hello
第二步是服务端向客户端发送 Server Hello 消息，这个消息会从 Client Hello 传过来的 Support Ciphers 里确定一份加密套件，这个套件决定了后续加密和生成摘要时具体使用哪些算法，另外还会生成一份随机数 Random2。注意，至此客户端和服务端都拥有了两个随机数（Random1+ Random2），这两个随机数会在后续生成对称秘钥时用到。
Certificate
这一步是服务端将自己的证书下发给客户端，让客户端验证自己的身份，客户端验证通过后取出证书中的公钥。
Server Key Exchange
如果是DH算法，这里发送服务器使用的DH参数。RSA算法不需要这一步。
Certificate Request
Certificate Request 是服务端要求客户端上报证书，这一步是可选的，对于安全性要求高的场景会用到。
Server Hello Done
Server Hello Done 通知客户端 Server Hello 过程结束。
Certificate Verify
客户端收到服务端传来的证书后，先从 CA 验证该证书的合法性，验证通过后取出证书中的服务端公钥，再生成一个随机数 Random3，再用服务端公钥非对称加密 Random3生成 PreMaster Key。
Client Key Exchange
上面客户端根据服务器传来的公钥生成了 PreMaster Key，Client Key Exchange 就是将这个 key 传给服务端，服务端再用自己的私钥解出这个 PreMaster Key 得到客户端生成的 Random3。至此，客户端和服务端都拥有 Random1 + Random2 + Random3，两边再根据同样的算法就可以生成一份秘钥，握手结束后的应用层数据都是使用这个秘钥进行对称加密。为什么要使用三个随机数呢？这是因为 SSL/TLS 握手过程的数据都是明文传输的，并且多个随机数种子来生成秘钥不容易被暴力破解出来。客户端将 PreMaster Key 传给服务端的过程如下图所示：
Change Cipher Spec(Client)
这一步是客户端通知服务端后面再发送的消息都会使用前面协商出来的秘钥加密了，是一条事件消息。
Encrypted Handshake Message(Client)
这一步对应的是 Client Finish 消息，客户端将前面的握手消息生成摘要再用协商好的秘钥加密，这是客户端发出的第一条加密消息。服务端接收后会用秘钥解密，能解出来说明前面协商出来的秘钥是一致的。
Change Cipher Spec(Server)
这一步是服务端通知客户端后面再发送的消息都会使用加密，也是一条事件消息。
Encrypted Handshake Message(Server)
这一步对应的是 Server Finish 消息，服务端也会将握手过程的消息生成摘要再用秘钥加密，这是服务端发出的第一条加密消息。客户端接收后会用秘钥解密，能解出来说明协商的秘钥是一致的。
Application Data
到这里，双方已安全地协商出了同一份秘钥，所有的应用层数据都会用这个秘钥加密后再通过 TCP 进行可靠传输。
双向验证
前面提到 Certificate Request 是可选的，下面这张图展示了双向验证的过程：
握手过程优化
如果每次重连都要重新握手还是比较耗时的，所以可以对握手过程进行优化。从下图里我们看到 Client Hello 消息里还附带了上一次的 Session ID，服务端接收到这个 Session ID 后如果能复用就不再进行后续的握手过程。
除了上述的 Session 复用，SSL/TLS 握手还有一些优化技术，例如 False Start、Session Ticket 等
参考文献：
[2]EtherNet/IP:Industrial Protocol White Paper
Institute of Electrical and Electronic Engineers,[3] File O P. Securing EtherNet/IPTM Networks: Introduction and Considerations[J]. ODVA Publication PUB00269R1.1, 2011.
[4] File O P. Common Industrial protocol CIPTM and the family of CIP networks: Introduction and Considerations[J]. ODVA Publication PUB00123R1,2016(引用的部分是隐士和显示传输的两种方式)
[5]Jack Visoky, Joakim Wiberg, Nancy Cam-Winget. Presented at the ODVA 2018 Industry Conference & 18th Annual Meeting October 10, 2018 Stone Mountain, Georgia, USA. TLS `1.3对CIP的影响
[6]Brian Batke, Joakim Wiberg&Dennis Dube.CIP Security Phase1 Secure Transport for EtherNet/IP.Presented at the ODVA 2015 Industry Conference&17th Annual Meeting ---TLS和DLTS安全性能的介绍
[7] A. Ginter, “The Top 20 Cyber Attacks Against Industrial Control Systems,”
https://ics-cert.us-cert.gov/sites/default/files/ICSJWGArchive/ QNL DEC 17/Waterfall top-20-attacks-article-d2%20- %20Article S508NC.pdf. [8] 冯涛,鲁晔,方君丽.工业以太网协议脆弱性与安全防护技术综述[J]. 通信学报, 2017(S2).
[9]Ryan Grandgenett ,Robin Gandhi,William Mahoney. Exploitation of Allen Bradley's implementation of etherNet/IP for denial of service against industrial control systems -----漏洞
[10]Sheffer Y, Holz R, Saint-Andre P. Summarizing known attacks on transport layer security (TLS) and datagram TLS (DTLS)[R]. 2015.
[11]Sheffer Y, Holz R, Saint-Andre P. Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)[R]. 2015.
[12]Rescorla E. The transport layer security (TLS) protocol version 1.3[R]. 2018.
[13] Song D X . Athena: a New Efficient Automatic Checker for Security Protocol Analysis[C]// IEEE Workshop on Computer Security Foundations. IEEE Computer Society, 1999. ------ 算法
[14] Cremers C J F , Mauw S . Operational Semantics of Security Protocols[C]// International Conference on Scenarios: Models. Springer-Verlag, 2005. ------Spdl 语言
[15]韩旭，陆思奇&程庆丰.形式化工具Scyther优化与实例分析
[16]陆思奇，程庆丰&赵进华.安全协议形式化分析工具比较研究
[17]魏成坤, 刘向东, 石兆军. OAuth2.0协议的安全性形式化分析[J]. 计算机工程与设计, 2016, 37(7):1746-1751.
[18] Cremers C .Scyther User manual
[19] MEMBER, IEEE, Dolev D , et al. On the Security of Public Key Protocols[J]. IEEE Transactions on Information Theory, 2003, 29(2):198-208. --------Dolev -Yao模型
[19]Cremers C ,HorvatM , Scott S , et al. Automated Analysis and Verification of TLS 1.3: 0-RTT, Resumption and Delayed Authentication[C]// 2016 IEEE Symposium on Security and Privacy (SP). IEEE Computer Society, 2016.
[20]Cremers C J F . The Scyther Tool: Verification, Falsification, and Analysis of Security Protocols[C]// Computer Aided Verification, 20th International Conference, CAV 2008, Princeton, NJ, USA, July 7-14, 2008, Proceedings. Springer-Verlag, 2008. ------- 介绍了Scyther的功能可以性能
[21]Krawczyk H , Paterson K G , Wee H . On the Security of the TLS Protocol: A Systematic Analysis[J]. 2013.
[23] Rescorla E, Modadugu N. Datagram transport layer security version 1.2[R]. 2012.