HTTPS概念

在前面我们已经详细的介绍了HTTP协议，但是HTTP协议由于是明文传送，传送过程中会出现安全问题，所以就引入了HTTPS协议：

• HTTPS 是一种应用层协议，是一种透过计算机网络进行安全通信的传输协议；
• HTTPS 经由 HTTP 进行通信，但是在 HTTP 的基础上引入了一个加密层，使用 SSL/TLS 来加密数据包；
• HTTPS 开发的主要目的，是提供对网站服务器的身份认证，保护交换数据的隐私与完整性；
• HTTPS 默认工作在 TCP 协议443端口。

加密是什么

首先，我们需要理解以下概念：

• 明文：要传输的原始的消息；
• 密文：通过一定的规则将明文变换后的内容；
• 加密：将明文变成密文；
• 解密：将密文变成明文；
• 密钥：在加密和解密的过程中，往往需要一个或多个中间的数据来辅助该过程，这样的数据称为密钥；

为什么需要https，为什么需要加密？

我们平时下载某些软件的时候就会发现，我们点击下载的按钮，本来是应该下载我们需要的软件的，但是他就会突然跳转值另一个链接，下载其他软件，这就叫做运营商劫持。

我们通过网络传输的任何数据都会经过运营商的网络设备（路由器，交换机等），运营商的网络设备就可以解析出我们的传输数据内容，进行篡改。我们可以想象，如果我们此时发生劫持的不是运营商，而是黑客，那岂不是就很危险。所以HTTPS的出现，使用密文传输进一步的保证了用户的信息安全。

常见加密方式

既然要保证数据安全，就需要进行“加密”，即网络传输中不再直接传输明文，而是加密之后的“密文”。加密的方式有很多，但是整体可以分为两大类：对称加密和非对称加密。

对称加密

• 采用单密钥系统的加密方法，同一个密钥可以同时用作信息的加密和解密，这种加密方法称之为对称加密，也称单密钥加密。特征：加密和解密所用的密钥是相同的；
• 常见的加密算法：DES、3DES、AES、TDEA、Blowfish、RC2等；
• 特点：算法公开，计算量小，加密速度快，加密效率高；

对称加密其实就是只通过一个密钥，把明文加密成密文，并且也能把密文解密成明文。

比如我们平时所说的异或操作，我们在C语言中学习过不使用变量来交换两个数，就是通过异或的方法，异或就是一个最简单的对称加密的方法，假设明文为 1234，密钥为 8888。通过明文和密钥异或操作实现加密 1234 ^ 8888，得到密文为 9834。然后通过密文和密钥异或操作解密 9834 ^ 8888，得到明文 1234。

非对称加密

• 需要两个密钥来进行加密和解密，这两个密钥是公开密钥（public key，简称公钥）和私有密钥（private key，简称私钥）。
• 常见的非对称加密算法：DSA、DSA、ECDSA；
• 特点：算法强度复杂，安全性依赖于算法与密钥但是由于其算法复杂，使得其加密解密速度没有对称加密解密速度快；

非对称加密要用到两个密钥，一个“公钥”，一个叫“密钥”。

公钥和密钥是配对的，最大的缺点就是运算速度非常慢，比对称加密慢得多。

• 通过公钥对明文加密，形成密文；
• 通过私钥对密文解密，形成明文。

他也可以反着用：

• 通过私钥对明文加密，形成密文；
• 通过公钥对密文解密，形成明文。

数据摘要&&数据指纹

• 数据指纹（数据摘要），其基本原理是利用单向散列函数（Hash函数）对信息进行运算，生成一串固定长度的数据摘要。数据指纹并不是一种加密机制，但可以用来判断数据有没有被篡改；
• 摘要常见方法：MDS、SHA1、SHA256、SHA512等，算法把无限的映射成有限，因此可能会有碰撞（两个不同的信息，算出相同的摘要，但是概率非常低）；
• 摘要特征：和加密算法的区别是，摘要严格意义上说不是加密，因为没有解密，只不过从摘要很难反推原信息，通常用来进行数据对比。

数据签名

摘要进过数据加密，就得到数据签名；

HTTP工作过程探究

既然要保证数据安全，就需要进行“加密”，网络传输中就不再直接传输明文，而是加密之后的“密文”，加密的方式有很多，但是整体分为两大类：对称加密和非对称加密。

方案一：只使用对称加密

如果通信双方各自持有同一个密钥X，且没有别人知道，这两方的通信安全自然是可以保证的（除非密钥被破解）

引入对称加密以后，即使数据被截获，由于黑客不知道密钥是啥，因此无法进行解密，也就不知道请求的真实内容是啥了。

但是服务器同一时刻其实要给很多客户端提供服务，多个客户端的密钥都必须是不同的（相同的话就太容易扩散，黑客也就能拿到了），因此服务器就需要维护每个客户端与每个密钥之间的关联关系。

比较理想的做法，在客户端和服务器建立连接的时候，双方协商密钥是什么。

此时如果把密钥明文传输，黑客也就获得密钥了，所以密钥的传输也必须是密文传输，此时对密钥进行对称加密就仍需先协商一个“密钥的密钥”，就会变成先有鸡还是先有蛋的问题，所以对密钥的加密也就行不通了。

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

鉴于非对称加密的机制，如果服务器先把公钥以明文方式传递给浏览器，之后浏览器向服务器传数据前都先用这个公钥加密好再传，从客户端到服务器似乎是安全的，但是服务器到浏览器就不一定了，如果服务器端用它的私钥加密数据传输给浏览器，那么浏览器用公钥就可以解密它，这个公钥一开始是明文传输给浏览器的，若公钥被中间人给劫持到了，那他也能用公钥解密服务器传来的信息了。

方案三：双方都使用非对称加密

• 服务端拥有公钥S和私钥S’，客户端拥有公钥C和C’；
• 客户端和服务端交换公钥；
• 客户端给服务端发消息：先用S对数据加密，在发送，只能用服务器解密，因为只有服务器有私钥S’；
• 服务端给客户端发消息：先用C对数据加密，在发送，只能用客户端解密，因为只有客户端有私钥C’。
  
  上面这种方案看似没有安全问题，但是效率太慢，因为双方都为非对称加密，而且他也不一定是安全的，稍后我们就会解释。

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

• 服务端具有非对称公钥S和私钥S’；
• 客户端发起https请求，获取服务端公钥S；
• 客户端在本地生成对称密钥C，通过公钥S加密，发送给服务器；
• 由于中间网络设备没有私钥，即使截获了数据，也无法还原出原文，也就无法获取对称密钥；
• 服务端通过私钥S’进行解密，还原出客户端发出的对称密钥C并且使用这个对称密钥加密给客户端返回的响应数据。
• 后序客户端和服务端的通信都只使用对称加密即可，由于该密钥只有客户端和服务端两个主机知道，其他主机/设备不知道密钥即使截获也没有意义。

上面这种方案看似也是安全的，但是此时我们并不知道中间人攻击的场景，下面我们针对上面这些场景来理解中间人的的攻击场景，就会发现这种方法也是不安全的。

中间人攻击

• 服务器具有非对称加密算法的公钥S，私钥S’；
• 中间人具有非对称加密算法的公钥M，私钥M’；
• 客户端向服务器发起请求，服务器明文传送公钥S给客户端；
• 中间人劫持数据报文，提取公钥S并保存好，然后将被劫持报文中的公钥S替换成为自己的公钥M,并将伪造报文发给客户端；
• 客户端收到报文，提取公钥M(自己当然不知道公钥被更换过了)，自己形成对称秘钥X，用公钥M加密X，形成报文发送给服务器；
• 中间人劫持后，直接用自己的私钥M’进行解密，得到通信秘钥X，再用曾经保存的服务端公钥S加密后，将报文推送给服务器；
• 服务器拿到报文，用自己的私钥S解密，得到通信秘钥X；
• 双方开始采用X进行对称加密，进行通信。但是一切都在中间人的掌握中，劫持数据，进行窃听甚至修改，都是可以的。

针对中间人这种情况，方案三和方案四都会出现安全问题，这里中间人能够攻击成功的本质就是中间人能够对数据做篡改并且client无法验证收到的公钥是合法的，为了解决上面的问题，就需要对client进行合法性认证。

引入证书

CA认证

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

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

1. CA机构拥有非对称加密的私钥A和公钥A；
2. CA机构对服务端申请的证书明文数据进行hash，形成数据摘要；
3. 然后对数据摘要用CA私钥A加密，得到数字签名S。

因为我们最终颁发给服务端的证书除了一些明文信息意外还有通过hash产生的数据摘要，通过hash产生的数据摘要几乎不会存在重复的情况，所以就算中间人能够截取到我们的CA认证，就算将非对称密钥的公钥和私钥替换成自己的，甚至自己去认证机构申请CA认证，最终客户端请求认证的过程中也会被认证机构给识别出来，因为数据摘要存在差异。

理解数据签名

经过CA几个认证以后，此时我们就可以的到我们安全的方案了。

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