理解 HTTPS 的加密原理

HTTPS 的原理

协议的名称

HTTPS 协议(HyperText Transfer Protocol over Secure Socket Layer):可以理解为 HTTP+SSL/TLS, 在 TCP 层到 HTTP 层之间加了一层 SSL。

在 HTTPS 技术中用到加密算法

  • 对称加密 : 加密和解密数据使用同一个密钥。这种加密方式的优点是速度很快,常见对称加密的算法有 AES;
  • 非对称加密: 加密和解密使用不同的密钥,叫公钥和私钥。数据用公钥加密后必须用私钥解密,数据用私钥加密后必须用公钥解密。一般来说私钥自己保留好,把公钥公开给别人,让别人拿自己的公钥加密数据后发给自己,这样只有自己才能解密。 这种加密方式的特点是速度慢,CUP 开销大,常见非对称加密算法有 RSA;
  • Hash: hash 是把任意长度数据经过处理变成一个长度固定唯一的字符串,但任何人拿到这个字符串无法反向解密成原始数据,Hash 常用来验证数据的完整性。常见 Hash 算法有 MD5、SHA1、SHA256

HTTP 的风险有哪些?

HTTP 请求过程中,客户端与服务器之间没有任何身份确认的过程,数据全部明文传输。我们收到的结果是否为被篡改后的结果,当然,更无法保证,即使没动过的数据,是不是会被窃听。

601940742

我们叫图中那位黑客「中间人」,也就会造成上文所说的中间人攻击。HTTP 传输面临的风险有:

  • 窃听风险:中间人可以获知通信内容。
  • 篡改风险:中间人可以修改通信内容。
  • 冒充风险:中间人可以冒充他人身份参与通信。

HTTPS 是如何保证安全的呢?

常见的加密有两种:对称加密和非对称加密 先看看使用对称加密时的情况。客户端和服务器之间共用一个密钥。有两个问题:

  1. 不同的客户端、服务器数量庞大,所以双方都需要维护大量的密钥,维护成本很高
  2. 因每个客户端、服务器的安全级别不同,密钥极易泄露

再来看看非对称加密的情况。客户端用服务器的公钥加密发送请求内容,服务器在返回时用公钥加密后响应内容。但在服务器返回内容的阶段。中间人截取返回的内容,后用公钥解密,依然可以截获数据。

这两中加密方法都存在安全隐患和限制。于是乎,我们又想到了一种升级的加密方式:对称与非对称结合。

3274134858

先用非对称加密的方式传输密钥,然后用对称加密传输数据,这样就可以避免了前面分析的传输过程中对称加密密钥泄露公钥公开导致的截获数据 但是还有另外的问题:

  • 客户端如何获得公钥?
  • 如何确认服务器的公钥是真实的,而不是被中间人替换成他自己的呢?

解决的方案是引入一个可信赖的第三方机构,服务器向这个机构申请 SSL 证书。这个证书中有服务器的公钥,以及这个公钥经过 Hash 运算后的值叫数字签名(来保证书的可靠性)

在客户端发起请求时,服务端先返回他的 SSL 证书。客户端在接受到服务端发来的 SSL 证书时,会对证书的真伪进行校验,以浏览器会做如下动作:

  • 首先浏览器读取证书中的证书所有者、有效期等信息进行一一校验
  • 浏览器开始查找操作系统中已内置的受信任的证书发布机构 CA,与服务器发来的证书中的颁发者 CA 比对,用于校验证书是否为合法机构颁发。
  • 如果找不到,说明服务器发来的证书是不可信任的,浏览器就会报错。
  • 如果找到,那么浏览器就会从操作系统中取出 颁发者 CA 的公钥,然后对服务器发来的证书里面的签名进行解密
  • 浏览器使用相同的 hash 算法计算出服务器发来的证书的 hash 值,将这个计算的 hash 值与证书中签名做对比。如一致则确定是服务器的公钥并没被中间人冒充。

拿到了确定的服务器公钥后,证书的使命也就此完成了。他让我们客户端获取到了服务器的公钥、并且确认这个公钥是没有被替换过的。 此时浏览器就可以用这个服务器的公钥,再随机生成一个用于之后对称加密的密钥,并将它用证书上的服务器公钥来 RSA 加密发送给服务器。服务器拿到后用他的私钥解密出对称加密的密钥。此时,就让服务器和客户端安全的知道了之后通讯的对称加密密钥。

这就是目前 HTTPS 的原理。左一个加密右一个加密,让我们不好理解。经过自己的一番折腾发现在读完参考文章后,把基本的加密算法的弄清楚,再通过自己扮演,客户端、服务器、证书颁发机构。在每一个步骤手动的去模拟一下,再帮他们来进行加密解密(使用在线工具),这样就更好理解。