HTTPS主要是在HTTP的基础上用TLS/SSL进行加密,当时候我自己弄完网站后,腾讯云问我需不需要TLS加密技术,用了这个之后我的就是https了

SSL是TLS的前身,它们俩都是加密安全协议

1.HTTP与HTTPS的区别

1. HTTP是超文本传输协议,信息是明文传输,存在安全风险的问题。HTTPS则解决了HTTP不安全的陷阱,在TCP和HTTP网络层之间加入了SSL/TLS安全协议,使得报文可以安全加密传输
2. HTTP的建立相对简单,只需要在传输层中进行TCP的三次握手就可以了。但是HTTPS的建立需要在TCP三次握手之后再进行一个SSL/TLS的握手过程,才可以进行加密报文传输
3. 两个默认的端口不一样,HTTP默认的端口是80,HTTPS的默认端口是443
4. HTTPS 协议需要向 CA（证书权威机构）申请数字证书，来保证服务器的身份是可信的。一般免费证书较少，因而需要一定费用。

2.HTTPS解决了HTTP的哪些问题

因为HTTP是明文传输,所以安全上存在下面3个风险

1. 窃听风险,比如通信链路上可以获得通信内容,用户号容易丢失
2. 篡改风险,比如强制植入垃圾广告,用户眼容易瞎
3. 冒充风险,比如冒充淘宝网站,用户钱容易没

为了解决这3个风险,我们采用以下三个方法

1. 混合加密,它可以保证信息的机密性,解决了窃听的风险
2. 摘要算法,它可以保证信息的完整性,它能够为数据生成独一无二的指纹,用于校验数据的完整性,解决了篡改的风险
3. 将服务器的公钥放入到数字证书中,解决了冒充的风险

混合加密主要是把对称加密和非对称加密两个给结合起来

现在我们来看看什么叫对称加密,非对称加密

2.1加密算法

2.1.1对称加密

对称加密是指在加密和解密过程中使用相同的密钥，也称为共享密钥加密。在HTTPS中，对称加密用于加密和解密实际的数据传输。具体而言，HTTPS使用一种称为“对称加密算法”的算法来加密通信过程中发送的数据。该算法使用一个密钥来加密数据，并使用相同的密钥来解密数据。因此，需要确保密钥在发送方和接收方之间是安全和私密的。

可以看这张图片,我们在加密和解密的过程中使用完全相同的密钥

刚才说了要将原数据变成密文我们不仅需要密钥还需要相应的加密算法

2.1.1.1对称加密的加密算法

DES（56 位密钥，密钥太短⽽逐渐被弃⽤）、AES（128 位、192 位、256 位密钥，现在最流⾏）

2.1.1.2对称加密的作用

加密通信,防止信息在不安全网络上被截获后,信息被人读取或者篡改

2.1.1.3对称加密的破解

• 拿到⼀组或多组原⽂-密⽂对
• 设法找到⼀个密钥，这个密钥可以将这些原⽂-密⽂对中的原⽂加密为密⽂，以及将密⽂解密为原⽂的组合，即为成功破解

2.1.1.4对称加密的缺点

不能再不安全网络上传输密钥,一旦密钥泄漏,则很快可以破解你的原文,通信加密失败

2.1.2非对称加密

不同于刚才我们的用相同的密钥分别进行加密和解密

我们在非对称加密的过程中使用两个不同的密钥

通过这张图我们可以知道,我们是通过公钥进行加密的,然后通过私钥进行解密的,那么公钥和私钥有什么关系呢?

我们看看非对称加密的特点

2.1.2.1非对称加密的特点

1. 对于一个公钥有且只有一个对应的私钥
2. 公钥是公开的,并且不能通过公钥反推出私钥
3. 通过私钥加密的密文只能通过公钥才能解密,通过公钥加密的密文也只能通过私钥才能解密(这句话,我原本很诧异,不是只能用公钥进行加密,用私钥进行解密。这里为什么还有一个通过私钥加密的密文只能通过公钥才能解密,然后我搜了一下，这是另一种可能的用法，但在 HTTPS 中并不常见。这种方式常常用于数字签名和证书验证。)然后我们的公钥加密,私钥解密常常用于在不安全的通道上发送敏感信息，如密码、信用卡号等。私钥加密，公钥解密：由于只有服务器拥有匹配的私钥，因此只有服务器能够创建一个可以用服务器的公钥解密的信息。这种方式常常用于数字签名和证书验证。使⽤⾮对称加密通信，可以在不可信⽹络上将双⽅的公钥传给对⽅，然后在发消息前分别对消息使⽤对⽅的公钥来加密和使⽤⾃⼰的私钥来签名，做到不可信⽹络上的可靠密钥传播及加密通信。2.1.2.2非对称加密的经典算法RSA算法是一个著名的非对称加密算法

2.2摘要算法

刚才我们说的加密算法是用来保证数据的安全性,这个摘要算法是用来保证数据的完整性的

能够为数据生成独一无二的「签名」，用于校验数据的完整性，解决了篡改的风险。

它并不是加密算法,因此不能用于加密（因为无法通过摘要反推明文），只能用于防篡改，但是它的单向计算特性决定了可以在不存储明文口令的情况下验证用户口令。

不能用于加密（因为无法通过摘要反推明文），只能用于防篡改，但是它的单向计算特性决定了可以在不存储明文口令的情况下验证用户口令。举一个例子吧,比如我们知道了y = x的平方,假如我们知道了x等于2的话,我们就可以很确定的推出y = 4,但是假如我们知道了y = 4,但是我们不知道函数,也就无法确定出唯一的x了

而且，对原始数据做一个bit的修改，都会导致计算出的摘要完全不同。摘要算法就是通过摘要函数对任意长度的数据计算出固定长度的摘要

2.2.1常见的摘要算法

常见的摘要算法有MD5,SHA等等

3.HTTPS如何保证数据传输是安全

• 文件内容不能被读取（混合加密）
• 文件内容不能被篡改（数字签名）(摘要算法)
• 文件不能被掉包（数字证书）

3.1混合加密

对称加密使用同一份密钥，在不安全网络上传输会有密钥泄露的风险。但是运算速度快，性能好。而非对称加密刚好相反，它使用一对密钥保证了数据的安全传输但是性能差。所以采用了混合加密的方式。

• 在通信建立前采用非对称加密的方式交换「会话秘钥」，后续就不再使用非对称加密。
• 在通信过程中全部使用对称加密的「会话秘钥」的方式加密明文数据。

采用「混合加密」的方式的原因：

• 对称加密只使用一个密钥，运算速度快，密钥必须保密，无法做到安全的密钥交换。
• 非对称加密使用两个密钥：公钥和私钥，公钥可以任意分发而私钥保密，解决了密钥交换问题但速度慢。

3.2数字签名

为了保证传输的内容不被篡改，我们需要对内容计算出一个「指纹」，然后同内容一起传输给对方。

对方收到后，先是对内容也计算出一个「指纹」，然后跟发送方发送的「指纹」做一个比较，如果「指纹」相同，说明内容没有被篡改，否则就可以判断出内容被篡改了。

那么，在计算机里会用摘要算法（哈希函数）来计算出内容的哈希值，也就是内容的「指纹」，这个哈希值是唯一的，且无法通过哈希值推导出内容。

通过哈希算法可以确保内容不会被篡改，但是并不能保证「内容 + 哈希值」不会被中间人替换，因为这里缺少对客户端收到的消息是否来源于服务端的证明。

举个例子，你想向老师请假，一般来说是要求由家长写一份请假理由并签名，老师才能允许你请假。

但是你有模仿你爸爸字迹的能力，你用你爸爸的字迹写了一份请假理由然后签上你爸爸的名字，老师一看到这个请假条，查看字迹和签名，就误以为是你爸爸写的，就会允许你请假。

那作为老师，要如何避免这种情况发生呢？现实生活中的，可以通过电话或视频来确认是否是由父母发出的请假，但是计算机里可没有这种操作。

那为了避免这种情况，计算机里会用非对称加密算法来解决，共有两个密钥：

• 一个是公钥，这个是可以公开给所有人的；
• 一个是私钥，这个必须由本人管理，不可泄露。

这两个密钥可以双向加解密的，比如可以用公钥加密内容，然后用私钥解密，也可以用私钥加密内容，公钥解密内容。

流程的不同，意味着目的也不相同：

• 公钥加密，私钥解密。这个目的是为了保证内容传输的安全，因为被公钥加密的内容，其他人是无法解密的，只有持有私钥的人，才能解密出实际的内容；
• 私钥加密，公钥解密。这个目的是为了保证消息不会被冒充，因为私钥是不可泄露的，如果公钥能正常解密出私钥加密的内容，就能证明这个消息是来源于持有私钥身份的人发送的。

因为非对称加密比较消耗性能,所以我们通常不适用非对称加密来加密实际上的数据,主要用途还是私钥加密,公钥解密,保障了消息不会被冒充,确认消息的身份。我们常说的数字签名算法就是使用的是这个方法,不过私钥加密的不是内容本身而是内容的hash值

我们可以看看下图

服务器先把公钥给了客户端,然后把内容的哈希值进行了一个私钥加密得到了一个数字签名(记住,我们说的私钥加密加密的是hash值而不是我们传递的内容)。然后把数字签名和内容一起发送出去,将数字签名的hash值用公钥进行解密,然后将传输过来的内容计算出它的Hash值,如果它们俩一样,则说明消息是完整的,且是由服务器端发送过来的。如果不一样那一定是篡改过的

3.3数字证书

前面我们知道了

1. 我们可以通过混合加密确保内容不被其他人窃听
2. 我们可以通过摘要算法里面的Hash算法保证消息的完整性
3. 我们可以通过非对称加密里面的私钥加密,公钥解密得到的数字签名保证消息来源的可靠性

但是但是,这并没有完,我么刚才说的第三点,它只能保证一件事情它只能确保通信的对方拥有与其公钥对应的私钥，不能保证其身份的真实性。

可能出现的是一个攻击者攻击了服务器获取了私钥,然后这个攻击者给客户端发送内容。

为了避免这个问题,我们引入了数字证书,它就可以确保一定是服务器给我发的内容而不是攻击者了

计算机中,权威机构CA(数字证书认证机构),将服务器公钥放在数字证书(由数字证书认证机构颁发),只要证书可信,就可以保证密钥可信

4.HTTPS是如何建立连接的

SSL/TLS 协议基本流程：

• 客户端向服务器索要并验证服务器的公钥。
• 双方协商生产「会话秘钥」。
• 双方采用「会话秘钥」进行加密通信。

前两步也就是 SSL/TLS 的建立过程，也就是 TLS 握手阶段。

TLS 的「握手阶段」涉及四次通信，使用不同的密钥交换算法，TLS 握手流程也会不一样的，现在常用的密钥交换算法有两种：RSA 算法 和 ECDHE 算法 。

基于 RSA 算法的 TLS 握手过程比较容易理解，所以这里先用这个给大家展示 TLS 握手过程，如下图：

TLS 协议建立的详细流程：

1. ClientHello

首先，由客户端向服务器发起加密通信请求，也就是 ClientHello 请求。

在这一步，客户端主要向服务器发送以下信息：

（1）客户端支持的 TLS 协议版本，如 TLS 1.2 版本。

（2）客户端生产的随机数（Client Random），后面用于生成「会话秘钥」条件之一。

（3）客户端支持的密码套件列表，如 RSA 加密算法。

2. SeverHello

服务器收到客户端请求后，向客户端发出响应，也就是 SeverHello。服务器回应的内容有如下内容：

（1）确认 TLS 协议版本，如果浏览器不支持，则关闭加密通信。

（2）服务器生产的随机数（Server Random），也是后面用于生产「会话秘钥」条件之一。

（3）确认的密码套件列表，如 RSA 加密算法。

（4）服务器的数字证书。

3.客户端回应

客户端收到服务器的回应之后，首先通过浏览器或者操作系统中的 CA 公钥，确认服务器的数字证书的真实性。

如果证书没有问题，客户端会从数字证书中取出服务器的公钥，然后使用它加密报文，向服务器发送如下信息：

（1）一个随机数（pre-master key）。该随机数会被服务器公钥加密。

（2）加密通信算法改变通知，表示随后的信息都将用「会话秘钥」加密通信。

（3）客户端握手结束通知，表示客户端的握手阶段已经结束。这一项同时把之前所有内容的发生的数据做个摘要，用来供服务端校验。

上面第一项的随机数是整个握手阶段的第三个随机数，会发给服务端，所以这个随机数客户端和服务端都是一样的。

服务器和客户端有了这三个随机数（Client Random、Server Random、pre-master key），接着就用双方协商的加密算法，各自生成本次通信的「会话秘钥」。

4. 服务器的最后回应

服务器收到客户端的第三个随机数（pre-master key）之后，通过协商的加密算法，计算出本次通信的「会话秘钥」。

然后，向客户端发送最后的信息：

（1）加密通信算法改变通知，表示随后的信息都将用「会话秘钥」加密通信。

（2）服务器握手结束通知，表示服务器的握手阶段已经结束。这一项同时把之前所有内容的发生的数据做个摘要，用来供客户端校验。

至此，整个 TLS 的握手阶段全部结束。接下来，客户端与服务器进入加密通信，就完全是使用普通的 HTTP 协议，只不过用「会话秘钥」加密内容。

有点长,我们稍微总结一下:

ClientHello主要干了三件事情,ClientHello是客户端给服务端发送消息

发了:1.客户端支持的TLS版本

2.客户端自己产生的随机数

3.客户端支持的密码套件列表，如 RSA 加密算法(这个就是咋们在混合加密中用到的)

SeverHello主要干了四件事,这个ServerHello是服务端给客户端发送消息

发了:1.确认 TLS 协议版本，如果浏览器不支持，则关闭加密通信。

2.服务端自己产生随机数

3.确认的密码套件列表，如 RSA 加密算法。

4.服务器的数字证书。

ServerHello其实相当于就是把ClientHello发送的东西执行一遍之后,多发送了一个服务器的数字证书

第三步是客户端回应,它主要干了2件事

1.刚才我们服务器发过来的数字证书,客户端收到之后会确认数字证书的真实性

2.如果证书没有问题,客户端会从数字证书里面拿出服务器的公钥,然后使用它的加密报文,向服务器发送以下信息

1. 一个随机数
2. 客户端发出通知,随后的消息都将用加密通信
3. 发出握手结束通知,把之前的内容所产生的数据做个摘要,用来服务器端校验

服务器和客户端有了这三个随机数（Client Random、Server Random、pre-master key），接着就用双方协商的加密算法，各自生成本次通信的「会话秘钥」。

第四步是服务器回应,它主要干了两件事

1.服务器受到了客户端的第三个随机数之后,通过协商的加密算法,计算出本次通信的会话密钥

2.给客户端发送消息

1. 服务端发出通知,随后的消息都用加密通信
2. 服务器握手结束通知，把之前的内容所产生的数据做个摘要,用来客户端校验