Open wython opened 4 years ago
https并不是一个协议，通常来说，如果我们说使用了https，意思是说，我们在http上使用了tls协议。 于是，我们可以更进一步的理解到：
为什么我比较强调这种层次概念，因为知识的边界和概念需要划分清晰，在遇到问题，才能知道突破口是在哪。我看大部分关于https文章会一上来就讲一些握手过程，或者密码学原理相关的内容，或者有些文章甚至没有关于协议本书的说明，而是仅仅讲抽象握手过程。我想，这样的理解并没有很结构化的去讲好这样一个东西，所以这也是我写这篇文章的初衷。
为了容易理解，我会把比较结构性内容放在前面，把细节内容放在后面。
上面一直在讲tls，对于事先没有了解过https的人来说，可能有点迷糊——tls是什么？ 了解过tls的人，应该也知道ssl协议。
从字面意思上来看，这两个东西差不多，实际上，这两个东西也可以认为是一样的概念。tls就是ssl升级之后的版本，在早期时候（1994），为了解决http本身的安全问题，网景公司创建了ssl协议应用于http协议，后来将ssl统一，应用于更广泛的应用层协议，进一步标准化ssl协议，也就是tls协议。
可以把tls当成一层协议看待，那么其于http的关系类似于：
上面提到，为了解决http存在的安全问题，所以引入tls协议。我们自然会有这样的疑问，是什么样的安全问题，需要在协议上去做文章。
先总结这样三个问题：
数据隐私：http协议是明文传输，也就是说如果中间人劫持请求，很容易理解到http协议传输内容的含义。有人可能会问：那我们平时通过加密传输不就可以解决了吗，为什么需要在协议中大动干戈。这里就需要点密码学的常识，如果仅仅是简单的加密数据，我们有三种可选密码方案，对称加密，非对称加密，单向散列或者mac算法，不管是对称加密和非对称加密，这意味着双方都需要有解密用的钥，对称加密用的是同一个密钥，非对称需要各有一把相对的钥匙。对于web这样面向客户端的传输，在客户端植入密钥明显是不现实的行为，所以可选方案中，密钥怎么安全传输变成了另一个问题，也是tls协议握手协议解决的问题。至于不可逆的加密，比如登录密码本身，对于中间人攻击，其实他并不需要知道你本身数据是什么，这样看似把数据隐私化，实际上并没有达到安全效果。
数据被篡改：如果http协议没法防止被篡改。虽然有消息验证码，数字签名能保证数据完整。但是单纯一个密码技术依然很难防止中间人攻击
身份认证问题：http是无状态协议，所以验证服务端身份是一件重要事情，证书认证也是https安全传输的一环
http确实存在这样一些安全问题，虽然对使用者而言，确实有很多方法去预防安全问题，但是通过分析可以发现，没法用简单的方式，通过单一的一个种密码学算法就能解决这些问题，一般来说，会组合各种密码学算法，这是一个繁琐的工作，所以tls也是将这些繁琐的问题，统一成一个解决方案。
tls是介于应用层协议和tcp协议纸之间的协议，tls协议可以分成两层协议：
结构如图：
握手协议可以分成四个子协议： 结构如图：
注：在tls 1.2版本之前，没有heartbeat心跳协议，而是change cipher spec protocol密码切换协议。
记录层协议是接近tcp协议的底层协议，用来将握手协议定义消息封装和下层协议通讯。
握手协议可以说是tls中最重要的子协议，因为它的职责就是协商出一种合适的 密码套件 。上面也提到，解决一个安全问题不止一种加密算法，密码套件正是一组各种不同功能算法的集合。一般需要两个来回协商完成。
握手协议中以消息为单位，消息格式如图：
一个消息分成是三个部分：
tls协议有十种不同的消息类型，分别是：
握手过程一般是两个来回，主要用于交换不同的信息。tls1.2版本的握手过程，大体可以如图这样抽象表示：
可以看到，在经过两个来回之后，客户端和服务端就正式进入数据传输。在握手端来回中，不难发现，一个请求可能会带好几个握手协议不同的消息类型。这是因为，虽然握手协议会把不同消息交给记录层协议，但是记录层协议一般会把几个类型封装成一个数据块发送。
图中的*标记表示该消息会根据不同的密码套件做调整，[]标记表示该协议并不是握手协议定义的内容，但是也会在握手过程中进行。颜色较浅部分属于需要一个集合，绑定发送，这是双向认证需要的环节。
接下来，就细看每一个消息的含义把
上面流程图中，客户端首先会发起一个消息，这个消息结构如下：
struct { ProtocolVersion client_version; Random random; SessionID session_id; CipherSuite cipher_suites<2..2^16-2>; CompressionMethod compression_methods<1..2^8-1>; select (extensions_present) { case false: struct {}; case true: Extension extensions<0..2^16-1>; }; } ClientHello;
该数据定义了6个key：
所以说，消息并不是很复杂。
服务端的hello信息和客户端一样的结构
struct { ProtocolVersion server_version; Random random; SessionID session_id; CipherSuite cipher_suite; CompressionMethod compression_method; select (extensions_present) { case false: struct {}; case true: Extension extensions<0..2^16-1>; }; } ServerHello;
具体就不重复描述了。
这个消息是和上面的hello在一个请求的，可以看到，握手协议发送完server_hello情况以后就会发送certificate消息。但是由于，一些密码套件如DH_anon和DCDH_anon，不会发送该证书，所以该消息是可选的，但是大部分情况，都会用到证书信息。
该消息主要承载证书信息，证书是做身份验证的，该消息结构如下：
opaque ASN.1Cert<1..2^24-1>; struct { ASN.1Cert certificate_list<0..2^24-1>; } Certificate;
可以看到只有一个certificate_list数组，该数组发送的是证书链，用于证书认证。 关于证书细节留到后面去讲述。
如果certificate消息里的证书信息不足以满足协商加密算法信息要求，会额外发送一个server_key_exchange信息作为补充。有6种密码套件是需要这个消息来发送的，如下：
DHE_DSS DHE_RSA ECDHE_ECDSA ECDHE_RSA ------------------------ // 无证书 DH_anon ECDH_anon
分割线之前的套件由于使用的临时的 DH/ECDH 密钥协商算法，证书中是不包含这些动态的 DH 信息(DH 参数和 DH 公钥)，所以发送完证书信息之后会追加这个消息对DH信息做补充
分割线下面的两种套件，属于匿名协商，没有证书信息，所以不会有certificate消息，但是由于需要发送额外的静态DH信息，所以会在这个消息里追加发送。
对于不同公钥密码算法细节就不在这里讨论。
可以看到，服务器端可能会发送一个certificate_request消息。该消息是可选的，同时是灰色，我用灰色表示，为了说明该消息和其他灰色信息的关系，同时，一般也不会出现。但是在双向认证场景中，由于需要客户端也提供证书，所以服务端会发送这样信息，要求客户端也需要认证证书。
上面流程图，在发送完sertificate和exchange信息之后，服务端会紧接一个server_hello_done类型消息作为结束。之后server会等待客户端后续的工作。该消息结构十分简单：
struct { } ServerHelloDone;
对于客户端的certificate消息，该消息表示，如果在收到服务端发送的消息里，包含certificate_request消息，则客户端会根据自身条件发送证书信息。如果没有客户端没有合适的证书信息，会发送一个空数组。
该消息无论如何都会发送，这个消息最大的作用是传递pre_master_key,也就是预备主密钥，除了预备主密钥，如果客户端需要发送上面的certificate消息，还会对类型DH算法密钥做补充信息。但是不管怎么，生成pre_master_key是最重要对事，生成对pre_master_key是用于生成master_key的重要前提，生成master_key会在双方拿到pre_master_key之后，在生成master_key之后，便会发送[ChangeCipherSpec]消息，转换状态。这意味着握手过程进入可以加密阶段。
其含义可以参考上面服务端的server_key_exchange
对于1.2版本的，在握手消息中，会涉及到协议状态转换，在1.3版本之后，该协议不在存在，但是为了向下兼容，握手中可能还会有。该协议是用于改变协议状态。
可以理解为，在上述的握手过程中，收到该协议消息的端，状态都为：
pending read status 待读状态 pending write status 待写状态
在接收到该信息之后，端状态修改为：
current read status 可读状态 current write status 可写状态
该消息表示，在握手过程中，当进入可读可写状态时，表示对端将进入加密阶段，这也意味着，握手环节已经基本完成，具备加密传输的条件。
在双方发送完，会对握手中的重要信息进行验证，验证双方会发送自己的校验信息，消息结构如下：
struct { opaque verify_data[verify_data_length]; } Finished; verify_data = PRF(master_secret, finished_label, Hash(handshake_messages)) [0..verify_data_length-1];
该消息的意义在于：握手过程中所有的子消息都没有加密和完整性保护，消息很容易篡改。为了避免握手期间存在消息被篡改的情况，所以 Client 和 Server 都需要校验一下对方的 Finished 子消息。
完成finish消息之后，最后双方的通讯会以master_key作为对称加密信息的主密钥。
以上，是tls1.2定义的握手内容，当然，还有很多细节没有研究，比如握手中涉及到的随机数，session_id的作用。不过大体的过程已经讲完了，后续慢慢补充一些细节。细节部分则需要一点密码学常识。
如果想更深入理解，则需要了解部分密码学相关内容，像上面提到的对称加密，非对称加密，随机数，均属于密码学的内容。
这里简单的介绍几个密码学概念，他们分别是：
随机数作为重要的密码学单元,在密码学中广泛运用到，密码学单元是指：在其他算法中，随机数会产当一个因子的作用。比如生成对称密码和消息验证码。
随机数有三个重要的特性：
三个特性关系可以表示为：
一般我们把具有不可重现性的随机数叫真随机数,把具有不可预知的随机数叫强伪随机数,把具有随机性的随机数叫伪随机数。
只有至少具有强伪随机数特性的随机数算法才能用于密码学。
单向散列函数即one-way hash function。就是我们常说的hash算法，对于用过md5算法的小伙伴应该不陌生。但是需要注意的是，单向散列函数的作用是保证消息的完整性。
单向散列函数具有这样的特点：
关于强抗碰撞和弱抗碰撞：
通过特点我们可以很容易的知道，单向散列可以用来比较消息的完整性。因为其足够小，足够快，用来校验不同内容是否完整很有用。
缺陷： 当然，这也暴露了，单向散列函数的局限性，就是无法防止被篡改，也无法验证信息的来源。无法防止篡改，是因为攻击者很容易的可以将不同消息生成散列并且伪装。比如中间人攻击。
常见散列算法：
加密和解密都是用同一个密钥的加密算法，叫对称加密算法。对称加密算法是在传输数据双方持有一个相同的密钥，这种算法需要解决最大问题就是密钥的传输问题。 常见的对称加密有AES，DES。
公钥密码算法就是非对称加密算法，由于前面提到的对称加密算法的局限性，所以很自然而然的联想到，是否有一种传输数据双方使用不同的密钥的算法。公钥密码算法的解密模型也很简单：
这里需要提下，公钥加密算法确实有更多可能性，但是我发现很多人有一些理解误区：
目前最常用的公钥加密算法是RSA算法和ECC算法。
关于这两个算法细节，这里就不花时间描述了。ECC算法相对密钥比RSA算法短，同时效率和机密性比RSA高。
公钥加密算法的缺点就是执行效率太慢。
消息验证码(message authentication code)是一种确认完整性，并认证的技术。简称MAC算法。
关于mac算法的理解需要结合之前的单向散列算法来看。我们知道，单向散列算法可以保证消息的完整性。
先看看两者的对比。
MAC算法相对单向散列算法而言，多了一个共享密钥才能生成MAC值。这样很容易联想到，如何在网络中传输密钥是MAC算法的一个问题，这个问题和对称加密算法中的问题一样。
那MAC算法相对HASH算法解决了什么问题呢，我们知道，如果中间人攻击了HASH算法生成的HASH值。由于HASH算法和MAC算法不关注消息的机密性，所以中间人可以对消息进行修改，同时用HASH算法重新生成HASH值从而达到篡改数据的效果。虽然MAC算法的密钥如果被中间人劫持，一样会遭受同样的问题，但是我们如果有一种方案，能够保证Mac密钥不被劫持，就能防止中间人攻击，这就是Mac算法存在的意义。
所以，在MAC算法密钥安全的情况下。mac能保证消息完整，同时能够认证，认证的含义是只有持有密钥的人可以生成mac值。
那mac算法的有没有其局限性，除了说mac算法本身不是为了机密性而生之外，mac算法依然无法反正抵赖问题。如何理解抵赖？
我们假设作为第三者角度而言，用mac算法认证的消息虽然是完整的，但是如果有一天有一方对这个消息不承认，由于发送方和接收方都有密钥生成mac值，所以我们无法单从mac值中判断说，这个消息是谁生成的。这就需要用到后面介绍的数字签名技术。
数字签名，是一种能够认证消息来源，保证数据准确性，防止篡改的技术。关于数字签名，依然需要和单向散列算法和MAC算法做一个对比。
单向散列算法可以保证消息完整准确性，含义在于只能保证在信息传输中不存在异常。但是无法防止如中间人攻击之类的，篡改数据，同时也无法对消息进行认证。
Mac算法可以保证消息准确同时，因为有一个共享密钥，所以只要保证密钥安全，就能反正数据被篡改，但是由于数据传输双方对密钥是相同的，无法通过第三方得知消息是谁发送的，即不能防止抵赖。
数字签名在借助公钥密码算法的密钥不同的特点，实现了消息认证的机制。原理很简单，就是生成消息的一方通过密钥生成签名，接受消息的一方，可以通过公钥解开消息然后认证消息的正确性。为什么数字签名可以反正抵赖，因为只有持有公钥的人才能验证消息，只有持有密钥的人才能生成签名。这样双方都无法抵赖，同时也能保证消息的完整性，同样能反正篡改。
关于数字签名的简单流程：
由于签名提到非对称加密算法的性能很差，所以上面流程的比对，性能自然也不好，原因是消息的长度可能很长，同时，对于rsa算法而言，需要加密的消息越长，其密钥公钥长度也要越长。聪明同学很容易联想到，使用单向散列算法可以使消息生成简单的hash值，同时，单向散列算法性能也很好。这样就解决了这个问题，所以，一般的签名算法流程优化如下：
补充：这里做一点补充，在数字签名里，非对称加密算法，通过密钥加密生成签名，通过公钥解密验证签名。而在使用rsa做加密操作时，一般会用公钥加密数据传输，而不会通过密钥加密数据传输。原因是因为，公钥是公开对，任何人都可能获得，如果通过密钥加密数据，任何人都可能拿到公钥然后解密。
回顾前面的技术，消息认证码（MAC），对称加密，以及用到这些技术的地方，都要强调密钥重要性。但是在网络传输过程中，为了双方都能持有相同密钥。我们会思考如何传输密钥。
这个就是密钥如何配送的问题，关于解决密钥配送问题，有以下几种方式：
这里只讲下DH的简单过程，关于用非对称算法传输密钥很好理解，就不再这里描述：
在上面流程中，G，P，G^AmodP和G^BmodP是四个公开的数字。但是要通过这四个数字算出A，B数是很难的。
生成元G的意义： G的计算是比较复杂的，对于G^XmodP （1 < x < p 内的整数)的所有值都不同时，G就是P的元。而A，B随机取0到P之间的所有整数。这样，A，B有足够多的选择，同时计算有足够多的可能性。
DH算法能防止中间人攻击吗？不能，中间人依然可以通过中间篡改伪造A和B达到中间人攻击的效果。
DH算法可以和RSA这类非对称算法做签名，从而抵御中间人攻击。 DH算法和ECC算法进行结合升级新的密钥写书协商算法即是ECDH。
证书认证的意义是给公钥加上签名，RSA算法在做密钥协商，或者数据加密时。都可能被中间人给劫持伪造。但是如果有一种技术能够识别，公钥有没有被伪造，那就能够防止中间人攻击。
这样我们很容易联想到我们之前谈论到数字签名技术，因为数字签名不仅能保证数据不被篡改，还能防止抵赖。但是，聪明的你应该很容易联想到，数字签名也是要用公钥算法做签名。怎么保证签名都机构都公钥安全又是另一个问题。
于是，我们想象如果有这样一个机构，他用自己都私钥给客户都公钥进行签名。然后这样都机构公开自己都公钥，因为中间人没有机构都私钥，这样中间人无法伪造签名。就无法伪造客户都公钥了。
这样又有新都问题，我们凭什么想象这个机构。事实到这里，我们确实只能想象这个机构，别无他法。这个机构就是CA机构。
所以，证书其实就是给客户的公钥和信息加上一个数字签名，有了这个数字签名。就没法伪造公钥。
但是，新的问题是，在做数字签名认证时，我们需要用到CA机构的公钥进行认证，如果通过网络的方式去获取公钥，这个公钥有没可能被攻击者劫持，是有可能的。所以比较好的做法是把CA机构的信息内置到操作系统中。不通过网络获取。但是如果CA机构的数量过于庞大，怎么办。所以实际上，CA机构分为 CA根机构 和 CA中间机构。在操作系统中只要内置根证书就行了。通过根证书给下一级机构签名，而中间机构通过网络传输也没有关系，只要更证书是安全的，就能通过签名发现中间机构是否被伪造。这样就解决了传输问题。
通过前面关于密码学的了解。这里可以更深入的去思考握手过程。 这次我们先明确握手的目的，看上图中的过程，握手过程最终是为了数据传输服务的。也就是后续数据传输中的application data过程。
数据传输是在记录层协议中的定义的，关于记录层协议，主要是完成一下的功能：
所以，在握手结束后，一般会采用对称加密算法加密数据，然后做mac认证。握手过程为了给传输数据提供会话密钥。而tls 1.2版本在PRF函数中使用加密基元是 SHA256 算法。
在握手过程中，最终会生成三个密钥分别是：
在前面的握手过程中，我们看到第一个来回，协商了主要的密码套件，并且客户端和服务端交换了以一对随机数，分别是client_random，和server_random。忘记的回去看hello消息的结构。
上面的主密钥是通过PRF函数和随机数计算得来：
PRF(pre_master_secret, "master secret", ClientHello.random + ServerHello.random) [0..47];
计算时间前面提到过，是在校验完证书之后。
以rsa协商为例，预备主密钥，则由客户端随机生成，然后通过公钥发送，也就是client_key_exchange的那个消息中生成。
这里可以根据密码学原理提出几个解答：
为什么是由客户端生成预备主密钥中，通过公钥加密发送。 答：在前面提到的rsa密钥协商中，通过公钥一方去发送密钥信息，第三方无法解密出密钥信息，因为第三方必须用非对称中的私钥去解密，但是私钥是不公开的。相反，如果是通过私钥加密，则由于公钥是公开的，第三方很容易解密得到密钥。
如果是dh算法相关的协商，如何获取到预备主密钥。 答：加入不是rsa作为密钥协商，那么双方会在exchange信息中交换公共信息，然后计算出预备主密钥，预备主密钥就不会进行网络传输。本质上是没有变化的。
在1问题中，通过rsa密钥协商不是会遭遇中间人攻击吗？ 答：密码学章节已经讲过，证书技术是如何防止中间人攻击的，也就是经过证书签名的公钥是安全的，中间人无法伪造。所以不会有中间人攻击。
而会话密钥是记录层中通过主密钥生成的数据。该数据会被拆成几部分，分别用于加密解密，和mac认证。
tls 1.2有两种会话重启的方式，分别：
基于Session Id流程：
基于session的方式，在客户端发送第一个hello的时候，会带上消息中的session_id，该id是在完整握手中由服务器生成，并且保存在服务器内存中。 会话重启中会保留之前的主密钥，会话密钥会重新生成。这样可以防止前向安全性。
这种重启方式有session的通病，就是比较占用服务器资源，因为session是服务器生成并且保存在服务器中。
相比session的重启方式，基于ticket的方式就是在客户端存储会话，服务端不做存储。不过每次重启会更新ticket。流程如下：
参考资料：
前言
https并不是一个协议，通常来说，如果我们说使用了https，意思是说，我们在http上使用了tls协议。 于是，我们可以更进一步的理解到：
为什么我比较强调这种层次概念，因为知识的边界和概念需要划分清晰，在遇到问题，才能知道突破口是在哪。我看大部分关于https文章会一上来就讲一些握手过程，或者密码学原理相关的内容，或者有些文章甚至没有关于协议本书的说明，而是仅仅讲抽象握手过程。我想，这样的理解并没有很结构化的去讲好这样一个东西，所以这也是我写这篇文章的初衷。
为了容易理解，我会把比较结构性内容放在前面，把细节内容放在后面。
宏观看tls
上面一直在讲tls，对于事先没有了解过https的人来说，可能有点迷糊——tls是什么？ 了解过tls的人，应该也知道ssl协议。
从字面意思上来看，这两个东西差不多，实际上，这两个东西也可以认为是一样的概念。tls就是ssl升级之后的版本，在早期时候（1994），为了解决http本身的安全问题，网景公司创建了ssl协议应用于http协议，后来将ssl统一，应用于更广泛的应用层协议，进一步标准化ssl协议，也就是tls协议。
可以把tls当成一层协议看待，那么其于http的关系类似于：
为何需要tls
上面提到，为了解决http存在的安全问题，所以引入tls协议。我们自然会有这样的疑问，是什么样的安全问题，需要在协议上去做文章。
先总结这样三个问题：
数据隐私：http协议是明文传输，也就是说如果中间人劫持请求，很容易理解到http协议传输内容的含义。有人可能会问：那我们平时通过加密传输不就可以解决了吗，为什么需要在协议中大动干戈。这里就需要点密码学的常识，如果仅仅是简单的加密数据，我们有三种可选密码方案，对称加密，非对称加密，单向散列或者mac算法，不管是对称加密和非对称加密，这意味着双方都需要有解密用的钥，对称加密用的是同一个密钥，非对称需要各有一把相对的钥匙。对于web这样面向客户端的传输，在客户端植入密钥明显是不现实的行为，所以可选方案中，密钥怎么安全传输变成了另一个问题，也是tls协议握手协议解决的问题。至于不可逆的加密，比如登录密码本身，对于中间人攻击，其实他并不需要知道你本身数据是什么，这样看似把数据隐私化，实际上并没有达到安全效果。
数据被篡改：如果http协议没法防止被篡改。虽然有消息验证码，数字签名能保证数据完整。但是单纯一个密码技术依然很难防止中间人攻击
身份认证问题：http是无状态协议，所以验证服务端身份是一件重要事情，证书认证也是https安全传输的一环
http确实存在这样一些安全问题，虽然对使用者而言，确实有很多方法去预防安全问题，但是通过分析可以发现，没法用简单的方式，通过单一的一个种密码学算法就能解决这些问题，一般来说，会组合各种密码学算法，这是一个繁琐的工作，所以tls也是将这些繁琐的问题，统一成一个解决方案。
tls协议结构
tls是介于应用层协议和tcp协议纸之间的协议，tls协议可以分成两层协议：
结构如图：
握手协议可以分成四个子协议： 结构如图：
记录层协议是接近tcp协议的底层协议，用来将握手协议定义消息封装和下层协议通讯。
握手子协议
握手协议可以说是tls中最重要的子协议，因为它的职责就是协商出一种合适的 密码套件 。上面也提到，解决一个安全问题不止一种加密算法，密码套件正是一组各种不同功能算法的集合。一般需要两个来回协商完成。
握手协议中以消息为单位，消息格式如图：
一个消息分成是三个部分：
tls协议有十种不同的消息类型，分别是：
握手过程
握手过程一般是两个来回，主要用于交换不同的信息。tls1.2版本的握手过程，大体可以如图这样抽象表示：
可以看到，在经过两个来回之后，客户端和服务端就正式进入数据传输。在握手端来回中，不难发现，一个请求可能会带好几个握手协议不同的消息类型。这是因为，虽然握手协议会把不同消息交给记录层协议，但是记录层协议一般会把几个类型封装成一个数据块发送。
图中的*标记表示该消息会根据不同的密码套件做调整，[]标记表示该协议并不是握手协议定义的内容，但是也会在握手过程中进行。颜色较浅部分属于需要一个集合，绑定发送，这是双向认证需要的环节。
接下来，就细看每一个消息的含义把
Client Hello消息
上面流程图中，客户端首先会发起一个消息，这个消息结构如下：
该数据定义了6个key：
所以说，消息并不是很复杂。
server_hello
服务端的hello信息和客户端一样的结构
具体就不重复描述了。
server certificate消息
这个消息是和上面的hello在一个请求的，可以看到，握手协议发送完server_hello情况以后就会发送certificate消息。但是由于，一些密码套件如DH_anon和DCDH_anon，不会发送该证书，所以该消息是可选的，但是大部分情况，都会用到证书信息。
该消息主要承载证书信息，证书是做身份验证的，该消息结构如下：
可以看到只有一个certificate_list数组，该数组发送的是证书链，用于证书认证。 关于证书细节留到后面去讲述。
server_key_exchange消息
如果certificate消息里的证书信息不足以满足协商加密算法信息要求，会额外发送一个server_key_exchange信息作为补充。有6种密码套件是需要这个消息来发送的，如下：
分割线之前的套件由于使用的临时的 DH/ECDH 密钥协商算法，证书中是不包含这些动态的 DH 信息(DH 参数和 DH 公钥)，所以发送完证书信息之后会追加这个消息对DH信息做补充
分割线下面的两种套件，属于匿名协商，没有证书信息，所以不会有certificate消息，但是由于需要发送额外的静态DH信息，所以会在这个消息里追加发送。
对于不同公钥密码算法细节就不在这里讨论。
certificate_request消息
可以看到，服务器端可能会发送一个certificate_request消息。该消息是可选的，同时是灰色，我用灰色表示，为了说明该消息和其他灰色信息的关系，同时，一般也不会出现。但是在双向认证场景中，由于需要客户端也提供证书，所以服务端会发送这样信息，要求客户端也需要认证证书。
server_hello_done消息
上面流程图，在发送完sertificate和exchange信息之后，服务端会紧接一个server_hello_done类型消息作为结束。之后server会等待客户端后续的工作。该消息结构十分简单：
client_certificate消息
对于客户端的certificate消息，该消息表示，如果在收到服务端发送的消息里，包含certificate_request消息，则客户端会根据自身条件发送证书信息。如果没有客户端没有合适的证书信息，会发送一个空数组。
client_key_exchange消息
该消息无论如何都会发送，这个消息最大的作用是传递pre_master_key,也就是预备主密钥，除了预备主密钥，如果客户端需要发送上面的certificate消息，还会对类型DH算法密钥做补充信息。但是不管怎么，生成pre_master_key是最重要对事，生成对pre_master_key是用于生成master_key的重要前提，生成master_key会在双方拿到pre_master_key之后，在生成master_key之后，便会发送[ChangeCipherSpec]消息，转换状态。这意味着握手过程进入可以加密阶段。
其含义可以参考上面服务端的server_key_exchange
[ChangeCipherSpec]协议
对于1.2版本的，在握手消息中，会涉及到协议状态转换，在1.3版本之后，该协议不在存在，但是为了向下兼容，握手中可能还会有。该协议是用于改变协议状态。
可以理解为，在上述的握手过程中，收到该协议消息的端，状态都为：
在接收到该信息之后，端状态修改为：
该消息表示，在握手过程中，当进入可读可写状态时，表示对端将进入加密阶段，这也意味着，握手环节已经基本完成，具备加密传输的条件。
finished消息
在双方发送完，会对握手中的重要信息进行验证，验证双方会发送自己的校验信息，消息结构如下：
该消息的意义在于：握手过程中所有的子消息都没有加密和完整性保护，消息很容易篡改。为了避免握手期间存在消息被篡改的情况，所以 Client 和 Server 都需要校验一下对方的 Finished 子消息。
完成finish消息之后，最后双方的通讯会以master_key作为对称加密信息的主密钥。
以上，是tls1.2定义的握手内容，当然，还有很多细节没有研究，比如握手中涉及到的随机数，session_id的作用。不过大体的过程已经讲完了，后续慢慢补充一些细节。细节部分则需要一点密码学常识。
细看tls
如果想更深入理解，则需要了解部分密码学相关内容，像上面提到的对称加密，非对称加密，随机数，均属于密码学的内容。
密码学常识
这里简单的介绍几个密码学概念，他们分别是：
随机数算法
随机数作为重要的密码学单元,在密码学中广泛运用到，密码学单元是指：在其他算法中，随机数会产当一个因子的作用。比如生成对称密码和消息验证码。
随机数有三个重要的特性：
三个特性关系可以表示为：
一般我们把具有不可重现性的随机数叫真随机数,把具有不可预知的随机数叫强伪随机数,把具有随机性的随机数叫伪随机数。
只有至少具有强伪随机数特性的随机数算法才能用于密码学。
单向散列函数
单向散列函数即one-way hash function。就是我们常说的hash算法，对于用过md5算法的小伙伴应该不陌生。但是需要注意的是，单向散列函数的作用是保证消息的完整性。
单向散列函数具有这样的特点：
关于强抗碰撞和弱抗碰撞：
通过特点我们可以很容易的知道，单向散列可以用来比较消息的完整性。因为其足够小，足够快，用来校验不同内容是否完整很有用。
缺陷： 当然，这也暴露了，单向散列函数的局限性，就是无法防止被篡改，也无法验证信息的来源。无法防止篡改，是因为攻击者很容易的可以将不同消息生成散列并且伪装。比如中间人攻击。
常见散列算法：
对称加密算法
加密和解密都是用同一个密钥的加密算法，叫对称加密算法。对称加密算法是在传输数据双方持有一个相同的密钥，这种算法需要解决最大问题就是密钥的传输问题。 常见的对称加密有AES，DES。
公钥密码算法
公钥密码算法就是非对称加密算法，由于前面提到的对称加密算法的局限性，所以很自然而然的联想到，是否有一种传输数据双方使用不同的密钥的算法。公钥密码算法的解密模型也很简单：
这里需要提下，公钥加密算法确实有更多可能性，但是我发现很多人有一些理解误区：
目前最常用的公钥加密算法是RSA算法和ECC算法。
关于这两个算法细节，这里就不花时间描述了。ECC算法相对密钥比RSA算法短，同时效率和机密性比RSA高。
公钥加密算法的缺点就是执行效率太慢。
消息验证码（MAC）
消息验证码(message authentication code)是一种确认完整性，并认证的技术。简称MAC算法。
关于mac算法的理解需要结合之前的单向散列算法来看。我们知道，单向散列算法可以保证消息的完整性。
先看看两者的对比。
MAC算法相对单向散列算法而言，多了一个共享密钥才能生成MAC值。这样很容易联想到，如何在网络中传输密钥是MAC算法的一个问题，这个问题和对称加密算法中的问题一样。
那MAC算法相对HASH算法解决了什么问题呢，我们知道，如果中间人攻击了HASH算法生成的HASH值。由于HASH算法和MAC算法不关注消息的机密性，所以中间人可以对消息进行修改，同时用HASH算法重新生成HASH值从而达到篡改数据的效果。虽然MAC算法的密钥如果被中间人劫持，一样会遭受同样的问题，但是我们如果有一种方案，能够保证Mac密钥不被劫持，就能防止中间人攻击，这就是Mac算法存在的意义。
所以，在MAC算法密钥安全的情况下。mac能保证消息完整，同时能够认证，认证的含义是只有持有密钥的人可以生成mac值。
那mac算法的有没有其局限性，除了说mac算法本身不是为了机密性而生之外，mac算法依然无法反正抵赖问题。如何理解抵赖？
我们假设作为第三者角度而言，用mac算法认证的消息虽然是完整的，但是如果有一天有一方对这个消息不承认，由于发送方和接收方都有密钥生成mac值，所以我们无法单从mac值中判断说，这个消息是谁生成的。这就需要用到后面介绍的数字签名技术。
数字签名
数字签名，是一种能够认证消息来源，保证数据准确性，防止篡改的技术。关于数字签名，依然需要和单向散列算法和MAC算法做一个对比。
单向散列算法可以保证消息完整准确性，含义在于只能保证在信息传输中不存在异常。但是无法防止如中间人攻击之类的，篡改数据，同时也无法对消息进行认证。
Mac算法可以保证消息准确同时，因为有一个共享密钥，所以只要保证密钥安全，就能反正数据被篡改，但是由于数据传输双方对密钥是相同的，无法通过第三方得知消息是谁发送的，即不能防止抵赖。
数字签名在借助公钥密码算法的密钥不同的特点，实现了消息认证的机制。原理很简单，就是生成消息的一方通过密钥生成签名，接受消息的一方，可以通过公钥解开消息然后认证消息的正确性。为什么数字签名可以反正抵赖，因为只有持有公钥的人才能验证消息，只有持有密钥的人才能生成签名。这样双方都无法抵赖，同时也能保证消息的完整性，同样能反正篡改。
关于数字签名的简单流程：
由于签名提到非对称加密算法的性能很差，所以上面流程的比对，性能自然也不好，原因是消息的长度可能很长，同时，对于rsa算法而言，需要加密的消息越长，其密钥公钥长度也要越长。聪明同学很容易联想到，使用单向散列算法可以使消息生成简单的hash值，同时，单向散列算法性能也很好。这样就解决了这个问题，所以，一般的签名算法流程优化如下：
补充：这里做一点补充，在数字签名里，非对称加密算法，通过密钥加密生成签名，通过公钥解密验证签名。而在使用rsa做加密操作时，一般会用公钥加密数据传输，而不会通过密钥加密数据传输。原因是因为，公钥是公开对，任何人都可能获得，如果通过密钥加密数据，任何人都可能拿到公钥然后解密。
密钥协商算法
回顾前面的技术，消息认证码（MAC），对称加密，以及用到这些技术的地方，都要强调密钥重要性。但是在网络传输过程中，为了双方都能持有相同密钥。我们会思考如何传输密钥。
这个就是密钥如何配送的问题，关于解决密钥配送问题，有以下几种方式：
这里只讲下DH的简单过程，关于用非对称算法传输密钥很好理解，就不再这里描述：
在上面流程中，G，P，G^AmodP和G^BmodP是四个公开的数字。但是要通过这四个数字算出A，B数是很难的。
生成元G的意义： G的计算是比较复杂的，对于G^XmodP （1 < x < p 内的整数)的所有值都不同时，G就是P的元。而A，B随机取0到P之间的所有整数。这样，A，B有足够多的选择，同时计算有足够多的可能性。
DH算法能防止中间人攻击吗？不能，中间人依然可以通过中间篡改伪造A和B达到中间人攻击的效果。
DH算法可以和RSA这类非对称算法做签名，从而抵御中间人攻击。 DH算法和ECC算法进行结合升级新的密钥写书协商算法即是ECDH。
证书认证
证书认证的意义是给公钥加上签名，RSA算法在做密钥协商，或者数据加密时。都可能被中间人给劫持伪造。但是如果有一种技术能够识别，公钥有没有被伪造，那就能够防止中间人攻击。
这样我们很容易联想到我们之前谈论到数字签名技术，因为数字签名不仅能保证数据不被篡改，还能防止抵赖。但是，聪明的你应该很容易联想到，数字签名也是要用公钥算法做签名。怎么保证签名都机构都公钥安全又是另一个问题。
于是，我们想象如果有这样一个机构，他用自己都私钥给客户都公钥进行签名。然后这样都机构公开自己都公钥，因为中间人没有机构都私钥，这样中间人无法伪造签名。就无法伪造客户都公钥了。
这样又有新都问题，我们凭什么想象这个机构。事实到这里，我们确实只能想象这个机构，别无他法。这个机构就是CA机构。
所以，证书其实就是给客户的公钥和信息加上一个数字签名，有了这个数字签名。就没法伪造公钥。
但是，新的问题是，在做数字签名认证时，我们需要用到CA机构的公钥进行认证，如果通过网络的方式去获取公钥，这个公钥有没可能被攻击者劫持，是有可能的。所以比较好的做法是把CA机构的信息内置到操作系统中。不通过网络获取。但是如果CA机构的数量过于庞大，怎么办。所以实际上，CA机构分为 CA根机构 和 CA中间机构。在操作系统中只要内置根证书就行了。通过根证书给下一级机构签名，而中间机构通过网络传输也没有关系，只要更证书是安全的，就能通过签名发现中间机构是否被伪造。这样就解决了传输问题。
再看握手过程
记录层协议
数据传输是在记录层协议中的定义的，关于记录层协议，主要是完成一下的功能：
所以，在握手结束后，一般会采用对称加密算法加密数据，然后做mac认证。握手过程为了给传输数据提供会话密钥。而tls 1.2版本在PRF函数中使用加密基元是 SHA256 算法。
在握手过程中，最终会生成三个密钥分别是：
在前面的握手过程中，我们看到第一个来回，协商了主要的密码套件，并且客户端和服务端交换了以一对随机数，分别是client_random，和server_random。忘记的回去看hello消息的结构。
上面的主密钥是通过PRF函数和随机数计算得来：
计算时间前面提到过，是在校验完证书之后。
以rsa协商为例，预备主密钥，则由客户端随机生成，然后通过公钥发送，也就是client_key_exchange的那个消息中生成。
这里可以根据密码学原理提出几个解答：
为什么是由客户端生成预备主密钥中，通过公钥加密发送。 答：在前面提到的rsa密钥协商中，通过公钥一方去发送密钥信息，第三方无法解密出密钥信息，因为第三方必须用非对称中的私钥去解密，但是私钥是不公开的。相反，如果是通过私钥加密，则由于公钥是公开的，第三方很容易解密得到密钥。
如果是dh算法相关的协商，如何获取到预备主密钥。 答：加入不是rsa作为密钥协商，那么双方会在exchange信息中交换公共信息，然后计算出预备主密钥，预备主密钥就不会进行网络传输。本质上是没有变化的。
在1问题中，通过rsa密钥协商不是会遭遇中间人攻击吗？ 答：密码学章节已经讲过，证书技术是如何防止中间人攻击的，也就是经过证书签名的公钥是安全的，中间人无法伪造。所以不会有中间人攻击。
而会话密钥是记录层中通过主密钥生成的数据。该数据会被拆成几部分，分别用于加密解密，和mac认证。
会话重启
tls 1.2有两种会话重启的方式，分别：
基于Session Id流程：
基于session的方式，在客户端发送第一个hello的时候，会带上消息中的session_id，该id是在完整握手中由服务器生成，并且保存在服务器内存中。 会话重启中会保留之前的主密钥，会话密钥会重新生成。这样可以防止前向安全性。
这种重启方式有session的通病，就是比较占用服务器资源，因为session是服务器生成并且保存在服务器中。
相比session的重启方式，基于ticket的方式就是在客户端存储会话，服务端不做存储。不过每次重启会更新ticket。流程如下：
参考资料：