HTTPS协议的SSL握手过程
HTTPS常被定义为为 HTTP over SSL ，超文本传输安全协议。
以往HTTP通讯直接使用的明文传输，容易被人抓包，破解数据包，而 HTTPS 经由 HTTP 进行通信，但利用 SSL/TLS 来加密数据包。
HTTP的URL由“http://”起始且默认使用端口80，
HTTPS的URL由“https://”起始且默认使用端口443。
注意：
SSL是一个介于HTTP协议与TCP之间的一个可选层，为数据通讯提供安全支持。SSL协议可分为两层：
如果用右边的TCP/IP协议来划分，SSL是属于应用层与传输层之间的协议，如果还是用OSI七层协议划分，SSL是属于表示层与会话层的。
以下是SSL协议握手的一个主要过程，主要分为4个阶段。
此时，client和server都持有3个随机数，客户端和服务端用商定的算法利用3个随机数生成一个 对话密钥（session key） ，随后的通信就用这个密钥进行加密解密。之所以用3个随机数，因为证书是静态的，增加随机数可以使得密钥更加有随机性。SSL协议传输过程中，使用的是由相同的3个随机数生成的 对话密钥（session key） ，而生成的规则是client与server商议好的算法，所以这个 对话密钥（session key） 是相同的，这个加密方法称为 对称加密 。
HTTPS通讯也不一定是绝对安全的，有可能会被人劫持，如路由，代理，防火墙，通常是中间人攻击。所谓中间人，就是攻击端欺骗服务端，伪造成客户端。反过来欺骗客户端，伪造成服务端。
简单过程如下
中间人攻击一般发生在SSL握手协议中，协商密钥的时候（非对称加密阶段），中间人攻击的主要目的是要欺骗客户端，与客户端协商生成最后的对话密钥（3个随机数生成），这样客户端的数据经过这个对话密钥加密后，就可以被中间人轻易解密出来。所以中间人攻击必须得使用自己证书（包含公钥）进行握手，这样才能有自己的私钥解密出客户端发过来的随机数。
如果客户端与服务端会话初始化完成，开始进行数据通讯（对称加密阶段），想要完成中间人攻击是非常困难的。
防御中间人攻击的手段是做好证书的校验，一般来说，客户端收到了服务端下发的证书，对证书的颁发机构、有效期等进行严格校验（证书是验证服务端身份合法与否的唯一方式）:
Charles其实是扮演一个中间人的角色，就是上述的中间人攻击。客户端选择信任并安装Charles的CA证书，否则客户端就会“报警”并中止连接。这样看来，HTTPS还是很安全的。
大概示例图如下
如果需要App进行抓包调试，一般需要设置Mode为AFSSLPinningModeNone。
加密和解密可以使用不同的规则，只要这两种规则之间存在某种对应关系即可，这样就避免了直接传递密钥。这种加密模式被称为"非对称加密算法"。RSA算法一直是最广为使用的"非对称加密算法"，2048位的密钥极其安全。SSL握手过程，客户端使用服务端的公钥解密随机数，服务端使用私钥解密出随机数的过程就是非对称加密。
http://www.nsfocus.net/index.php?act=magazine&do=view&mid=841
https://www.jianshu.com/p/9c52693a09dc
https://www.jianshu.com/p/405f9d76f8c4
2023-03-08 · 百度认证:安徽斯百德信息技术有限公司
安信SSL证书
第二步：服务端收到请求以后也会给客户端发一个server hello请求，请求中会告诉客户端它选择的协议版本、加密套件、压缩算法以及一个随机数。
第三步：服务端会给客户端发一个server certificate请求，里面包含服务端的数字证书，用于客户端进行校验。
第四步：服务端会给客户端发一个server hello done告诉客户端信息已发送完毕。
第五步：客户端收到证书以后进行校验获取到服务端的公钥。
第六步：客户端会将自己的数字证书发给服务端用于校验。
第七步：客户端计算出一个随机数pre-master,然后用公钥进行加密发送给服务器端。
第八步：服务端和客户端都根据自己的随机数+对端的随机数+pre-master算出对称密钥，然后再根据对称密钥进行通信。
2023-03-14 · 百度认证:Gworg官方账号,科技领域创作者
Gworg
关于SSL/TLS握手如何工作的一些混淆是由于握手只是实际的、安全的会话本身的前奏。让我们尝试解决一些共同点：
非对称与对称加密
握手本身使用非对称加密——使用两个单独的密钥，一个公钥，一个私钥。由于非对称加密系统的开销要高得多，因此它们不能用于提供全时的、真实世界的安全性。因此，仅在握手期间使用公钥进行加密，使用私钥进行解密，这允许双方秘密地设置和交换新创建的“共享密钥”。会话本身使用这个单一的共享密钥来执行对称加密，这就是使安全连接在实际实践中可行的原因（开销大大降低）。因此，“SSL/TLS加密是非对称的还是对称的？”的完整而正确的答案是“第一个，然后另一个”。
什么是“密码套件”？
握手本身有多个阶段，每个阶段根据不同的规则进行管理。细节可以在这里找到，但它的核心是，而不是一系列单独的来回协商（关于使用什么密钥，如何加密握手本身，如何验证握手等等）各方可以同意使用“密码套件”——预先存在的选择或商定组件套件。（请记住，非对称加密在时间和资源方面都非常昂贵——使用密码套件作为快捷方式可以加快握手本身的速度。）TLS规范允许使用相当多的密码套件，并且客户端和服务器几乎总是可以访问他们都可以雇用的人。
基本与相互认证的握手
另一个令人困惑的地方是，我们上面描述的基本模型让客户端验证服务器，而绝大多数受TLS保护的会话只需要这样做。但是，一些密码套件会要求客户端同时发送证书和公钥以供双方相互验证。这种双向身份验证当然会增加握手的开销——但是，在某些情况下（例如，两家银行正在协商资金转账的安全连接）密码套件会坚持这样做，并且额外的安全性被认为是值得的它。
不同的会话会有不同的安全参数
每次新的握手都会创建一个新的会话，并且根据所选的密码套件，一个会话中使用的设置可能与另一个会话有很大不同。这就是该死的握手图存在如此多不同迭代的原因之一，也是我们在这里给出相当广泛的概述的原因之一。还要知道会话可以设置可能与您期望的不完全相同的参数。根据密码套件的不同，可能会添加一些步骤（例如双向身份验证的要求）或不添加。事实上，实际上有密码套件协商会话以不使用任何加密。（是的，我们知道，决定以明文方式发送数据的端口443上的HTTPS连接对我们来说也毫无意义。
