参考说说SSL/TLS协议 - 简书 (jianshu.com)
基本概念
-
HTTP：是一个客户端和服务器端请求和应答的标准（TCP），超文本传输协议。
-
HTTPS：是HTTP的安全版，即HTTP下加入SSL层，HTTPS的安全基础是SSL/TLS。加密传输、身份认证
区别
- https协议需要到ca申请证书
- http是超文本传输协议，信息是明文传输，https则是具有安全性的ssl加密传输协议
- http和https使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443
- http的连接很简单，是无状态的；HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，比http协议安全。
为什么使用SSL/TLS(SSL是TLS前身)
明文通信，三大风险：
- 窃听风险
- 篡改风险
- 冒充风险
SSL/TLS怎么解决以上问题：
- 防窃听：通信过程加密
- 防篡改：具备校验机制，一旦被篡改，通信双方会立刻发现
- 防冒充：配备证书，防止被冒充
工作原理
使用公开密钥加密算法（非对称加密算法）为基础对通信双方进行认证，并协商出一套用于后期对称加密的密钥和算法。
对称加密
对称加密算法加密速度快，而且很安全，因此可被用作数据传输的加密算法。 但是其薄弱点是如何在通信双方之间安全的共享密钥，即密钥分发问题。
因此我们需要在非安全的通信信道上协商出一个安全的密钥用于后续采用对称加密进行通信使用（即使通信过程被第三方截获，但是只有通信双方才知道的密钥）。
为了解决这个问题，协议设计者引入了公开密钥加密算法（即非对称加密），利用该算法作为基础，可以在非安全的传输通道上协商出一个安全的通信密钥。
单独使用公开密钥加密
-
A含有一对密钥，公钥公开，私钥保留。
-
B使用A的公钥加密信息发给A，A用其私钥解开。即使C截获了B发给A的信息，但是由于其没有A的私钥，因此其无法解开。
-
B向A发消息是没有问题的，但是A向B发送经过A私钥加密后的消息还是可以被C解开（因为A的公钥是公开的，C可以使用A的公钥解开A发送给B的消息）
所以，单纯使用公开密钥加密是不行的，可利用公开密钥加密算法协商出一套后期双方通信的密钥，并且保证即使第三方知道双方通信的过程，依然无法知晓后期通信的真正密钥。
密钥协商过程
-
Bob 生成一个随机数a，使用Alice公钥加密成A后发送给Alice（Charlie无法将A解密成a，因为它没有Alice私钥）
-
Alice生成一个随机数b，使用Alice私钥加密成B后发送给Bob（Charlie可以利用Alice的公钥将B解密成b）
-
Bob再生成一个随机数c，使用Alice的公钥加密成C后发送给Alice（Charlie不知道C）。这一步，Bob和Alice都知道三个数（a、b、c），但Charlie只知道b
-
然后，Bob和Alice分别使用一个已知算法PRF，对三个随机数a、b、c进行计算生成最终的共享密钥K，后期通信就使用K进行。
由于K没有明文传输，且攻击者由于没有获取到足够信息也无法生成，每次协商都生成不同的密钥。因此具有很强的安全性。
中间人攻击
以上协商过程还存在漏洞：中间人攻击。 伪装服务器用自己的公钥与私钥跟客户端通信。
解决办法：
- 提供一个由权威机构（CA）颁发的证书来证明这个公钥就是属于服务器的。 服务器发送给客户端的不再是单纯的公钥，而是由CA认证的证书，这个证书里面包含了服务器的公钥，发行机构信息（CA），以及证书持有者（服务器），还有CA的签名，证书有效期 客户端相信CA，从而可以相信CA颁发的证书，从而相信其拿到的公钥就是服务器的公钥，从而相信和它通信的就是服务器（因为只有服务器才有私钥）
验证可靠性
系统里面预装根证书，或者用户自己安装根证书，根证书是CA自己给自己颁发的证书。这个信任靠得就是平台本身和用户自己。 如果CA在你信任的CA表里面，那么说明是受信任的。
验证完整性
完整性校验依赖于数字签名。 证书上面有CA的签名。
签名生成过程： 利用HASH算法对证书内容计算出HASH值，然后CA用自己的私钥对HASH进行加密，这就是CA对该证书的签名。
校验： 利用CA的公钥（根证书里面有）对签名进行解密，得到的就是解密后的HASH值 利用HASH算法对证书内容计算出HASH，和上一步解密后的HASH对比，如果不一致则认为被篡改。
为啥篡改者不连签名也一起改了？ 因为它没有CA的私钥。
还有证书有效期检查。
实际协议过程：
先进行TCP握手，三次，再进行SSL握手，九次
握手目的：
- 协商加密套件
- 认证通信方（可选）
- 基于协商好的加密机制构建信息安全
