网络初阶——应用层：HTTPS 协议

一、HTTPS & HTTP 的区别

从协议的名字来看，HTTP 比 HTTPS 少了一个 S。而这个 “S”，其实可以理解成 “Safe”，所以不难看出，其实 HTTPS 就是 HTTP 的安全版。就是为了保证客户端 cookie 的传输安全的。

二、相关概念

1、明文

没有被加密过的数据就是明文。

2、秘文

被加密过的数据就是秘文。

3、密钥

负责给数据加密和解密的都叫密钥。

3.1. 私钥

不会被发出去的，只有自己知道的密钥就是私钥。

3.2. 公钥

会被发给对方的，让所有人都知道的密钥就是公钥。

4、对称加密

发送方和接收方双方各有一把密钥，这两把密钥是完全相同的。发送方用密钥给数据加密，然后接收方就用相同的密钥给数据解密，这就叫对称加密。

举个例子，假设发送方想发个 5，且发送方和接收方的密钥都是 7，那么发送方就会用密钥加密：5 ^ 7 = 2，然后再把 2 发给接收方；然后接收方收到 2 后，再通过密钥解密 2 ^ 7 = 5，那么接收方就成功拿到 5 了。

5、非对称加密

发送方和接收方也是各有一把密钥，但这两把密钥是不同的。一把是公钥，一把是私钥。假设发送方持有的是公钥，接收方持有私钥，那么当发送方要发送数据时，发送方会先用公钥加密数据，再发给接收方，但接收方只能用密钥来对这个数据解密；而如果发送方持有的是私钥，接收方持有的是公钥，那么当发送方向接收方发数据时，会用私钥加密数据，然后再发给接收方，然后接收方只能用对应的公钥才能成功解密发来的数据。

三、加密方法

1、双方都用非对称加密

1. 服务端拥有公钥 S 与对应的私钥 S' ，客户端拥有公钥 C 与对应的私钥 C'。
2. 客户和服务端交换公钥。
3. 客户端给服务端发信息：先用 S 对数据加密，再发送，只能由服务器解密，因为只有服务器有私钥 S'。
4. 服务端给客户端发信息：先用 C 对数据加密，再发送，只能由客户端解密，因为只有客户端有私钥 C'。

2、非对称加密 + 对称加密

1. 服务端具有非对称公钥 S 和私钥 S'
2. 客户端发起 https 请求，获取服务端公钥 S
3. 客户端在本地生成对称密钥 C，通过公钥 S 加密，发送给服务器.
4. 由于中间的网络设备没有私钥，即使截获了数据，也无法还原出内部的原文，也就无法获取到对称密钥（遇到中间人攻击照样寄）。
5. 服务器通过私钥 S' 解密，还原出客户端发送的对称密钥 C。并且使用这个对称密钥加密给客户端返回的响应数据。
6. 后续客户端和服务器的通信都只用对称加密即可。 由于该密钥只有客户端和服务器两个主机知道，其他主机/设备不知道密钥即使截获数据也没有意义。

四、中间人攻击

 

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

五、CA 证书

从前面的 “中间人攻击” 问题可发现，其实就是因为客户端没办法分辨自己收到的密钥是不是合法的，或者说客户端是不知道自己收到的密钥到底有没有被中间人调包。更准确地说，产生 “中间人攻击” 问题的根本原因就是客户端一开始就接受了中间人的密钥 M 。而如何解决这个“中间者攻击” 问题呢？答案就是要引入一个叫 “CA 证书” 的东西了。

1、服务器如何获得 “CA 证书”

2、通信过程中证书的形成与处理

因为接收者只能用 CA 的公钥对 CA 签名进行解码，而 CA 签名又是衡量这个数据有没有被改过的唯一标准；所以当接收者接收到一个莫名的密钥时，接收者只认 CA 的公钥。 

Q：为什么有了证书就可以保证数据的安全呢？

• 中间者修改明文但不改签名

虽然数据是明文，不过一旦中间者修改了数据，那么就必然会导致接收者在对数据进行哈希映射后得到的值不等于数字签名的映射的值，那么该数据就会判定为已经被改过的数据，于是接收者就不会接收它了。

• 中间者修改明文和签名 

中间者最多就通过它自己的密钥修改签名，然后再把签名连同数据发给接收者。但可惜的是，接收者只有 CA 的公钥但没有中间者的公钥，因此接收者是无法用 CA 的公钥解密中间者发来的签名的；而一旦接收者发现解密错误，那么就会意识到这个数据已经被中间者改了，那么也不会接受这个数据。

六、最终解决方案

1. 客户端向服务端发送请求
2. 服务端给客户端发证书（里面包含了服务端的公钥）
3. 客户端拥有服务端的公钥后，通过非对称加密给服务端发对称密钥
4. 客户端和服务端进行对称加密