HTTP 协议内容都是按照文本的方式明文传输的,这就导致在传输过程中出现一些被篡改的情况。例如臭名昭著的运营商劫持。显然, 明文传输是比较危险的事情,为此引入 HTTPS ,HTTPS
就是在 HTTP
的基础上进行了加密, 进一步的来保证用户的信息安全。
回过头来说,那么 HTTPS
是如何实现对数据加密的呢?为了解答这个问题,首先要引入一组概念:
加密:就是把 明文 (要传输的信息)进行一系列变换,生成 密文
解密:就是把 密文 再进行一系列变换,还原成 明文
密钥:在这个加密和解密的过程中,往往需要一个或者多个中间的数据,辅助进行这个过程,这样的数据称为 密 钥
加密的方式:加密是一个复杂的过程,方式有很多,目前我们讨论宏观过程将其分成两大类:对称加密 和 非对称加密。
概念: 对称加密其实就是通过同一个密钥 key
,把明文加密成密文,并且也能把密文解密成明文。
这个过程就类似
于按位异或操作:
明文=1234,对称密钥 key=6666
加密:密文=明文^key=1234^6666=7896
解密:明文=密文^key=7896^6666=1234
对称密钥工作过程:
通过对称加密,即使数据被黑客截获,但是由于没有密钥,无法对数据进行解密,因此可以保证数据传输的安全。
但是上述情况并不现实,对于服务器来说,通常要给很多个客户端提供服务,如果密钥全部都相同,那么当黑客作为客户端,也就可以获取到密钥 key
,这对于网络数据传输来说显然是行不通的;
因此为了杜绝以上情况,需要保证每个客户端与服务器之间的密钥是唯一的,此处就需要让客户端在于服务器建立连接的时候,生成一个自己的对称密钥 key,然后通过网络发送给服务器,此后每个客户端与服务器数据传输过程就通过各自的对称对称密钥实现加密传输。但是这样真的可行吗?我们先看一张示例图:
可以看到,由于密钥 key
是明文传输的,一旦传输过程中被黑客截获,那么后面的加密传输就是形同虚设了。因此 密钥的传输也必须加密传输 为此引入了非对称加密。
概念:
- 非对称加密要用到两个密钥,一个叫做 “公钥
pub
”,一个叫做 “私钥pri
”,并且公钥和私钥是配对的。- 此处约定自己留着的是私钥,公布给别人的是公钥。
- 可以通过私钥 pri 对明文加密,使用配对的公钥 pub 对密文解密;亦可以使用公钥 pub 对明文加密,使用配对的私钥 pri 对密文解密。
非对称密钥工作过程:
- 为了保证对称密钥能够安全到达服务器,引入非对称加密,保护对称密钥。非对称加密在完成对称密钥的传输后就结束了。
- 对称密钥相较于非对称密钥,效率要高很多。对于客户端和服务器的业务数据传输,通常使用对称加密的方式。
中间人攻击
那么引入了非对称加密,数据传输就彻底安全了吗?其实在这个过程中黑客还有另一种手段称作“中间人攻击”,黑客可以通过伪造公钥 pub
的方式获取对称密钥 key
,具体过程如下图:
很显然,通过上述“中间人攻击”的方式,黑客可以“神不知鬼不觉”地获取到使用非对称加密传输的对称密钥 key
,从而获取到接下来的业务传输数据。为了防止这种“中间人攻击”的情况发生,下面引入证书。
中间人攻击破解的关键就是能够让客户端信任公钥。服务器在搭建的时候就需要向权威机构提交材料,申请证书,证书中就包含了服务器自己的公钥 pub
和一些其他属性,其中一个关键的属性就是 加密的签名,这个签名是由证书的颁发机构根据证书中的所有属性按照一定的算法计算得到的校验和,并且使用颁发机构的一对非对称密钥 pub
(客户端操作系统内置)、pri
(机构自己持有) 中的私钥 pri
进行加密得到的。
引入证书之后,客户端就不再直接从服务器请求公钥了,而是直接请求服务器的证书:
可见证书起到的主要作用就是 校验:
- 客户端拿到证书后,首先使用系统中内置权威机构的公钥,针对证书中的 加密签名进行解密,得到初始签名
sum1
。- 客户端使用相同签名计算算法,基于证书中的属性重新计算,得到
sum2
。- 比较两个签名是否相同,如果相同,说明证书中的数据都是未篡改过的原始数据;如果不同,说明证书中的数据被篡改过,客户端浏览器弹窗报错。