一、基础概念

1.HTTP

HTTP (超文本传输协议) 是一种用于客户端和服务器之间传输超媒体文档的应用层协议，是万维网的基础。
简而言之：一种获取和发送信息的标准协议
在这里插入图片描述

2.SSL

安全套接字层（SSL）是一种通信协议或一组规则，用于在网络上的两个设备或应用程序之间创建安全连接。在通过互联网共享凭证或数据之前，建立信任并对另一方进行身份验证非常重要。SSL 是一种技术，您的应用程序或浏览器可能使用该技术在任何网络上创建安全的加密通信通道。
简而言之：一种用于进行身份验证的通信协议

3.TLS

TLS 是 SSL 的直接后继者，所有版本的 SSL 目前均已弃用。但是，使用术语 SSL 来描述 TLS 连接的情况很常见。在大多数情况下，术语 SSL 和 SSL/TLS 都是指 TLS 协议和 TLS 证书。
简而言之：SSL的升级版

4.HTTPS

HTTPS 是在不安全的 HTTP 连接上建立安全 SSL/TLS 协议
简而言之：HTTPS = HTTP + SSL/TLS

5.证书

域名证书：域名证书是针对域名注册的拥有者而言的，它是以电子证书的格式来表现的，标明了注册域名、域名所有人的中文和英文名称、域名注册时间和到期时间等这些内容。
SSL证书：SSL证书是数字证书的一种，是遵守SSL协议的，由受信任的数字证书颁发机构（简称CA）在验证服务器身份后颁发，具有服务器身份验证和数据传输加密的功能。
简而言之：域名证书用于证明域名的归属权。SSL证书用于保护网站的数据传输安全。（域名证书是 SSL 证书的基础）

二、思考

1.HTTP和HTTPS比较

1.1 HTTP在传输时候是明文传输，很容易被他人恶意拦截获取篡改（中间人攻击）

在这里插入图片描述

1.2 https则通过加密手段保证数据的安全。相应的因为在http基础上每次传输都会涉及加密和解密，对应消耗的资源和时耗会增加。

1.3 如果确认服务所在的环境很安全（内网）或者涉及的都是非隐私性数据，则采用http会更好；如果涉及隐私数据则采用https会更好

2.HTTPS具体如何确保数据安全的

简而言之就是使用SSL/TLS加密协议对HTTP通讯协议传输的内容进行加密/解密，即使中途传输内容被人截获了，其获得的也只是加密后的内容，保证了数据安全。
上面说了SSL，其实SSL就是TLS的前身，下文涉及这里的就统一就称为TLS了。

2.1 TLS的对称加密

TLS的核心内容就是对称加密。对称加密就是客户端跟服务端协商好一个对话密钥（预主密钥），每次发送/接收消息都用对话密钥对内容进行加密/解密

如图，
a.客户端和服务端先进行一次会话（Client Hello,Server Hello），协商会话密钥的生成算法和协议版本
b.然后客户侧根据协商好的内容生成会话密钥（预主密钥）并发送给服务端【这一步注意存在隐患，后面会展开讲】
c.再之后客户端和服务端就可以使用会话密钥进行正常对称加密交互了

2.2 TLS的非对称加密

在上面讲TLS的对称加密流程中存在一个隐患点（流程b），就是客户端在传输生成的会话密钥（预主密钥）时，如果这期间被黑客截获，那他就也可以用会话密钥对后序传输的所有内容进行加/解密，先前的所有操作都白搭了。
ps：这里可能会有人问既然a步骤时已经协商好了加密方法和版本，为啥双方直接各自根据协商好的加密方法和版本直接都本地生成会话密钥，就不需要再去传输会话密钥了
首先，如果采取这种形式的话，那黑客直接就在最开始直接截取协商的加密算法和版本号就可以了，黑客也在本地生成对应的会话密钥去加/解密后序的交互内容
其次，其实在Client Hello,生成密钥的过程中客户端会生成俩随机数a、c，Server Hello过程中服务侧会生成随机数b，在生成会话密钥时夹杂这三个随机数进行生成。这样即使黑客知道协商的加密算法和版本也无法计算出最终的会话密钥
回归正题，TLS这里就是通过非对成加密来优化传输会话密钥中泄漏的风险

2.2.1非对称加密

非对称加密的核心内容就是使用公/私钥，内容用公钥加密，只有私钥才能解密出来。私钥自己保留，公钥放开给任何人，别人用公钥对内容加密，自己用私钥进行解密。
在这里插入图片描述

2.2.2 非对成加密实际在TLS中的应用

在这里插入图片描述
a. 服务端在最开始协商版本和加密方法是把公钥也发送给客户端
b. 客户生成会话密钥后用公钥再加密一道，然后发送给服务端
c. 服务端收到被公钥加密过的会话密钥，用私钥进行解密获取原始的会话密钥
d. 后序客户端跟服务端就可以用会话密钥进行交互了
在这个过程中客户端跟服务端并没有传输过会话密钥，所以即使黑客截获到被会话密钥加密的内容，也无法解密到真实数据

3.TLS过程存在的风险

上面讲了TLS的对成加密+非对称加密的全过程，但是这其中还是有一个风险点。公/私密钥对任何人都可以创建，如果过程中黑客将传输的公钥替换成自己创建的公钥，那后序的操作也就都白费了
在这里插入图片描述
如图，假设黑客从一开始就介入，类似中间商黄牛一样。

面向客户端装成服务端，提供给服务端自己的公钥y，用自己的私钥y对客户端发送来的“公钥y加密过的会话密钥”进行解密原始会话密钥
面向服务端装成客户端，拿到服务端的公钥x，将从客户端解密到的“原始会话密钥”用公钥x进行加密再发送给服务端
这样客户端、黑客、服务端最终手上的会话密钥就是一致的了，后序的交互过程就如下
- 客户端数据加密 -> 黑客解密拿到真实数据 -> 黑客使用会话密钥对原始数据/篡改数据加密 -> 服务端解密到黑客发来的原始数据/篡改数据
- 服务端数据加密 -> 黑客解密拿到真实数据 -> 黑客使用会话密钥对原始数据/篡改数据加密 -> 客户端解密到黑客发来的原始数据/篡改数据

4.优化TLS过程中的风险–证书

简而言之，为了优化上面的风险，服务端不要直接传输公钥给客户端。而是替换为有公证力的证书传输给服务端。服务端可以根据证书解析拿到公钥，同时证书也能证明该公钥是没有被人掉包/篡改过的

4.1 证书介绍

证书包含如下内容

Issued To：证书的申请者，即服务侧申请证书时登记自己的身份信息
Issued By：证书的颁发者，有公证力的组织
Validity Period：证书的有效期信息
SHA-256 Fingerprints：证书的指纹信息和登记的公钥
- 指纹码：证书的唯一标识（保证证书的完整性）。被Hash加密过
  
  服务侧拿到证书需要确保两个事情才能信任证书
  1.证书的完整性：证书在传输过程中是否被人截获修改篡改过？比如证书被黑客拦截，对里面的内容进行了修改（数据篡改）
  2.证书的可信性：证书虽然是完整的，但不知道这个证书是否为客户端发送的被公证过滴证书？比如真正的证书a被黑客拦截，黑客再给服务端换成自己生成的证书b发送过去（证书调包）
  这两种情况分别需要使用证书指纹、数字签名来验证

4.2 证书指纹

指纹码：证书的唯一标识（保证证书的完整性）。被Hash加密过

hash加密不可逆且具有唯一性，即无法根据加密后的内容反解析出初始内容，不同的初始内容加密后不可能得到相同的加密串。那么服务侧对原始内容hash后进行比对，如果不一致则代表当前证书中途被人篡改过内容

4.3 数字签名

用于验证证书身份的真实性

我们之前都是对内容公钥加密，私钥解密。数字签名这里相反，会把内容进行私钥加密，公钥解密
权威机构CA颁发证书时候，会用私钥对证书加密，然后颁发出去。服务端拿到加密证书后，再用公钥解密证书，获取证书信息。如果解密成功，说明手上的公钥和证书加密使用的私钥为一对，即说明该加密证书确实为权威机构所颁发的那个证书
电脑一般安装的系统/浏览器内都自带有由权威机构颁发的证书验证公钥，即不需要从网络上传递公钥，也就不存在证书公钥被泄漏的风险
ps：思考题：全网那么多域名需要申请证书，又有那么多权威CA机构。总不能在系统和浏览器里都预装所有证书验证公钥吧？
a.CA机构也是分级的，浏览器和系统只需要预装根CA机构的公钥；
b.用根CA公钥解密中间CA的【A类证书】（这里的证书指的是根CA 颁发给中间CA 验证中间CA机构权威性的证书）；
c.然后从A类证书里拿到下一级证书的公钥（这里的下一级如果是更次级的中间CA，则类推继续到下一级，直到拿到验证服务端域名的【B类证书】），