简介
SSL(Secure Socket Layer)最初在OSI网络模型中位于传输层和应用层之间，被称为安全套接字层。主要是通过CA和加密算法实现对身份的认证和防止数据被修改。
SSL/TLS协议的三个特性
保密：在握手协议中定义了会话密钥后，所有的消息都被加密。
鉴别：可选的客户端认证，和强制的服务器端认证。
完整性：传送的消息包括消息完整性检查(使用MAC)。
TLS和SSL
SSL最初提出的时候存在很多安全隐患，在SSL更新到3.0时，IETF对SSL3.0进行了标准化，并添加了少数机制(但是几乎和SSL3.0无差异)，标准化后的IETF更名为TLS1.0(Transport Layer Security 安全传输层协议)。
可以说TLS就是SSL的新版本3.1，并同时发布“RFC2246-TLS加密协议详解”，如果想更深层次的了解TLS的工作原理可以去RFC的官方网站：www.rfc-editor.org，搜索RFC2246即可找到RFC文档！
TLS和HTTP
SSL最初提出是为了解决HTTP是明文传输这个问题，后来因其安全性很好，也被应用在了别的协议和内容上，比如邮件协议SMTP和POP3也支持TLS，任何可以在TCP上承载的协议，都可以使用SSL/TLS协议加以保护。
故一般可以认为：HTTPS = HTTP + SSL/TLS
即对HTTP的内容用TLS进行了加密处理，HTTPS默认端口为443，HTTP默认端口为80。
TLS的发展历史
- 1999年IETF将SSL标准化(RFC 2246)，并将其称为TLS(Transport Layer Security)
- TLS 1.1版本在2006年4月发表，是TLS 1.0 的更新(RFC 4346)
- TLS 1.2版本在2008年8月发表，是目前的主流版本(RFC 5246)
- 2020 年主流Web 浏览器都将禁用TLS 1.0 和TLS 1.1 安全协议
- 2018年8月，TLS 1.3标准正式发布 （RFC 8446），相比于TLS 1.2有 两个主要的优势：
- 性能提升：连接时间大幅缩短
- 安全性提升：删除不安全的加密算法
TLS协议结构
TLS的协议结构主要分成两层，下层是记录协议层，上层是SSL握手协议层，握手协议层主要包含握手(Handshake)，密码变化(ChangeCipherSpec)，警告(Alert)，应用(Application)
SSL记录协议层的作用是为高层协议提供基本的安全服务。SSL纪录协议针对HTTP协议进行了特别的设计，使得超文本的传输协议HTTP能够在SSL运行。纪录封装各种高层协议，具体实施压缩解压缩、加密解密、计算和校验MAC等与安全有关的操作。
SSL握手协议层包括SSL握手协议（SSL HandShake Protocol）、SSL密码参数修改协议（SSL Change Cipher Spec Protocol）和SSL告警协议（SSL Alert Protocol）。握手层的这些协议用于SSL管理信息的交换，允许应用协议传送数据之间相互验证，协商加密算法和生成密钥等。
SSL握手协议的作用是协调客户和服务器的状态，使双方能够达到状态的同步。
下图摘自[曹世宏的博客][https://blog.csdn.net/qq_38265137/article/details/90112705]
ChangeCipherSpec协议
- 工作在Handshake完成后，通知服务器后续的通信都采用协商的通信密钥和加密算法进行加密通 信，内容一般是固定的。
Alert协议
- 允许通信双方发送错误或问题警告。
Application协议
- 工作在TLS会话建立后， 在通信双方进行加密数据的传输。
握手Handshake协议
Handshake协议主要功能
工作在TLS通信的启动阶段，进行通信双方的密钥协商、身份认证、会话建立等工作。
客户和服务器之间相互认证
协商加密算法和密钥
提供连接安全性，有三个特点
- 身份认证，至少对一方实现认证，也可以是双向认证
- 协商得到的共享密钥安全，中间人不能知道
- 协商过程可靠
Handshake协议主要结构
用来进行密钥协商，身份验证的。
是SSL/TLS协议中最关键的、最复杂的一个子协议。
Handshake协议报文被Record Head所封装。
Handshake协议内部有自己的结构。
其中Type记录了Handshake协议报文的消息类型，Content是与消息相关的参数
记录Record协议
Record协议主要功能
建立在可靠的传输协议(如TCP)之上
TLS报文的首部，封装其他4个协议，并提供加密，压缩，消息验证功能
提供连接安全性，有两个特点
- 保密性，使用了对称加密算法
- 完整性，使用HMAC算法
Record协议格式
Content type：封装的TLS子协议的类型
Version：TLS协议的主版本号和次版本号
Length：TLS报文的大小
TLS运行机制
SSL/TLS主要分成两个阶段
- SSL建立的第一阶段：Handshake phase（握手阶段）
- 协商加密算法
- 认证服务器
- 建立用于加密和MAC（Message Authentication Code）用的密钥
- SSL建立第二阶段：Secure data transfer phase（安全的数据传输阶段）
- 在已经建立的SSL连接里安全的传输数据
接下来主要介绍TLS的“握手Handshake阶段”，结合图对应过程。
下面这张图摘自阮一峰大佬的博客，详细的描述了TLS的“握手阶段”，需要注意的是，”握手阶段”的所有通信都是明文的。
第一步，客户端发出请求（ClientHello）
Client Hello：客户端向服务器请求TLS加密通信连接
Client Hello消息里包含了一个客户端生成的随机数 Random1、客户端支持的加密套件（Support Ciphers）和 SSL Version 等信息。
Version: 协议版本指示客户端支持的最佳协议版本
Random:
- 32 字节，前4字节是GMT Unix 时间戳，后28字节是随机数
- 客户端的记作random_client，用于密钥协商计算master key
Session ID
- 初次连接时，session ID字段不存在
- 如果Client Hello中session ID字段存在，表示客户端之前跟服务 器连接过，现在恢复之前的会话，称为TLS复用
Cipher Suites: 密码套件
- 由客户端支持的所有密码套件组成的列表，该列表是按优先级顺序排列的，供服务器选择一个作为此次TLS连接的密码算法组合
Extensions: 扩展
- 由任意数量的扩展组成。这些扩展块说明额外的信息
- 其中重要的一个扩展就是：server_name(SNI)。用于表示所请求服务的域名
Compress method压缩方法
- 一般不启用
第二步，服务器回应（SeverHello）
Server Hello：用于服务器回应客户端的Client Hello
收到客户端问候之后服务器必须发送服务器问候信息，服务器会检查指定诸如TLS版本和算法的客户端问候的条件，如果服务器接受并支持所有条件，它将发送其证书以及其他详细信息，否则，服务器将发送握手失败消息。
如果接受，第二步是服务端向客户端发送 Server Hello 消息，这个消息会从 Client Hello 传过来的 Support Ciphers 里确定一份加密套件，这个套件决定了后续加密和生成摘要时具体使用哪些算法，另外还会生成一份随机数 Random2。注意，至此客户端和服务端都拥有了两个随机数（Random1+ Random2），这两个随机数会在后续生成对称秘钥时用到。
Certificate: 在服务器回应客户端Server Hello之后，随机发送服务器 X.509 证书链，供客户端验证
一般情况下，除了会话恢复时不需要发送该消息，在SSL握手的全流程中，都需要包含该消息。消息包含一个X.509证书，证书中包含公钥，发给客户端用来验证签名或在密钥交换的时候给消息加密。
这一步是服务端将自己的证书下发给客户端，让客户端验证自己的身份，客户端验证通过后取出证书中的公钥。
ServerKeyExchange（可选）: 服务器发送密钥协商参数，提供证书私钥的签名供证客户端验证
ServerHelloDone作用: 服务器的密钥协商，身份认证信息发送完毕，等待客户端回复
第三步，客户端回应
这一步主要包含ClientKeyExchange，ChangeCipherSpec，Finished，如果服务器端要求客户端提供证书，也是在这一步
ClientKeyExchange: 客户端校验服务器证书，进行密钥协商。
根据服务器发送的X.509证书链，用证书的公钥解密服务器ServerKeyExchange报文的Signature，检查服务器的身份；检查证书是否过期，域名是否匹配等。服务器身份验证成功后客户端发送ClientKeyExchange。
客户端生成pubkey_client，结合ServerKeyExchange中的pubkey_server通过某个算法生成一个随机数pre-master，注意这里是第3个随机数，前两个分别是在client hello和server hello中出现的随机数random1和random2
根据随机数pre-master和Client Hello、Server Hello中的random_client和random_server生成master key
Pubkey: 发送给服务器，让服务器也能通过独立计算得到master key
ChangeCipherSpec作用:
编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送（ChangeCipherSpec是一个独立的协议，体现在数据包中就是一个字节的数据，用于告知服务端，客户端已经切换到之前协商好的加密套件（Cipher Suite）的状态，准备使用之前协商好的加密套件加密数据并传输了）
告知通信对端之后的通信都采用协商的密钥与算法进行加密。
TLS1.3规定可发送也可不发送。
Finished作用
- 用于开启加密通信的第一个报文，验证Handshake过程中信息没有被篡改，并且确认通信双 方得到的对称加密密钥是一致的。
第四步，服务器的最后回应
这一步主要涉及到ChangeCipherSpec和Finished，和第三步类似
服务器收到客户端的第三个随机数pre-master key之后，计算生成本次会话所用的”会话密钥Session Secret”。然后，向客户端最后发送下面信息：
- ChangeCipherSpec：编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送。
- Finished：服务器握手结束通知，表示服务器的握手阶段已经结束。这一项同时也是前面发送的所有内容的hash值，用来供客户端校验。
四步结束后，TLS“握手”完成，可以将应用层内容通过TLS，用之前商量好的加密套件和会话密钥加密，再在TCP等协议上进行传输。
为什么需要3个随机数？
来自[ssl协议中的dh算法的pre-master-secret - dog250的CSDN博客][https://blog.csdn.net/dog250/article/details/5717162]
“不管是客户端还是服务器，都需要随机数，这样生成的密钥才不会每次都一样。由于SSL协议中证书是静态的，因此十分有必要引入一种随机因素来保证协商出来的密钥的随机性。
对于RSA密钥交换算法来说，pre-master-key本身就是一个随机数，再加上hello消息中的随机，三个随机数通过一个密钥导出器最终导出一个对称密钥。
pre master的存在在于SSL协议不信任每个主机都能产生完全随机的随机数，如果随机数不随机，那么pre master secret就有可能被猜出来，那么仅适用pre master secret作为密钥就不合适了，因此必须引入新的随机因素，那么客户端和服务器加上pre master secret三个随机数一同生成的密钥就不容易被猜出了，一个伪随机可能完全不随机，可是是三个伪随机就十分接近随机了，每增加一个自由度，随机性增加的可不是一。”
其他相关
CA
CA，Certificate Authority，即证书颁发机构，CA上面还有CA，直到root CA
在浏览器查看公钥证书
加密算法
虽然学过密码学，但是现在唯一记得的就是RAS基于大质数分解的难点了
TLS中用到了对称加密和非对称加密
常见的对称加密：DES（基本不用），3DES，AES
常见非对称加密：RSA，ECC，DSA，ECDSA（ECC结合DSA）
wiresshark捕包
一般组里要求对于TLS，看其sni特征（client hello里），TLS版本号，SSL证书（certificate里）
参考：
[HTTPS、SSL、TLS三者之间的联系和区别- 天府云创的CSDN博客][https://blog.csdn.net/enweitech/article/details/81781405]
[SSL/TLS协议运行机制的概述][http://www.ruanyifeng.com/blog/2014/02/ssl_tls.html]阮一峰大佬的博客，用精简的语言讲清了TLS
[SSL协议详解 - 曹世宏的CSDN博客][https://blog.csdn.net/qq_38265137/article/details/90112705]非常好的博客，图文并茂，包含了更详细的信息，也是本文主要参考（抄抄）对象，非常感谢！！！！！
[ssl协议中的dh算法的pre-master-secret - dog250的CSDN博客][https://blog.csdn.net/dog250/article/details/5717162]
感谢李舒老师的slides，真的太详细了