服务器（被）认证阶段
客户端 -> 服务器：客户端发送ClientHello（包括SSL版本，随机数Random_C，支持的加密算法Cipher Suite等），开始一个新的会话连接；
客户端 <- 服务器：服务端响应，发送ServerHello，生成主密钥所需信息（包括SSL版本，随机数Random_S，选择的客户端支持的加密算法Cipher Suite等）；
客户端 -> 服务器：客户端验证证书的合法性，通过后，生成主密钥Pre-master，用证书的公钥（服务器的公开密钥）加密后，发送给服务端；
计算得到协商密钥enc_key=Fun(random_C, random_S, pre_master)；
客户端通知服务器后续通信都采用协商的通信密钥和加密算法。
用协商密钥和加密算法对一段信息加密得到encrypted_handshake_message，发送给服务器用于数据和握手验证；
客户端 <- 服务器：服务端返回一个用主密钥认证的信息。
服务器用私钥解密得到pre_master，计算得到协商密钥enc_key；
解密客户端发过来的encrypted_handshake_message，验证数据和密钥的准确性。
验证通过后，服务器通知客户端后续通信都采用协商的通信密钥和加密算法。
用协商密钥和加密算法对一段信息加密得到encrypted_handshake_message，发送给客户端。
该服务器成功被客户端认证。
用户（被）认证阶段
客户端 <- 服务器：服务端发送一个提问给客户；
客户端 -> 服务器：客户端返回（数字签名后的）提问，和其公开密钥，从而向服务端提供认证。
TLS
传输层安全性协议（英语：Transport Layer Security，缩写作TLS），及其前身安全套接层（Secure Sockets Layer，缩写作SSL）是一种安全协议，目的是为互联网通信提供安全及数据完整性保障。
https://blog.csdn.net/English0523/article/details/81781405
HTTPS是HTTP+SSL/TCP的简称。
https://www.jianshu.com/p/fb6035dbaf8b
https要解决的是网络连接和数据传送中的3个问题：
- 1. 数据的保密性：随机密钥+非对称加密+对称加密
对数据进行加密实现。包括对称加密，比如DES、AES；
非对称加密，比如RSA、ECC等。
需要有2个密钥，公钥和私钥。公钥向所有人公开，私钥不公开。用公钥加密的数据只有私钥才能解密；反之，用私钥加密的数据只有公钥才能解密。因为这种特性，非对称加密算法可以用来校验数字签名，
注：如果只用非对称加密的方案，意味着客户端A用公钥加密的数据，其他客户端无法解密，因为没有解密的私钥；而服务端B用私钥加密的数据，拥有同一个公钥的其他客户端都可以读取。
HTTPS的解决方案
客户端用非对称算法加密得到一个随机的对称密钥，然后双方用对称密钥进行通信。
具体来说，一是握手阶段：就是客户端生成一个随机密钥（对称密钥），用服务器的公钥对这个密钥进行非对称加密，发送给服务端；服务器用私钥进行解密得到协商的通信密钥；
二是通信阶段：双方就用这个对称密钥（协商的通信密钥）来进行数据传输的加密。
- 2. 校验双方身份的真实性：数字证书
数字证书就是身份认证机构（Certificate Authority）盖在数字身份证上的一个签名，这一行为表示身份认证机构已认定这个人。证书的合法性可以向CA验证。
数字证书主要包含以下信息：
证书颁发机构
证书颁发机构签名
证书绑定的服务器域名
证书版本、有效期
签名使用的加密算法（非对称算法，如RSA）
公钥
- 3. 数据的完整性：数字签名校验
哈希算法+非对称加密/解密
在通信阶段，每一次数据传输都会通过校验数字签名保证数据的完整性吗？
注：会，但是用哈希算法+对称加密/解密的方案。
https://www.jianshu.com/p/6825d6c4bca6
如何发布https服务？
https://blog.csdn.net/itchuangyi/article/details/82832366
没有证书还算是https吗？
算，没有证书指的是没有使用CA认证的证书，服务端还是有自签名的证书。客户端请求使用httpclient可以设置忽略证书，其实是忽略了CA校验证书这一步，但是握手和加密通信还在。
如何评价平安的https
https://www.jianshu.com/p/f20ed83aa0dc
平安应该是在其web服务器上生成和配置了无CA证书的自签名证书。
如何评价平安的数字签名
客户端的部分
对请求体做hash加密生成固定长度的密文A1，加密算法SHA-256。
对请求方法类型（POST）+请求地址+请求头（Content-Type，X-Appid，X-Deviceid，X-Timestamp）+请求体密文A1拼接；通过加密算法生成签名；把签名放到请求头（X-Authorization）。
生成签名的加密算法：拼接数据；对拼接数据做SHA-256加密得到密文；通过密钥appkey对密文做SHA-256加密得到签名，加密算法MAC（该算法需要密钥）。
服务端的部分
平安受到请求后，获取请求头的appID，通过appID获取存储的对应的appkey，再对请求头和请求体明文做同样的加密算法得到签名，通过比对两个签名校验数据的一致性。
所以，平安的数字签名方案可以解决数据一致性的问题。如果是明文传输，不是解决数据加密的问题。因为有密钥appkey，所以可以防中介攻击（一致性）的问题。
签名一般都是用于解决数据一致性的问题，身份校验的问题。一般签名都是通过不可逆的摘要算法，hash算法得到，长度固定。
Md5的作用
https://blog.csdn.net/junmoxi/article/details/80841555
https://blog.csdn.net/qq_30683329/article/details/80879058
https://blog.csdn.net/carol980206/article/details/96705859#_212
Md5是一种摘要加密算法，对明文加密后得到固定长度的密文。
应用的场景：客户端把请求体，比如密码，做md5加密得到密文A1，把密文A1发送给服务端，服务端用存储的密码做md5加密得到密文A2，对比A1和A2是否一致。
所以应用场景的限制是服务端已有明文。
如何评价平安的md5的作用？
Hash算法测试，能解决我的问题吗
问题：用户输入的文本太长，超过了服务端对应的字段长度。
方法：对用户输入的文本加密得到固定长度的密文，发给服务端，服务端解密后得到明文。要求密文长度短。
Hash算法是不可逆的，所以不能解决。
和Token的关系？能解决我的问题吗：中间人攻击
问题：中间人获取到服务端返回的响应（明文），比如是否通过校验字段，通过修改服务端的响应的字段（比如：不通过->通过）给前端，前端调到下一页，而不是报错。
Token解决的是身份认证的问题，问题是数据一致性的问题，所以没有解决。
抓包工具的使用
https://www.jianshu.com/p/405f9d76f8c4
Charles，Fiddler
Burp Suit Professional v2.1.03
https://blog.csdn.net/u013291076/article/details/90081313
https://www.xcnte.com/archives/426/