Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

HTTPS #70

Open
lovelmh13 opened this issue Jun 11, 2021 · 0 comments
Open

HTTPS #70

lovelmh13 opened this issue Jun 11, 2021 · 0 comments

Comments

@lovelmh13
Copy link
Owner

HTTPS

在 HTTP 传输中,内容都是以明文的方式传递的,不安全,很容易被获取到。这个方式叫做中间人攻击。如果要安全的传输内容,就要使用 HTTPS,对请求和响应的内容进行加密。

HTTPS 在 HTTP 和 TCP 请求之间,多加了一层 TLS 安全层来对数据进行加密解密。

img

使用对称加密

对称加密是最简单方便的加密,发送端和接收端都是用相同的方式来进行加解密。

  • 在浏览器端,发送对称加密套件列表和一个随机数 client-random,给服务器。(套件即方法)浏览器的加密套件列表就是浏览器支持的加密方法的列表。
  • 服务器保存 client-random 并根据浏览器发来的对称加密列表选出一个加密方法来,发送一个对应的对称加密套件,并加上一个服务器端的随机数 service-random 给浏览器。
  • 浏览器和服务器分别返回确认消息。
  • 浏览器端和服务器端此时有相同的 client-random 和 service-random 和加密套件,此乃对称加密的对称体现。然后两端用一样的加密方法,把 client-random 和 service-random 混合起来生成一个密钥
  • 有了密钥,就可以对数据进行加密了

img

但是,对称加密有个问题,就是生成密钥之前的协商过程,加密套件和 client-random 和 service-random 是使用明文传递的,这样也会被拦截。

使用非对称加密

为了避免加密套件和随机数被拦截到,改用非对称加密。非对称加密使用公私钥来进行加密。

服务器会生成两种密钥 ,一个是公钥一个是私钥。服务器会把公钥发给浏览器端。自己留下私钥,从不公开。如果只有公钥,没有私钥,那么也不能解密。

公钥加密的数据只能用私钥解,私钥加密的数据只能用公钥解。

  • 浏览器端发送非对称加密套件列表给服务器。

  • 服务器选择一个非对称加密套件和一个公钥给浏览器(在非对称加密时服务器上需要有浏览器加密的公钥和服务器来解密的私钥,这个公钥需要传给浏览器,让浏览器对数据进行加密)。

  • 浏览器和服务器互相返回确认消息。

    img

有了公钥的浏览器,就可以对数据进行加密了,只有有对应私钥才可以对公钥加密的数据进行解密。所以及时被别人拿到了公钥也不用担心数据被解密。

不过这里存在一个明显的问题,就是黑客也可以获取到公钥,服务器端只能用私钥加密,私钥加密的数据可以用公钥来解,这样就不能做到服务器端发送数据的安全性了,黑客可以解密并篡改服务器端发送的数据,浏览器能够收到数据,那攻击者必然也能够收到数据。

所以,使用非对称加密虽然可以保证浏览器发送的数据安全,但是并不能保证无服务器发送来的数据是安全的

非对称加密还有一个缺陷:非对称的加密效率太低,会影响用户体验。

混合加密

我们既想做到效率高,又想做到安全,于是乎就把对称加密和非对称加密混合起来用,结合他们的长处,规避短处,来满足我们希望的效果。

  • 浏览器发送对称加密套件列表和非对称加密套件列表和 client-random 给服务器。

  • 服务器保存 client-random。选择一个对称加密套件和一个非对称加密套件,生成一个 service-random,然后把对称加密套件、非对称加密套件、 service-random 和 公钥发给浏览器。

  • 浏览器拿到公钥,再生成一个随机数 pre-master。使用公钥对这个 pre-master 加密,把这个加密后的 pre-master 发送给服务器。

  • 服务器拿到加密后的 pre-master 对 pre-master 进行解密,返回确认。

  • 此时,浏览器和服务器都拥有了相同的 client-random、service-random 和 pre-master,此乃对称

    img

由于浏览器和服务器是同一套方法来加密的,又是对称的,所以生成的密钥也是一样的。

在这个过程中,pre-master 是在浏览器端经过公钥加密生成后再传输的,所以黑客拿到了 pre-master 也没有私钥,生成不出解密的密钥,这就保证了数据的安全性。

数字证书

即使是经过了混合加密,但是如果黑客通过 DNS 劫持,直接把被访问的网站的 IP 改成了他自己的 IP 地址,那么我们再怎么加密也于事无补了。

所以,需要服务器证明,「我即是我」。

通过 CA 机构办法的数字证书,可以来证明。数字证书里面包括服务器的身份和服务器的公钥。

img

在混合加密的基础上,做了两点改变:

  1. 服务器不再发送公钥,而是直接发送证书,公钥就包含在证书里面。
  2. 浏览器收到服务器返回的加密套件和随机数以及证书以后,先验证证书的身份,再生成 pre-master。

验证证书

验证证书主要是通过摘要信息来验证。

  • 浏览器获取到证书中的明文信息,使用 CA 签名时相同的 Hash 函数来计算出信息摘要 A
  • 用对应 CA 的公钥解密签名,得到信息摘要 B
  • 比较信息摘要 A 和 信息摘要 B,一致的话,就是合法的证书

具体其他数字证书的相关问题,可以看极客时间 《浏览器工作原理与实践》

参考

极客时间 《浏览器工作原理与实践》

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant