HTTPS协议介绍

一、HTTPS协议的认识

HTTPS和HTTP都是属于应用层协议，只不过HTTP协议在传输数据时，它的数据报正文都是以明文的形式展现的，非常不安全，被盗取数据的风险很高，所以HTTPS协议是在HTTP协议的基础上引入的一个加密层。

HTTPS协议介于HTTP协议与其他层协议之间，当数据自顶向下流动时HTTPS协议会对数据进行加密，当数据自底向上流动时HTTPS协议会对数据进行解密。所谓加密就是把HTTP的明文传输信息进行一系列转换，生成密文。解密就是把密文再进行一系列转换，生成明文。在这个加密和解密的过程中，往往需要一个或者多个中间的数据，辅助进行这个过程，这样的数据被称为密钥。

因为HTTP的内容是明文传输的，明文数据会经过路由器、wifi热点、通信服务运营商、代理服务器等多个物理节点，如果信息在传输过程中被劫持，传输的内容就完全暴露了。劫持者还可以篡改传输的信息并且不被双方发现，这就是中间人攻击。所以我们才要对信息进行加密。

二、常见的加密方式

1.对称加密

对称加密是采用单钥密码系统的加密方法，同一个密钥可以同时用作信息的加密和解密，这种方法也称作单密钥加密。对称加密其实就是通过同一个密钥，把明文加密成密文，再把密文解密成明文。

常见的对称加密算法有：DES、3DES、AES、TDEA、Blowfish、RC2等。

对称加密的特点是算法公开、计算量小、加密速度快、加密效率高。

2.非对称加密

非对称加密需要两个密钥来进行加密和解密，这两个密钥分别叫做公开密钥(简称公钥) 和 私有密钥(简称私钥)。公钥可以让对外公开让别人知道，私钥一般不公开。公钥和私钥是配对的，可以通过公钥对明文进行加密，变成密文，通过私钥对密文解密，变成明文；也可以反过来使用，通过私钥对明文加密，变成密文，通过公钥对密文解密，变成明文。

常见的非对称加密算法有：RSA、DSA、ECDSA等。

非对称加密的特点是算法强度复杂、安全性依赖于算法与密钥。但是由于其算法复杂，所以它的加密和解密速度都比较慢。

三、数据摘要

数据摘要也叫作数据指纹，其基本原理是利用单向散列函数(Hash函数)对信息进行运算，生成一串固定长度的数据摘要。数据摘要并不是一种加密机制，它可以用来判断数据有没有被修改。比如一个很大的文件，里面有很多内容，对该文件生成数据摘要之后，如果稍微修改一下文件内容，比如只是修改一下标点符号，都会使数据摘要发生很大的变化。

常见的摘要算法有：MD5、SHA1、SHA256等，数据摘要的算法是有可能发生碰撞的，即两个不同的信息算出的摘要可能会相同，但是这种概率非常低。

数据摘要的特征是它严格意义上并不是加密，因为没有解密，只不过从摘要很难反推原信息，通常用来进行数据对比。

四、HTTPS的工作过程探究

1.只使用对称加密

第一种方案是只使用对称加密，如果通信双方都各自持有同一个密钥，且没有别人知道，那么双方的通信安全是可以得到保证的。客户端通过密钥对明文请求进行加密，转换成为密文请求之后发送回给服务器，服务器通过密钥对密文请求进行解密，转换成明文请求，这样双方就可以完成一次加密通信。

但是这种加密方式明显是存在弊端的，首先是这种方式无法保证客户端和服务器获取到同一个密钥，因为密钥本质也是一种信息，如果双方要获取同一份密钥，就必须通过通信协商好使用的密钥是什么，在密钥传输的过程中也会有可能被截取数据，所以这种方式并不可行。

2.只使用非对称加密

鉴于非对称加密的机制，如果服务器先把公钥以明文的方式传输给客户端，之后客户端向服务器传数据前都先用这个公钥加密好了再传，数据传输到服务器之后，服务器再用自己的私钥对其进行解密，从而获取到客户端发送过来的数据。即使中间传输过程被别人截取数据，但它只有公钥，私钥在服务器手上，所以也就无法对数据进行解密。

这样看似乎是安全的，但是只局限于一方向另一方发送数据，如果服务器想要发送数据给客户端，只使用非对称加密这种方式就无法保证安全性了。

3.双方都使用非对称加密

针对第二种方案的局限性，我们可以对其进行改进。即服务端拥有公钥S和对应的私钥S’，客户端拥有公钥C和对应的私钥C‘。

在双方通信之前，客户端和服务端先交换公钥，之后客户端在给服务端发消息时，先用服务端的公钥S对数据加密之后再发送，服务端再用服务端的私钥S’对其进行解密。服务端在给客户端发消息时，先用客户端的公钥C进行加密再发送，客户端再用客户端的私钥C’对其进行解密。

这种方案看起来似乎解决了通信安全的问题，但依旧存在两个弊端：

首先是这种方案的效率太低了，由于非对称加密本身就是一种效率很低的加密方式，这里还采用两队公钥私钥非对称加密，只会导致通信效率更低。

其次，这种方案也是存在安全问题的。

4.非对称加密+对称加密

第四种方案是服务端具有非对称公钥S和私钥S’，客户端先发起HTTPS请求，获取服务端的公钥S。

然后客户端在本地生成对称密钥C，通过公钥S将对称密钥C发送给服务器。

从此以后，客户端和服务端就以对称密钥C进行加密解密，从而保证信息传递的安全性。

这种方案的本质是基于对称加密的效率比非对称加密高很多，所以客户端和服务端只是在开始阶段协商密钥的时候使用非对称加密，后续的通信都采用对称加密。由于中间的网络设备没有私钥，即使截获了数据，也无法还原出内部的原文，也就无法获取到对称密钥。

5.中间人攻击

上面所介绍的方案2、方案3、方案4看似解决了安全问题，实际上处理得还是不够完美，依然可能会遭受中间人攻击。

中间人攻击(Man-in-the-MiddleAttack)，简称MITM攻击。在方案2、方案3、方案4中，客户端获取到服务端的公钥S之后，用公钥S对客户端生成的对称密钥C进行加密，中间人即使窃取到了诗句。此时中间人也无法解密出客户端形成的对称密钥C，因为只有服务器有解密的私钥S‘。

但是如果中间人在最开始双方握手协商的时候就进行攻击了，这三种方案都无法保证其安全性。

服务器生成了自己的非对称公钥S和私钥S’，中间人也在本地生成了自己的非对称公钥M和私钥M’，客户端发起HTTPS请求获取服务端的公钥S。此时中间人截取到服务器的公钥S，将服务器的公钥S保存在自己的本地，然后将自己的公钥M响应回给客户端。

客户端获取响应之后并不知道这个公钥是中间人的，它默认是服务器正常响应回来的，所以就拿着响应回来的公钥M对客户端本地的对称密钥C进行加密，再发送回给服务器。

此时中间人继续截取客户端发送回去的信息，获取到了通过中间人的公钥M加密的对称密钥C，中间人只需要拿着自己本地的私钥M‘进行解密即可，最后将解密出来的对称密钥C再用服务器的公钥S进行加密，然后发送回给服务器。

这样服务器和客户端都以为双方是在正常通信，但事实上是已经被中间人篡改了数据截取了信息。

上述问题的本质是客户端无法确定收到的含有公钥的数据报文，是不是目标服务器发送过来的。

6.引入证书

服务端在使用HTTPS之前，需要向CA机构申领一份数字证书，数字证书里包含证书申请者的信息、公钥信息等。服务器把证书传输给客户端，客户端从证书里获取公钥就可以了。证书就如同身份证，证明服务端公钥的权威性。

这个证书可以理解成是一个结构化的字符串，里面包含了以下信息：证书发布机构、证书有效期、公钥、证书所有者、数字签名……

当服务端申请CA证书的时候，CA机构会对该服务端进行审核，并专门为该网站形成数字签名，过程如下：

1. CA机构拥有非对称加密的公钥A和私钥A’
2. CA机构对服务端申请的证书明文数据进行哈希，形成数据摘要
3. 然后对数据摘要用CA私钥A’加密，得到数字签名S
4. 服务端申请的证书明文和数字签名S共同组成了数字证书，这样一份数字证书就可以颁发给服务端了

7.非对称加密+对称加密+证书认证

所以方案五就是在客户端和服务器刚建立连接的时候，服务器给客户端返回一个证书，证书包含了之前服务端的公钥，也包含了网站的身份信息。

当客户端获取到这个证书之后，会对证书进行校验(防止证书是伪造的)，首先会判定证书的有效期是否过期，然后判定证书的发布机构是否受信任(操作系统中已内置的受信任的证书发布机构)，最后验证证书是否被篡改。

客户端验证证书是否被篡改的方式是：从操作系统中拿到该证书发布机构的公钥，对签名进行解密，会得到一个哈希值(称为数据摘要)，设为hash1，然后计算整个证书的哈希值，设为hash2。客户端通过对比hash1和hash2是否相等就可以判断证书是否被篡改。比如如果两个哈希值相等，则说明证书是没有被篡改的。

如果中间人截取了证书并且篡改了证书明文，但是由于中间人没有CA机构的私钥，所以无法哈希形成签名，即使他用自己的私钥强行篡改证书，生成新的签名，但是客户端在验证的时候是会发现明文和签名与官方的不一致，说明证书已经被篡改了，证书不可信，从而终止向服务器传输信息，防止信息泄露给中间人。

除此之外，中间人也无法通过掉包整个证书来截取信息，因为所有计算机都使用的是公认的机构颁发的证书，中间人无法制作假的证书。