来自公众号：新世界杂货铺

前言

呼，这篇文章的筹备周期堪称是相当的长了！本来是想间接通过源码进行剖析的，然而发现TLS握手流程调试起来十分不不便，笔者怒了，于是实现了一个极简的net.Conn接口以不便调试。码着码着，笔者哭了，因为当初这个调试Demo曾经达到2000多行代码了！

尽管码了两千多行代码，然而目前只可能解析TLS1.3握手流程中发送的音讯，因而本篇次要剖析TLS1.3的握手流程。

特地揭示：有想在本地调试一番的小伙伴请至文末获取本篇源码。

论断后行

鉴于本文篇幅较长，笔者决定论断后行，以助各位读者了解后文具体的剖析内容。

HTTPS单向认证

单向认证客户端不须要证书，客户端只有验证服务端证书非法即可拜访。

上面是笔者运行Demo打印的调试信息：

依据调试信息知，在TLS1.3单向认证中，总共收发数据三次，Client和Server从这三次数据中别离读取不同的信息以达到握手的目标。

留神：TLS1.3不解决ChangeCipherSpec类型的数据，而该数据在TLS1.2中是须要解决的。因本篇次要剖析TLS1.3握手流程，故后续不会再提及ChangeCipherSpec，同时时序图中也会疏忽此音讯。

笔者将调试信息转换为下述时序图，以不便各位读者了解。

HTTPS双向认证

双向认证不仅服务端要有证书，客户端也须要证书，只有客户端和服务端证书均非法才可持续拜访。

笔者在这里特地揭示，开启双向认证很简略，在笔者的Demo中勾销上面代码的正文即可。

// sconf.ClientAuth = tls.RequireAndVerifyClientCert

另外，笔者在main.go同目录下留有测试用的根证书、服务端证书和客户端证书，为了保障双向认证的顺利运行请将根证书装置为受用户信赖的证书。

上面是笔者运行Demo打印的调试信息：

同单向认证一样，笔者将调试信息转换为下述时序图。

双向认证和单向认证相比，Server发消息给Client时会额定发送一个certificateRequestMsgTLS13音讯，Client收到此音讯后会将证书信息（certificateMsgTLS13）和签名信息（certificateVerifyMsg）发送给Server。

双向认证中，Client和Server发送音讯变多了，然而总的数据收发依然只有三次。

总结

1、TLS1.3和TLS1.2握手流程是有区别的，这一点须要留神。

2、单向认证和双向认证中，总的数据收发仅三次，单次发送的数据中蕴含一个或者多个音讯。

3、clientHelloMsg和serverHelloMsg未通过加密，之后发送的音讯均做了加密解决。

4、Client和Server会各自计算两次密钥，计算机会别离是读取到对方的HelloMsg和finishedMsg之后。

注：上述第3点和第4点剖析过程详见后文。

Client发送HelloMsg

在TLS握手过程中的第一步是Client发送HelloMsg，所以针对TLS握手流程的剖析也从这一步开始。

Server对于Client的根本信息理解齐全依赖于Client被动告知Server，而其中比拟要害的信息别离是客户端反对的TLS版本、客户端反对的加密套件（cipherSuites）、客户端反对的签名算法和客户端反对的密钥替换协定以及其对应的公钥。

客户端反对的TLS版本：

客户端反对的TLS版本次要通过tls包中(*Config).supportedVersions办法计算。对TLS1.3来说默认反对的TLS版本如下：

var supportedVersions = []uint16{    VersionTLS13,    VersionTLS12,    VersionTLS11,    VersionTLS10,}

在发动申请时如果用户手动设置了tls.Config中的MaxVersion或者MinVersion，则客户端反对的TLS版本会发生变化。

例如发动申请时，设置了conf.MaxVersion = tls.VersionTLS12，此时(*Config).supportedVersions返回的版本为：

[]uint16{    VersionTLS12,    VersionTLS11,    VersionTLS10,}

ps: 如果有趣味的小伙伴能够在克隆笔者的demo后手动设置Config.MaxVersion，设置后能够调试TLS1.2的握手流程。

客户端反对的加密套件（cipherSuites）：

说实话，加密套件曾经进入笔者的常识盲区了，其作用笔者会在下一大节讲明确，故本大节笔者间接贴出计算后的后果。

图中篮框局部为以后Client反对加密套件Id，红框局部为计算逻辑。

客户端反对的签名算法：

客户端反对的签名算法，仅在客户端反对的最大TLS版本大于等于TLS1.2时失效。此时客户端反对的签名算法如下：

var supportedSignatureAlgorithms = []SignatureScheme{    PSSWithSHA256,    ECDSAWithP256AndSHA256,    Ed25519,    PSSWithSHA384,    PSSWithSHA512,    PKCS1WithSHA256,    PKCS1WithSHA384,    PKCS1WithSHA512,    ECDSAWithP384AndSHA384,    ECDSAWithP521AndSHA512,    PKCS1WithSHA1,    ECDSAWithSHA1,}

客户端反对的密钥替换协定及其对应的公钥：

这一块儿逻辑仅在客户端反对的最大TLS版本是TLS1.3时失效。

if hello.supportedVersions[0] == VersionTLS13 {    hello.cipherSuites = append(hello.cipherSuites, defaultCipherSuitesTLS13()...)    curveID := config.curvePreferences()[0]    if _, ok := curveForCurveID(curveID); curveID != X25519 && !ok {        return nil, nil, errors.New("tls: CurvePreferences includes unsupported curve")    }    params, err = generateECDHEParameters(config.rand(), curveID)    if err != nil {        return nil, nil, err    }    hello.keyShares = []keyShare{{group: curveID, data: params.PublicKey()}}}

上述代码中，办法config.curvePreferences的逻辑为：

var defaultCurvePreferences = []CurveID{X25519, CurveP256, CurveP384, CurveP521}func (c *Config) curvePreferences() []CurveID {    if c == nil || len(c.CurvePreferences) == 0 {        return defaultCurvePreferences    }    return c.CurvePreferences}

在本篇中，笔者未手动设置优先可供选择的曲线，故curveID的值为X25519。

上述代码中，generateECDHEParameters函数的作用是依据曲线Id生成一种椭圆曲线密钥替换协定的实现。

如果客户端反对的最大TLS版本是TLS1.3时，会为Client反对的加密套件减少TLS1.3默认的加密套件，同时还会抉择Curve25519密钥替换协定生成keyShare。

小结：本节介绍了在TLS1.3中Client须要告知Server客户端反对的TLS版本号、客户端反对的加密套件、客户端反对的签名算法和客户端反对的密钥替换协定。

Server读HelloMsg&发送音讯

Server读到clientHelloMsg之后会依据客户端反对的TLS版本和本地反对的TLS版本做比照，失去Client和Server均反对的TLS版本最大值，该值作为后续持续通信的规范。本篇中Client和Server都反对TLS1.3，因而Server进入TLS1.3的握手流程。

解决clientHelloMsg

Server进入TLS1.3握手流程之后，还须要持续解决clientHelloMsg，同时构建serverHelloMsg。

Server反对的TLS版本:

进入TLS1.3握手流程之前，Server曾经计算出两端均反对的TLS版本，然而Client还无奈得悉Server反对的TLS版本，因而开始持续解决clientHelloMsg时，Server将曾经计算失去的TLS版本赋值给supportedVersion以告知客户端。

// client读取到serverHelloMsg后，通过读取此字段计算两端均反对的TLS版本hs.hello.supportedVersion = c.vers

Server计算两端均反对的加密套件：

clientHelloMsg中含有Client反对的加密套件信息，Server读取该信息并和本地反对的加密套件做比照计算出两端均反对的加密套件。

这里须要留神的是，如果Server的tls.Config.PreferServerCipherSuites为true则抉择Server第一个在两端均反对的加密套件，否则抉择Client第一个在两端均反对的加密套件。笔者通过Debug失去两端均反对的加密套件id为4865（其常量为tls.TLS_AES_128_GCM_SHA256），详情见下图：

上图中的mutualCipherSuiteTLS13函数会从cipherSuitesTLS13变量中抉择匹配的加密套件。

var cipherSuitesTLS13 = []*cipherSuiteTLS13{    {TLS_AES_128_GCM_SHA256, 16, aeadAESGCMTLS13, crypto.SHA256},    {TLS_CHACHA20_POLY1305_SHA256, 32, aeadChaCha20Poly1305, crypto.SHA256},    {TLS_AES_256_GCM_SHA384, 32, aeadAESGCMTLS13, crypto.SHA384},}

联合后面的Debug信息知，hs.suite为cipherSuiteTLS13构造体的变量且其值为cipherSuitesTLS13切片的第一个。cipherSuiteTLS13构造体定义如下：

type cipherSuiteTLS13 struct {    id     uint16    keyLen int    aead   func(key, fixedNonce []byte) aead    hash   crypto.Hash}

至此，Server曾经计算出双端均反对的加密套件，Server通过设置cipherSuite将双端均反对的加密套件告知Client：

hs.hello.cipherSuite = hs.suite.idhs.transcript = hs.suite.hash.New()

在后续计算密钥时须要对Client和Server之间的所有音讯计算Hash摘要。依据后面计算出的加密套件知，本篇中计算音讯摘要的Hash算法为SHA256，此算法的实现赋值给hs.transcript变量，后续计算音讯摘要时均通过该变量实现。

Server计算双端均反对的密钥替换协定以及对应的公钥：

clientHelloMsg.keyShares变量记录着Client反对的曲线Id以及对应的公钥。Server通过比照本地反对的曲线Id计算出双端均反对的密钥替换协定。依据后面Client发送HelloMsg这一大节的内容以及笔者理论调试的后果，双端均反对的曲线为Curve25519。

Server计算出双端均反对的曲线后，调用generateECDHEParameters办法失去对应密钥替换协定的实现，即Curve25519密钥替换协定。

Curve25519是椭圆曲线迪菲-赫尔曼（Elliptic-curve Diffie–Hellman ，缩写为ECDH）密钥替换计划之一，同时也是最快的ECC（Elliptic-curve cryptography）曲线之一。

ECDH能够为Client和Server在不平安的通道上为单方建设共享密钥，并且Client和Server须要各自持有一组椭圆曲线公私密钥对。当Client和Server须要建设共享密钥时仅须要颁布各自的公钥，Client和Server通过对方的公钥以及本人的私钥即可计算出相等的密钥。如果公钥被第三方截获也无关紧要，因为第三方没有私钥无奈计算出共享密钥除非第三方可能解决椭圆曲线Diffie–Hellman问题。ECDHE为ECDH的一个变种，其区别仅仅是私钥和公钥在每次建设共享密钥时均需从新生成（以上为笔者对维基百科中ECDH的了解）。

对ECDHE有了肯定的了解后，咱们当初看一下generateECDHEParameters函数中的局部源码：

func generateECDHEParameters(rand io.Reader, curveID CurveID) (ecdheParameters, error) {    if curveID == X25519 {        privateKey := make([]byte, curve25519.ScalarSize)        if _, err := io.ReadFull(rand, privateKey); err != nil {            return nil, err        }        publicKey, err := curve25519.X25519(privateKey, curve25519.Basepoint)        if err != nil {            return nil, err        }        return &x25519Parameters{privateKey: privateKey, publicKey: publicKey}, nil    }  // 此处省略代码}

每次调用generateECDHEParameters函数时均会生成一组新的椭圆曲线公私密钥对。clientHelloMsg.keyShares变量存有Client的公钥，因而Server曾经能够计算共享密钥：

params, err := generateECDHEParameters(c.config.rand(), selectedGroup)if err != nil {  c.sendAlert(alertInternalError)  return err}hs.hello.serverShare = keyShare{group: selectedGroup, data: params.PublicKey()}hs.sharedKey = params.SharedKey(clientKeyShare.data) // 共享密钥

上述代码中Server曾经计算出共享密钥，之后能够通过此密钥派生出其余密钥为数据加密。Client因为无Server的公钥还无奈计算出共享密钥，所以Server通过设置serverShare变量告知Client服务端的公钥。

至此，Server对Client发来的helloMsg曾经处理完毕。笔者在这里额定揭示一句，clientHelloMsg和serverHelloMsg中依然有Client和Server生成的随机数，然而在TLS1.3中这两个随机数曾经和密钥替换无关了。

小结：本节介绍了Server读取clientHelloMsg后会计算双端反对的TLS版本以及双端反对的加密套件和密钥替换协定，同时还介绍了共享密钥的生成以及ECDH的概念。

抉择适合的证书以及签名算法

在Server抉择和以后Client匹配的证书前其实还有对于预共享密钥模式的解决，该模式须要实现ClientSessionCache接口，鉴于其不影响握手流程的剖析，故本篇不探讨预共享密钥模式。

一个Server可能给多个Host提供服务，因而Server可能持有多个证书，那么抉择一个和以后Client匹配的证书是十分必要的，其实现逻辑参见(*Config).getCertificate办法。本篇中的Demo只有一个证书，故该办法会间接返回此证书。

证书中是蕴含公钥的，不同的公钥反对的签名算法是不同的，在本例中Server反对的签名算法和最终双端均反对的签名算法见上面的Debug后果：

上图中红框局部为Server反对的签名算法，蓝框为选定的双端均反对的签名算法。

小结：本节次要介绍了Server抉择匹配以后Client的证书和签名算法。

计算握手阶段的密钥以及发送Server的参数

在这个阶段Server会将serverHelloMsg写入缓冲区，写完之后再写入一个ChangeCipherSpec（TLS1.3不会解决此音讯）音讯，须要留神的是serverHelloMsg未进行加密发送。

计算握手阶段的密钥：

后面提到过计算密钥须要计算音讯摘要：

hs.transcript.Write(hs.clientHello.marshal())hs.transcript.Write(hs.hello.marshal()) // hs.hello为serverHelloMsg

上述代码中hs.transcript在后面曾经提到过是SHA256Hash算法的一种实现。上面咱们逐渐剖析源码中Server第一次计算密钥的过程。

首先，派生出handshakeSecret：

earlySecret := hs.earlySecret if earlySecret == nil {  earlySecret = hs.suite.extract(nil, nil)}hs.handshakeSecret = hs.suite.extract(hs.sharedKey, hs.suite.deriveSecret(earlySecret, "derived", nil))

earlySecret和预共享密钥无关，因本篇不波及预共享密钥，故earlySecret为nil。此时，earlySecret会通过加密套件派生出一个密钥。

// extract implements HKDF-Extract with the cipher suite hash.func (c *cipherSuiteTLS13) extract(newSecret, currentSecret []byte) []byte {    if newSecret == nil {        newSecret = make([]byte, c.hash.Size())    }    return hkdf.Extract(c.hash.New, newSecret, currentSecret)}

上述代码中HDKF是一种基于哈希音讯身份验证的密钥派生算法，其两个主要用途别离为：一、从较大的随机源中提取更加平均和随机的密钥；二、将曾经正当的随机输出（例如共享密钥）扩大为更大的明码独立输入，从而将共享密钥派生出多个密钥（以上为笔者对维基百科中HKDF的了解）。

上述代码中hs.suite.deriveSecret办法笔者就不列出其源码了，该办法最终会调用hkdf.Expand办法进行密钥派生。

此时再次回顾hs.handshakeSecret的生成正是HKDF算法基于sharedKey和earlySecret计算的后果。

而后，通过handshakeSecret和音讯摘要派生出一组密钥。

clientSecret := hs.suite.deriveSecret(hs.handshakeSecret,    clientHandshakeTrafficLabel, hs.transcript)c.in.setTrafficSecret(hs.suite, clientSecret)serverSecret := hs.suite.deriveSecret(hs.handshakeSecret,    serverHandshakeTrafficLabel, hs.transcript)c.out.setTrafficSecret(hs.suite, serverSecret)

上述代码中clientHandshakeTrafficLabel和serverHandshakeTrafficLabel为常量，其值别离为c hs traffic和s hs traffic。hs.suite.deriveSecret办法会在外部调用hs.transcript.Sum(nil)计算出音讯的摘要信息，所以clientSecret和serverSecret是HKDF算法基于handshakeSecret和两个常量以及Server和Client曾经发送的音讯的摘要派生出的密钥。

clientSecret在服务端用于对收到的数据进行解密，serverSecret在服务端对要发送的数据进行加密。c.in和c.out同其语义一样，别离用于解决收到的数据和要发送的数据。

上面看看笔者对setTrafficSecret办法的Debug后果：

上图中trafficKey办法应用HKDF算法对密钥进行了再次派生，笔者就不再对其开展。这里须要关注的是红框局部，aes-gcm是一种AEAD加密。

单纯的对称加密算法，其解密步骤是无奈确认密钥是否正确的。也就是说，加密后的数据能够用任何密钥执行解密运算，失去一组疑似原始数据，然而并不知道密钥是否是正确，也不晓得解密进去的原始数据是否正确。因而，须要在单纯的加密算法之上，加上一层验证伎俩，来确认解密步骤是否正确，这就是AEAD。

至此，Server在握手阶段的密钥生成完结，此阶段之后发送的音讯（即serverHelloMsg和ChangeCipherSpec之后的音讯），均通过aes-gcm算法加密。

最初回顾一下加密套件的作用：

1、提供音讯摘要的Hash算法。

2、提供加解密的AEAD算法。

最初再顺便提一嘴，笔者Demo中parse.go文件的processMsg办法在解决serverHelloMsg时有计算握手阶段密钥的极简实现。

反对的HTTP协定：

Client通过clientHelloMsg.alpnProtocols告知Server客户端反对的HTTP协定，Server通过比照本地反对的HTTP协定，最终抉择双端均反对的协定并构建encryptedExtensionsMsg音讯告知Client

encryptedExtensions := new(encryptedExtensionsMsg)if len(hs.clientHello.alpnProtocols) > 0 {  if selectedProto, fallback := mutualProtocol(hs.clientHello.alpnProtocols, c.config.NextProtos); !fallback {    encryptedExtensions.alpnProtocol = selectedProto    c.clientProtocol = selectedProto  }}hs.transcript.Write(encryptedExtensions.marshal())

hs.clientHello.alpnProtocols的数据起源为客户端的tls.Config.NextProtos。在笔者的Demo中，Client和Server均反对h2和http1.1这两种协定。

这里顺便强调一下，Client或者Server在获取到对方的helloMsg之后承受/发送的音讯均会调用hs.transcript.Write办法，以便计算密钥时能够疾速计算音讯摘要。

小结：

1、本节探讨了握手阶段的密钥生成流程：对音讯摘要，而后用HKDF算法对共享密钥和音讯摘要派生密钥，最初通过加密套件返回AEAD算法的实现。

2、确认了加密套件的作用。

3、计算两端均反对的HTTP协定。

发送Server证书以及签名

此阶段次要波及三个音讯，别离是certificateRequestMsgTLS13、certificateMsgTLS13和certificateVerifyMsg。

其中certificateRequestMsgTLS13仅在双向认证时才发送给Client，单向认证时Server不发送此音讯。这里也再次印证了后面单向认证和双向认证时序图中Server发送的音讯数量不统一的起因。

certificateMsgTLS13音讯的主体是Server的证书这个没什么好说的，上面着重剖析一下certificateVerifyMsg。

私钥签名：

首先，构建certificateVerifyMsg并设置其签名算法。

certVerifyMsg := new(certificateVerifyMsg)certVerifyMsg.hasSignatureAlgorithm = true // 没有签名算法无奈签名，所以间接写true没故障certVerifyMsg.signatureAlgorithm = hs.sigAlg

上述代码中hs.sigAlg为抉择适合的证书以及签名算法大节抉择的签名算法。

而后，通过签名算法计算签名类型以及签名hash，并构建签名选项。以下为笔者Debug后果：

由上图知，签名类型为signatureRSAPSS，签名哈希算法为SHA256。signedMessage的作用是将音讯的摘要和serverSignatureContext（值为TLS 1.3, server CertificateVerify\x00）常量依照固定格局构建为待签名数据。

最初，计算签名并发送音讯。

sig, err := hs.cert.PrivateKey.(crypto.Signer).Sign(c.config.rand(), signed, signOpts)if err != nil {  // 省略代码  return errors.New("tls: failed to sign handshake: " + err.Error())}certVerifyMsg.signature = sighs.transcript.Write(certVerifyMsg.marshal())

特地揭示，私钥加密公钥解密称之为签名。

小结：本节次要介绍了此阶段会发送的三种音讯，以及Server签名的过程。

发送finishedMsg并再次计算密钥

发送finishedMsg：

finishedMsg的内容非常简单，仅一个字段：

finished := &finishedMsg{  verifyData: hs.suite.finishedHash(c.out.trafficSecret, hs.transcript),}

verifyData通过加密套件的finishedHash计算得出，上面咱们看看finishedHash的内容：

func (c *cipherSuiteTLS13) finishedHash(baseKey []byte, transcript hash.Hash) []byte {    finishedKey := c.expandLabel(baseKey, "finished", nil, c.hash.Size())    verifyData := hmac.New(c.hash.New, finishedKey)    verifyData.Write(transcript.Sum(nil))    return verifyData.Sum(nil)}

HMAC是一种利用密码学中的散列函数来进行音讯认证的一种机制，所能提供的音讯认证包含两方面内容（此内容摘自百度百科）：

音讯完整性认证：可能证实音讯内容在传送过程没有被批改。

信源身份认证：因为通信单方共享了认证的密钥，接管方可能认证发送该数据的信源与所声称的统一，即可能牢靠地确认接管的音讯与发送的统一。

上述代码中，c.expandLabel最种会调用hkdf.Expand派生出新的密钥。最初用新的密钥以及音讯摘要通过HMAC算法计算出verifyData。

收到finishedMsg一方通过同样的形式在本地计算出verifyData'，如果verifyData'和verifyData相等，则证实此音讯未被批改且起源可信。

再次计算密钥：

本次计算密钥的过程和后面计算密钥的流程类似，所以间接上代码：

hs.masterSecret = hs.suite.extract(nil,    hs.suite.deriveSecret(hs.handshakeSecret, "derived", nil))hs.trafficSecret = hs.suite.deriveSecret(hs.masterSecret,    clientApplicationTrafficLabel, hs.transcript)serverSecret := hs.suite.deriveSecret(hs.masterSecret,    serverApplicationTrafficLabel, hs.transcript)c.out.setTrafficSecret(hs.suite, serverSecret)

首先，利用前文曾经生成的handshakeSecret 再次派生出masterSecret，而后再从masterSecret派生出trafficSecret和serverSecret，最初调用c.out.setTrafficSecret(hs.suite, serverSecret)计算出Server发送数据时的AEAD加密算法。

须要留神的是，此时利用serverSecret生成的AEAD加密算法会用于握手完结后对要发送的业务数据进行加密。

此阶段完结后，Server会调用c.flush()办法，将后面提到的音讯一次性发送给Client。

小结：

1、本节介绍了finishedMsg的生成过程，其中finishedMsg.verifyData通过HMAC算法计算得出。

2、finishedMsg的作用是确保握手过程中发送的音讯未被篡改，且数据起源可信。

3、计算Server发送业务数据时的加密密钥。

Client读音讯&发送音讯

Client读到serverHelloMsg之后会读取服务端反对的TLS版本并和本地反对的版本做比照，前文曾经提到过服务端反对的TLS版本是TLS1.3，因而Client也进入TLS1.3握手流程。

读取serverHelloMsg并计算密钥

Client进入TLS1.3握手流程后，有一系列的查看逻辑，这些逻辑比拟长而且笔者也不须要思考这些异样，因而笔者化繁为简，在上面列出要害逻辑：

selectedSuite := mutualCipherSuiteTLS13(hs.hello.cipherSuites,    hs.serverHello.cipherSuite) // 联合Server反对的加密套件抉择双端均反对的加密套件hs.suite = selectedSuitehs.transcript = hs.suite.hash.New()hs.transcript.Write(hs.hello.marshal()) // hs.hello为clientHelloMsghs.transcript.Write(hs.serverHello.marshal())

下面这一段代码逻辑和Server解决加密套件以及通过加密套件构建音讯摘要算法的实现逻辑绝对应，因而笔者不再过多赘述。

上面咱们看一下计算握手阶段的密钥以及masterSecret的生成：

sharedKey := hs.ecdheParams.SharedKey(hs.serverHello.serverShare.data)earlySecret := hs.earlySecretif !hs.usingPSK {  earlySecret = hs.suite.extract(nil, nil)}handshakeSecret := hs.suite.extract(sharedKey,    hs.suite.deriveSecret(earlySecret, "derived", nil)) // 通过共享密钥派生出handshakeSecretclientSecret := hs.suite.deriveSecret(handshakeSecret,    clientHandshakeTrafficLabel, hs.transcript) // 通过handshakeSecret派生出clientSecretc.out.setTrafficSecret(hs.suite, clientSecret)serverSecret := hs.suite.deriveSecret(handshakeSecret,    serverHandshakeTrafficLabel, hs.transcript) // 通过handshakeSecret派生出serverSecretc.in.setTrafficSecret(hs.suite, serverSecret)hs.masterSecret = hs.suite.extract(nil,    hs.suite.deriveSecret(handshakeSecret, "derived", nil)) // 通过handshakeSecret派生出masterSecret

这里须要提一嘴的是hs.ecdheParams，该值为Client发送HelloMsg这一大节调用generateECDHEParameters函数生成的params。其余逻辑和Server生成握手阶段的密钥保持一致，硬要说不同的话也就只有masterSecret生成的阶段不同。

最初，clientSecret在客户端用于对要发送的数据进行加密，serverSecret在客户端对收到的数据进行解密。

小结：本节梳理了客户端解决serverHelloMsg的逻辑和生成握手阶段密钥的逻辑。

解决Server发送的参数

在客户端须要解决的Server参数只有一个encryptedExtensionsMsg音讯。而且解决逻辑也非常简略：

msg, err := c.readHandshake()encryptedExtensions, ok := msg.(*encryptedExtensionsMsg)hs.transcript.Write(encryptedExtensions.marshal())c.clientProtocol = encryptedExtensions.alpnProtocol

如果客户端读取到encryptedExtensionsMsg音讯，则间接将Server反对的HTTP协定赋值给c.clientProtocol。在之后的HTTP申请中会依据TLS握手状态以及服务端是否反对h2决定是否将本次申请降级为http2。

验证证书和签名

本大节依然持续解决Server发送的音讯，次要蕴含certificateRequestMsgTLS13、certificateMsgTLS13和certificateVerifyMsg，这三个音讯均和证书相干。

首先，解决certificateRequestMsgTLS13音讯，仅在双向认证时，服务端才发送此音讯。在本阶段的解决逻辑也很简略，读取该音讯并记录。

msg, err := c.readHandshake()certReq, ok := msg.(*certificateRequestMsgTLS13)if ok {  hs.transcript.Write(certReq.marshal())  hs.certReq = certReq  msg, err = c.readHandshake()}

其次，解决certificateMsgTLS13音讯，该音讯中次要蕴含证书信息，Client在获取到证书信息后要校验证书是否过期以及是否可信赖。

if err := c.verifyServerCertificate(certMsg.certificate.Certificate); err != nil {  return err}

c.verifyServerCertificate的外部逻辑如果各位读者有趣味能够下载Demo调试一番，笔者在这里就不对该办法做深刻的开展和剖析了。

最初，解决certificateVerifyMsg音讯。后面在解决certificateMsgTLS13时曾经验证了证书可信赖或者Client能够疏忽不受信赖的证书，然而Client仍无奈确信提供这个证书的服务器是否持有该证书，而验证签名的意义就在于确保该服务的确持有该证书。

在Server发送certificateVerifyMsg音讯时曾经应用了证书对应的私钥对须要签名的数据进行签名，客户端利用证书的公钥解密该签名并和本地的待签名数据做比照以确保服务端的确持有该证书。

// 依据签名算法返回对应的算法类型和hash算法sigType, sigHash, err := typeAndHashFromSignatureScheme(certVerify.signatureAlgorithm)signed := signedMessage(sigHash, serverSignatureContext, hs.transcript)if err := verifyHandshakeSignature(sigType, c.peerCertificates[0].PublicKey,    sigHash, signed, certVerify.signature); err != nil {  c.sendAlert(alertDecryptError)  return errors.New("tls: invalid signature by the server certificate: " + err.Error())}

typeAndHashFromSignatureScheme函数和signedMessage函数在前文曾经提到过，因而不再做反复叙述。

verifyHandshakeSignature函数的外部实现波及到非对称加密算法的加解密，因笔者的常识无限，的确无奈做更进一步的剖析，在这里给各位读者道个歉～

小结：在这一大节简略介绍了客户端证书的验证以及签名的验证。

解决finishedMsg并再次计算密钥

客户端对证书签名验证通过后，接下来还须要验证音讯的完整性。

finished, ok := msg.(*finishedMsg)expectedMAC := hs.suite.finishedHash(c.in.trafficSecret, hs.transcript)if !hmac.Equal(expectedMAC, finished.verifyData) {  c.sendAlert(alertDecryptError)  return errors.New("tls: invalid server finished hash")}

finishedHash办法阐明请参考发送finishedMsg并再次计算密钥这一大节。

只有当客户端计算的expectedMAC和finishedMsg.verifyData统一时才可持续后续操作，即客户端二次计算密钥。

hs.trafficSecret = hs.suite.deriveSecret(hs.masterSecret,    clientApplicationTrafficLabel, hs.transcript)serverSecret := hs.suite.deriveSecret(hs.masterSecret,    serverApplicationTrafficLabel, hs.transcript)c.in.setTrafficSecret(hs.suite, serverSecret)

二次计算密钥时别离派生出trafficSecret和serverSecret两个密钥。

须要留神的是，此时利用serverSecret生成的AEAD加密算法会用于握手完结后对收到的业务数据进行解密。

至此，Server发送给客户端的音讯曾经全副处理完毕。

小结：本节次要介绍了客户端通过HMAC算法确保收到的音讯未被篡改以及二次计算密钥。

Client发送最初的音讯

客户端曾经验证了服务端音讯的完整性，然而服务端还未验证客户端音讯的完整性，因而客户端还须要发送最初一次数据给服务端。

首先判断是否须要发送证书给Server：

if hs.certReq == nil {  return nil}certMsg := new(certificateMsgTLS13)// 此处省略代码certVerifyMsg := new(certificateVerifyMsg)certVerifyMsg.hasSignatureAlgorithm = true// 此处省略代码

依据验证证书和签名这一大节的形容，如果服务端要求客户端发送证书则hs.certReq不为nil。

certificateMsgTLS13的主体也是证书，该证书的起源为客户端tls.Config配置的证书，在本例中客户端配置证书逻辑如下：

tlsConf.NextProtos = append(tlsConf.NextProtos, "h2", "http/1.1")tlsConf.Certificates = make([]tls.Certificate, 1)if len(certFile) > 0 && len(keyFile) > 0 {  var err error  tlsConf.Certificates[0], err = tls.LoadX509KeyPair(certFile, keyFile)  if err != nil {    return nil, err  }}

既然要发送证书给服务端，那么同服务端逻辑一样也须要发送certificateVerifyMsg提供音讯签名的信息。客户端签名逻辑和服务端签名逻辑统一，因而笔者不再赘述。

最初，客户端须要发送finishedMsg给服务端：

finished := &finishedMsg{  verifyData: hs.suite.finishedHash(c.out.trafficSecret, hs.transcript),}hs.transcript.Write(finished.marshal())c.out.setTrafficSecret(hs.suite, hs.trafficSecret)

须要留神的是hs.trafficSecret在第二次计算密钥时就曾经被赋值，当finishedMsg发送后，利用hs.trafficSecret生成的AEAD加密算法会对客户端要发送的业务数据进行加密。

至此，客户端的握手流程全副实现。

小结：

1、如果服务端要求客户端发送证书，则客户端会发送certificateMsgTLS13和certificateVerifyMsg音讯

2、发送finishedMsg音讯并设置发送业务数据时的密钥信息。

Server读Client最初的音讯

首先，服务端在TLS握手的最初阶段，会先判断是否要求客户端发送证书，如果要求客户端发送证书则解决客户端发送的certificateMsgTLS13和certificateVerifyMsg音讯。服务端解决certificateMsgTLS13和certificateVerifyMsg音讯的逻辑和客户端解决这两个音讯的逻辑相似。

其次，读取客户端发送的finishedMsg， 并验证音讯的完整性，验证逻辑和客户端验证finishedMsg逻辑统一。

最初，设置服务端读取业务数据时的加密信息：

c.in.setTrafficSecret(hs.suite, hs.trafficSecret)

hs.trafficSecret在服务端第二次计算加密信息时就曾经赋值，当读完客户端发送的finishedMsg之后再执行此步骤是为了防止无奈解密客户端发送的握手信息。

至此，服务端的握手流程全副实现。

握手实现之后

实现上述流程后，笔者还想试试看能不能从握手过程获取的密钥信息对业务数据进行解密。说干就干，上面是笔者在TLS握手实现之后用Client连贯发送了一条音讯的代码。

// main.go 握手实现之后，client发送了一条数据client.Write([]byte("点赞关注：新世界杂货铺"))

上面是运行Demo后的输入截图：

图中红色箭头局部为在Internet中实在传输的数据，蓝色箭头局部为其解密后果。

一点感叹

对于TLS握手流程的文章笔者想写很久了，当初总算得偿所愿。笔者不敢保障把TLS握手过程的每一个细节都形容分明，所以如果两头有什么问题还请各位读者及时指出，大家互相学习。

写到这里时笔者的心田也略有忐忑，毕竟这两头波及了很多密码学相干的常识，而在笔者各种疯狂查资料期间发现国内具备权威性的文章还是太少。像ECDH之类的关键词在百度百科都没有收录，果然维基百科才是爸爸呀。

最初一点感概是对于Go中io.Reader 和io.Writer这两个接口的，不得不说这两个接口的设计真的很简略然而真的十分通用。笔者的Demo正是基于这两个接口实现，否则笔者的宿愿很难实现。

挖坑

在上一篇文章中，笔者给了一条彩蛋——“下一期TLS/SSL握手流程敬请期待”。哇，这可真的是本人坑本人了，本篇文章未实现之前，笔者愣是断更了也没敢发别的文章。果然本人作的死，哭着也要作完。

有了前事不忘;后事之师，笔者决定当前不再放彩蛋，而是挖坑（填坑工夫待定????）：本篇中次要介绍了TLS1.3的握手流程，那么TLS1.2也快了～

最初，衷心希望本文可能对各位读者有肯定的帮忙。

注：

  1. 写本文时， 笔者所用go版本为: go1.15.2
  2. 文章中所用残缺例子：https://github.com/Isites/go-...