目录
前言
上一篇文章介绍了HTTP协议,这篇文章主要说HTTPS的由来以及HTTP和HTTPS有什么区别。
HTTPS是基于HTTP的,只是比HTTP多了一层加密。 只要是在网络上进行传输的数据,HTTP协议格式传输都是明文传输的,都是存在被劫持的风险的,为了解决上述问题,此时就引入了加密,HTTPS这个协议就产生了。(主要介绍加密的过程)
明文:实际要传输的信息。
密文:明文经过加密后得到的信息。
加密:就是明文到密文的这个过程。
解密:就是密文到明文的过程。
密钥:在加密和解密的过程中需要用到的一把钥匙,就相当于是锁的钥匙一样,只有原配的钥匙才能进行开锁。
对称加密:只有一个密钥,key,明文+key => 密文; 密文 + key => 明文,在加密和解密的过程中使用的是同一个密钥(计算起来比较快)
非对称加密:需要两个密钥,一个叫做公钥(pub),一个叫做私钥(pri),明文+ pub => 密文;
密文 + pri => 明文,或者公钥和私钥反过来用也是可以的。
总结:
| 对称加密 | 明文 + key = 密文 ;密文 + key = 明文 |
| 非对称加密 | 明文 + pub = 密文;密文 + pri = 明文 或者是 明文 + pri = 密文; 密文 + pub = 明文 |
如下图:

但是此时对称加密有一个非常大 的问题:数据都是 在网络上进行传输的,只要是在网络上传输的数据就有中间的节点(交换机,路由器),此时既然是对称加密,客户端时需要自己生成一个密钥的,那服务器需要对数据进行解密,也需要这个密钥,所以客户端时需要把这个密钥通过网络传输的手段告知服务器密钥。
如果是一个黑客用手段攻击拿到了一个中间的节点,如果黑客没有这个密钥,就无法对数据进行解密,此时密文传输的数据安全性就会有很大的提升。
但是密钥key也是在网络中进行传输的,此时黑客是很有可能拿到这个密钥的,如果经过某一个中间节点拿到了key,此时黑客也就可以针对正在传输的数据进行解密了。
所以此时就引入了非对称加密;
如下图:

| 1. 首先服务器生成一对公钥和私钥,在客户端传输数据之前先向服务器请求公钥,服务器给客户端私钥之后,通过网络传输给客户端。 |
| 2. 客户端生成一对对称加密的密钥,然后用pub对key进行加密,然后传输给服务器。 |
| 3. 服务器就拿到了客户端生成了公钥key,之后就可以进行数据的传输了。 |
在服务器发送给客户端pub的过程中,黑客是可以拿到这个pub的,在客户端传输pub加密后的key,黑客此也是可以拿到的,但是pri(私钥)在服务器手里,所以黑客无法对客户端加密之后的数据进行解密,也就拿不到客户端生成的key,这就对key在传输的过程中进行了加密,安全性就有提升了一个等级。
客户端和服务器的业务数据的传输,仍然是使用对称加密的方式(对称加密速度快,成本低),为了保证对称密钥能够进行安全的传输,才引入了非对称加密,保护对称密钥,非对称加密在对称密钥传输完成之后,就可以不用了(非对称加密速度慢,成本高,但是只是在开始的时候使用一次)。
如下图:

还是同样的流程,客户端进行数据的传输之前先向服务器请求pub,服务器返回pub,但是在返回pub的过程中,黑客把这个pub拦截,之后自己生成一个pub2和pri2,此时把这个pub2传输回给客户端,客户端拿pub2对key进行加密,之后传输给服务器,在这个传输的过程中,黑客就拿到了pub2加密的key,之后用pri2对加密的key进行解密,此时黑客就拿到了key,之后用pub在对key加密,传输给服务器。
注:此时的黑客已经拿到key了,所以之后的加密的数据传输(是使用这个key进行对称加密的),就已经不安全了。
既然已经拿到了key,之后客户端和服务器之间数据的传输都是对称加密的,所以黑客想怎么解密就怎么解密了。
注:中间人攻击破解的关键是让客户端能够信任自己的公钥(pub2)。
详细流程如下图:

| 1. 客户端拿到证书之后,首先对证书进行校验 得到初始签名:客户端使用系统中内置的权威机构的公钥pub2,针对证书中加密后的签名进行解密,得到这个签名,设为sum1。 |
| 2. 计算现在的签名:客户端使用同样的签名的计算方法,基于证书中的属性重新计算,得到一个sum2 |
| 3. 比较两个签名是否相同,如果相同,说明证书中的数据都是没有被纂改过的原始数据。 |
| 4. 如果计算的签名是不同的,说明证书的数据是被纂改过的数据,此时客户端的浏览器弹框报错。 |
注:此时的黑客是可以在签名传输的过程中拿到签名的,由于黑客也可以拿到公钥pub2,此时也是可以对签名进行解密并且进行校验的,但是黑客不能纂改这个签名。
如果黑客要改这个签名的数据,需要进行一下步骤:
| 1. 首先对证书进行解密。 |
| 2. 解密之后将权威机构的公钥pub2换成自己的公钥 |
| 3. 由于公钥已经改变,而权威机构是根据签名的各个属性进行计算的校验和,公钥改变了,签名就需要重新进行计算,所以还需要重新计算签名 |
| 4. 对这个篡改过的签名重新进行加密(因为客户端要拿到的是一个加密后的签名,黑客不加密就直接穿帮了),就是这个环节出了问题; |
| 5. 黑客要想对这个签名重新加密,务必要知道权威机构的pri2(私钥),此时黑客是拿不到这个pri2的,所以就无法对数据进行重新加密。(如果黑客用自己的私钥进行加密,此时是非对称加密,那客户端就无法对签名解密,此时客户端也知道这个签名被篡改过了) |
综上表格所述,黑客是无法针对这个证书进行篡改然后拿到自己想要的数据并且不被发现的。
HTTPS引入的对称 加密 + 非对称加密 + 证书 ,这一套流程,不仅仅是HTTPS回涉及到,其他的场景中也会用到;HTTPS = HTTP + SSL(对称加密和非对称加密也是一个协议,称作SSL);
所以现在的应用层的协议基本都是用的HTTPS这个比较安全的协议,如果浏览器访问的一个请求是HTTP协议的,此时浏览器会给报出一个 ”存在风险“ 的 弹窗。