Https协议如何保证安全性？

Https和Http的关系

Https是Http里的一层加密层，如果协议走了这一层加密层，那么就是https。如果没有，则是单纯的http。

因为没有走ssl/tls这层加密层，所以这是单纯的http协议，数据在网络中传输是明文的，也就是裸奔的，所以http协议在网络中传输其实是不安全的。

而https协议会走这一层加密层，所以从传输层开始，所有的数据都是密文的。而这比起http，是相当安全的。

所以http和https的区别就是，https的数据是加密后传输的，而http的数据则是网络中裸奔。所以http其实是不安全的！

数据加密的原理

那么数据如何加密？ 这里有一个最简单的加密例子。 客户端和服务端都有一个密钥key，客户端用密钥对数据进行加密，随后把加密后的数据发送给服务器。服务器用密钥解密，得到传过来的数据。

而传输过去的b则是一个加密后的值。int b = key ^ daya 是加密的过程。而int data = b ^ key 是解密的过程。这就是数据加密的原理。

所以数据加密是非常重要的。假如我们在外面的时候，连上了别人的wifi，那么我们发送的所有请求都是从该wifi所在的路由器中发送出去的。也就是说我们发送的请求都会先转发到路由器，而如果我们的数据没有加密，那么我们的数据就会被不心术不正之人截获。这是非常严重的。

HTTPS加密方案

首先我们要明白加密分为对称加密和非对称加密。对称加密就是上面那个例子所说，只有一个密钥。通过密钥加密，也用密钥解密。 而非对称加密则是分为公钥和私钥，公钥是公开的，全世界人都可以知道，而私钥只有自己知道，是不公开的。可以通过公钥加密，私钥解密。也可以通过私钥加密，公钥解密。都是可以的。

相信我们应该都知道百度网盘的秒传功能，就是明明有时候我们上传的文件明明很大，却是一瞬间就上传完了。这是什么原理呢？

实际上，在上传的时候，百度网盘的客户端会先把文件用hash散列的方式转变成一个字符串。我们称这个字符串为摘要 ，在对摘要进行数据签名(签名下面会说，就是对摘要的一种加密) 。 随后把加密后的摘要发送到百度网盘的服务器，而百度网盘的服务器会在后台进行查找。看摘要是否存在，如果摘要不存在，则让你上传，并把该摘要保存一份，建立摘要与文件的映射关系。如果摘要存在，则找到摘要对应的文件，创建一个软链接，给你的账户映射。

所以这样就可以保证，网盘中真正存储的文件只有一份(也有可能有备份)。摘要是一串固定长度的字符串，当你上传文件的时候先文件进行hash散列然后形成摘要发送给网盘服务器，网盘服务器去判断摘要是否存在。不存在就让你上传该文件并形成一份摘要。反之直接找到摘要对应的文件，创建一份软链接给你的云盘用户映射。

网络通信中，我们要解决哪些问题？

1. 数据被监听

2. 数据被纂改

接下来我要为大家演示几种加密方案。

方案1：只使用对称加密

只使用对称加密时，我们要先把自己的密钥发送给服务器。让服务器知道密钥，随即才能进行加密解密传输。

但是！！你第一次发送密钥S的时候，就有可能被拦截。被拦截之后别人也知道你的密钥了，也可以通过密钥S对你发来的消息进行加密解密。 所以这个密钥可以说就是加了个寂寞 =。=

方案2： 只使用非对称加密

首先客户端向服务端发起协商握手。

随后服务器把自己的公钥返回给客户端。

之后客户端的数据通过服务端提供的公钥S加密，发送给服务端。 服务端用私钥S’ 进行解密，返回给客户端。

这种方法只能保证客户端到服务端的数据是加密的。因为中间人同样可以拦截服务器最先发送给客户端的公钥S，随后服务器用私钥加密的所有数据都可以被中间人用公钥解密。

方案3： 都使用非对称加密

首先，客户端用一个公钥C 和 一个私钥C’ ， 服务端有一个公钥S 和 一个私钥S’ 。

然后客户端把自己的公钥C发送给服务器。 服务器收到客户端发来的公钥C后，把公钥C保存一份。

然后服务器用公钥C对自己的公钥S进行加密，加密得到的数据为X，并把X发送给客户端。客户端收到X。

客户端收到X之后，因为X是用自己的公钥C加密的，所以客户端可以用C’ 对X进行解密，得到服务器的公钥S。并保存下来。

现在客户端就得到了服务端的公钥S，服务端也得到了客户端的公钥C。 客户端每次发送数据都用公钥S加密发给服务端，服务端用S’ 解密后得到数据。服务端发送数据则通过公钥C进行加密，发到客户端后用C’ 进行解密。 这个流程看似天衣无缝，其实有大问题。

第一个问题：非对称加密解密的速度是非常慢的，相比于对称加密而言。

第二个问题：这个问题则是和下面要介绍的方案4是一样的问题，所以问题会在方案4中提到。

方案4： 非对称加密+对称加密

非对称加密则是服务器具有非对称的公钥S和私钥S’

随后客户端发送握手协商，服务器把自己的公钥S发送给客户端。

客户端收到公钥S后，保存公钥S，并生成一个对称密钥C。

随后客户端用公钥S对密钥C进行加密生成X，再发送给服务器。

服务器收到X后用私钥S’ 对X进行解密得到密钥C。

方案4相比于方案3，解决了速度的问题。因为在后面传输的过程中，都是用对称密钥C进行加密解密的。而公钥S，和S’只有最开始使用，所以方案4的速度是比方案3快很多的。 但方案4同样面临着一个严重的问题。这个问题和方案3，方案2面临的问题是一样的。 因为我们上面的流程都是在确保握手协商阶段不被中间人获取数据的情况，可是如果中间人在握手协商阶段就开始拦截你的请求了呢？

接下来我们图解描述这个问题。

假如服务器有一个公钥S和一个私钥S’ ， 而此时也有一个中间人准备进行拦截。

客户端发送握手协商请求，中间人拦截到请求，但没有管这个请求，这个请求被原模原样的发送给了服务器。

此时服务器把自己的公钥S发送给客户端，可是却被中间人拦截了，中间也有一份自己的公钥M和私钥M’。

中间人把公钥S返回一份，并把自己的公钥M发送给客户端。客户端则接收到了中间人的公钥M。

相信到这里已经有很多人能看出问题了，这丫的中间人不是在冒充服务器吗？？？？是这样的，但是讲解还需继续。接下来客户端生成自己的对称密钥C。并用公钥M对密钥C进行加密生成X。

生成了X后，客户端向服务端发送X，但是又被中间人给拦截了。

中间人收到了X，因为X是用公钥M加密的。所以中间人可以用私钥M’ 对X进行解密，得到对称密钥C。并保存对称密钥C。

此时中间人再把对称密钥C用公钥S进行加密，得到P，并把P发送给服务器。

服务器收到P后，因为P是用公钥S进行加密的，所以服务器可以用私钥S’ 对P进行解密。解密后得到对称密钥C。

而之后每次通信中，客户端向服务器发送的消息都能被中间人截获，且用对称密钥C进行解密，从而获得你的数据。然后在用对称密钥C加密发送给客户端。因为中间人已经得到了密钥C，所以服务器和客户端发送的消息都能被中间人解密。这不就已经退化到了方案一吗？而方案4也同样有这个问题。因为这些方案都无法保证在握手协商阶段，数据不被截取。 所以就有了方案5，来完美解决这些问题。

方案5 : 非对称加密 + 对称加密 + 证书认证

引入证书

CA认证

服务端在使用https之前，需要先向CA机构申领一份数字证书，数字证书里含有证书申请者信息、公钥信息。服务器把证书传输给浏览器，浏览器从证书里获取公钥就行了，证书就像身份证，证明服务端公钥的权威性

这个证书可以理解成是一个结构化的字符串，里面包含了：

• 证书发布机构
• 证书有效期
• 公钥
• 证书所有者
• 签名
• …

需要注意的是：申请证书的时候，需要在特定的平台查，会同时生成一个公钥和对应的私钥。这对密钥就是用来在网络通信中进行明文加密以及数字签名的。

所以引入证书分为如下几个流程：

1. 申请证书认证 ， 可以去网站上申请

2. 审核信息，比如你的域名，申请人…等等信息都需要审核。

3. 签发证书，就是申请证书成功了。证书包含明文信息和签名两部分。

4. 返回证书，就是把证书发送给浏览器，由浏览器认证证书是否合法

5. 浏览器认证证书是否合法，不合法直接丢弃报文。

6. 证书合法，密钥协商成功。

其中 1 - 3的步骤只需要进行一次，而 4 - 6 这个步骤是会进行多次的。

证书如何保证可靠性？

都说证书可以让公钥更具有权威性，那么为什么？ 又凭什么？ 这整套流程是怎么样的？

首先我们的证书肯定是从服务器发送到客户端的，证书是如何保证能够不被中间人篡改的？

首先，这是我们证书的样子。

首先明文信息就是一些信息，用来核对服务器的一些信息，还有存储公钥的，那么这个签名是怎么生成的呢？

签名的生成有如下2个步骤：

1. 对明文信息INFO进行hash散列，形成数字摘要。

2. 用自己的私钥对数字摘要进行加密。最后形成签名

用了私钥加密，那么就必须要用公钥解密。所以这也就是为什么明文信息中必须要有公钥的原因了。因为浏览器就是根据这个公钥来对签名进行解密。

然后我们就把证书发送给浏览器客户端。

浏览器客户端也会做如下几个步骤：

1. 对证书的明文信息进行hash散列，形成数字摘要。

2. 用证书提供的公钥对签名进行解密，得到最开始的明文数字摘要。

3. 将两个摘要进行比对，如果两个摘要相等则说明证书没有被篡改。反之说明证书被篡改了，就丢弃报文。

4. 校验明文信息中的其他内容，例如证书有效日期，域名…等等内容是否正确。不正确则丢弃报文。

按照这个流程来，我们就可以保证，证书发送给浏览器客户端时，一定是没有被中间人篡改过的。如果被篡改了，就会丢弃报文。

为什么中间人不能篡改证书？

为什么中间人不能篡改证书呢？这是因为证书中的签名，是用CA机构生成的私钥加密的，而这个私钥只有人家知道。中间人根本就不知道，这也就意味着你中间人无法生成有效的数字签名。即使中间人拦截了证书，并用公钥对证书的签名进行解密，获得的是对明文信息的一串数字摘要。而因为中间人没有私钥，所以就算篡改了明文信息，和对应的数据摘要。也无法生成新的签名，因为生成签名需要CA机构提供的私钥！ ，而只修改明文信息也会因为和签名解密后的摘要不一样被识别到。

中间人能不能用他申请的证书替换你的证书？

答案是可以的，但是替换了之后，浏览器识别到证书是真证书，但是浏览器还会去识别域名，你证书的域名和服务器的域名对不上，一样会被校验出来，丢弃报文。所以即使中间人拦截你的证书，给客户端提交自己的证书，也无法认证成功。