HTTPS加密握手与加密算法
目录
前言
一、加密与解密
二、加密
2.1混合加密
2.2摘要算法与数字签名
2.2.1数字摘要与完整性保证
2.2.2数字签名与数据可靠性保证
2.2.3数字证书与服务端合法性证实
三、TLS握手
四、HTTPS应用数据如何保证完整性
前言
听别人讲其HTTP的时候，人们都会说HTTP时无连接、不可靠的，所谓的不可靠很大程度上是由于HTTP报文传输时有被监听或篡改的风险，那么本文就来讲解一下对HTTP报文进行安全性加固的HTTPS通信协议，以及其是如何保证安全性的。
一、加密与解密
现在请你想想一下你们家的大门，如果这个大门永远都是敞开的，那是不是谁都可以来你家里“做做客”，这种情况显然不是我们希望的，所以家门上往往配着一把锁，这个锁可以保护我们家里的财产安全，现在你用锁把家里的门锁上就可以认为是对家里的财产进行“加密”操作，当你回到家里打开门，准备使用这个房间就相当于“解密”操作。此外，家门的钥匙往往不止一把，可能你、你的妈妈、你的爸爸都有一把钥匙。这就意味有钥匙的人都具备使用这个房间的能力。
放到我们的通信过程中则是，数据的发送端会在数据发送前对数据“加密”，当数据被接收时，使用对应的钥匙进行“解密”操作就可以获取到数据。
二、加密
2.1混合加密
HTTPS采用的是对称加密和非对称加密的混合加密方式。
对称加密：使用同一把密钥进行数据的加密与解密，运算速度快，但是密钥不可以公开，这就意味着我们将密钥如何分发在客户端与服务端就成了一个问题。
非对称加密：存在“私钥”和“公钥”一对密钥可以使用公钥加密，私钥解密或者私钥加密、公钥解密，运算速度慢，但是公钥可以进行分发。公钥一般保存在客户端，私钥保存在服务端。
公钥加密、私钥解密：这种加解密方式一般用于客户端向服务端发送数据时。
私钥解密、公钥解密：这种加解密方式一般用于服务端向客户端验明身份。
在HTTPS加密过程中，我们使用非对称加密的方式将对称加密的密钥进行交换，交换完毕后，使用对称加密的密钥进行加密通信。
2.2摘要算法与数字签名
2.2.1数字摘要与完整性保证
为了保证我们的数据在传输过程中不被篡改我们需要对我们传输的数据利用摘要算法生成一个摘要数据，也可以叫它【指纹】，然后我们将数据和【指纹】一同发送给对端主机，对端主机接收到数据后，再利用摘要算法对数据作摘要然后和传输过来的【指纹】进行对比，如果新生成的摘要数据和【指纹】作对比，如果两个数据值一致，那么认为数据没有被更改。(对于同一份数据使用同一种摘要算法生成的值是一致的，但是如果数据发生变动，则会导致最终生成的值不一致)
虽然我们可以通过摘要算法来确定我们的数据是否是完整的，但是我们无法确定我们的数据是不是被替换过了，比如黑客将服务器发送给我们的数据截获并对其修改，然后重新计算了一个数字摘要覆盖我们原来的数字摘要，因此数据的可靠性未得到保证。
2.2.2数字签名与数据可靠性保证
这个时候就需要用到服务端的“私钥”，服务端在生成数字摘要后，再使用私钥对数字摘要进行加密，加密后的数字摘要我们称为“数字签名”，然后我们将数字签名和数据一同发送给客户端，客户端接收到数据后，使用公钥对数字签名进行解密获取数字摘要，然后对数据进行数据摘要与接收到的数据摘要作比较即可。
但是现在还有个问题，如果黑客伪造了一对密钥，并将公钥设置进用户的电脑中，当服务端的数据到来，黑客劫持数据并修改后，使用自己的私钥重新生成数字签名覆盖原来的数字签名，最后再交给用户，用户在不知情的情况下使用黑客的公钥进行了解密和数字摘要比对后发现没有问题。继续与服务器进行通信而导致数据被监听或篡改。所以这里的可靠性只能确定，接收到的消息确实是有客户端公钥对应的拥有私钥的服务端发送过来的，但是服务端的合法性没有得到证实。
2.2.3数字证书与服务端合法性证实
数字证书是由权威的CA机构颁发的，你可以认为CA机构就是世界级的网络公安机关，经过该机构审核通过的服务端就会被认为是合法的，这种审核往往比较严苛，所以对于黑客的钓鱼站点来说是几乎不可能通过审核的。
所以，对于客户端来说，如果你想对我设置配对的公钥必须要提供CA机构或其子机构的数字证书，如果没有提供审核通过的数字证书那么客户端的操作系统就不会信任这个公钥也就不会被设置进操作系统。
三、TLS握手
再讲解图5之前，我们需要明确——在TLS握手期间一定是使用非对称密钥加密的方式来进行通讯的。
如图5所示，在进行TLS握手前，需要先进行TCP三次握手，因为HTTPS协议也是基于TCP的，然后开始生成对称加密密钥所需的三个数据。这三个数据就是我们需要使用非对称加密进行通讯的数据。
首先客户端会先生成一个随机数client random，并将这个随机数发送给服务端，服务端接收到后会返回一个服务端生成的随机数server random，然后客户端会生成最后一个随机数pre-master，并将这个随机数使用与服务端私钥配对的公钥加密后发送给服务端。之后客户端就可以使用client random、server random、pre-master这三个随机数生成对称公钥，服务端也是如此。最后客户端发起使用对称加密通信请求，服务端收到请求返回响应之后，带客户端确认就可以进行对称加密通信了。
至此客户端和服务端的TLS握手完成。
四、HTTPS应用数据如何保证完整性
之前我们在讲解TLS握手过程中数据完整性一致的策略是使用数据摘要算法对要发送的数据进行处理后随数据一起发送，数据的可靠性是与数字签名和CA证书有关的，如果我们还是使用这种方式来保证可靠性和数据的完整性那么对已有的数据利用就太低了。
TLS在实现上分为了握手协议和记录协议，握手协议就是我们用来建立TLS通信的(如图5)，记录协议就是用来对我们的数据作完整性、可靠性保证的且还可以对数据进行压缩。
记录协议也会对数据进行摘要操作并生成一个MAC值（消息认证码），这个值不仅与我们的数据有关还与我们的对称密钥有关，因为我们的对称密钥是经过非对称加密传输的是可靠的，所以生成的MAC值也是可靠的。然后对包含MAC值和压缩后的片段进行加密添加属性后就可以发送了。
参考文章：
小林coding
理解SSL/TLS系列 (四) 记录协议_记录层-CSDN博客