带有 GET 和 POST 的 SSL

信息安全 tls 休息
2021-08-17 09:23:34

我对安全性很陌生,所以请原谅我的基本问题,但是 SSL 是否加密 POST 请求而不是 GET 请求?

例如,如果我有两个请求

获取:www.mycoolsite.com/index?id=1&type=xyz

邮政

网站:www.mycoolsite.com/index { 参数:id=1&type=xyz }

假设某人能够拦截整个 GET 请求(读取 id 和类型)是否安全,但如果他们拦截 POST,他们将能够看到站点路径,但由于它通过 SSL,他们看不到id和类型的参数?

4个回答

现在,问题是,你知道 HTTP 请求是什么的吗?

好吧,假设不是,这里有一个例子:

GET /test?param1=hello&param2=world HTTP/1.1
Host: subdomain.test.com
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20100101 Firefox/10.0.1
Accept: image/png,image/*;q=0.8,*/*;q=0.5
Accept-Language: en-gb,en;q=0.5
Accept-Encoding: gzip, deflate
DNT: 1
Connection: keep-alive

所有这些信息都封装在 SSL 传输中 - 正如您对答案的评论中所说的那样。这意味着:

  • 获取参数是加密的。
  • HTTP 正文(post 参数)是加密的。

什么不一定安全:

  • 您要的主机。如今,大多数 Web 服务器都支持Host: something参数,因此一台 Web 服务器可以在一个接口和 IP 地址上处理多个域。显然,此标头加密的,但是,如果您对站点运行非 https 流量,则应该清楚您可能连接到哪些主机。即使不是这样,反向 DNS 肯定会告诉您该 IP 上托管的内容,您可能可以从那里做出合理的猜测。
  • 您的浏览器/客户端信息。不幸的是,每个 https 客户端都是不同的,它的协商过程可能会泄露它运行的平台,或者它是什么浏览器。无论如何,这不是世界末日,这只是一个可以理解的事实。

POST 请求看起来类似于 get 请求,只是它们包含一个主体。这可能看起来像这样:

POST /testpost HTTP/1.1
Host: subdomain.test.com
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20100101 Firefox/10.0.1
Accept: image/png,image/*;q=0.8,*/*;q=0.5
Accept-Language: en-gb,en;q=0.5
Accept-Encoding: gzip, deflate
DNT: 1
Connection: keep-alive

param1=hello&param2=hello

当然,还有一些更复杂的变体,但本质上它无论如何都是加密的。

我没有在其他回复中看到这一点,但是即使使用 SSL,您通常也不应该在 GET 请求中放入秘密信息(密码),而是使用 POST。为什么?带有敏感信息的 URL 一般会在两端记录;例如,在您的浏览器历史列表 (https://www.example.com?user=me&password=MyPassword) 以及服务器上的日志中。POST 信息(尤其是密码)通常不会写入网络服务器日志,尽管显然可以配置为记录 - 所以最好不要在不同的站点重复使用(或使用类似的)密码。

SSL 加密并确保整个连接的真实性,包括请求的方法和 URL。GET 与 POST 一样受到保护。

当 SSL 按预期工作时,窃听者只能看到哪个 IP 地址连接到哪个 IP 地址(以及在哪个端口,但通常是 443)、在什么时间以及连接了多少。如果同一台机器上有多个虚拟主机,攻击者无法知道您正在联系哪一个(但是,窃听者可能会在 HTTPS 请求之前看到您的 DNS 请求并进行合理猜测)。所有这些信息也经过身份验证:主动攻击者无法扮演中间人并修改传输中的数据。

可能使 SSL 无法按预期工作的事情:

  • 应用程序滥用,其中一些数据意外地通过普通 HTTP 发送。
  • SSL 协议中罕见的漏洞之一,例如最近的BEAST 漏洞
  • 错误的证书操作,允许攻击者冒充服务器,因为服务器的证书已被泄露,证书颁发机构不正确地将证书传递给攻击者,或者因为客户端没有正确检查服务器的证书。
    • 在这一点上,请记住 SSL,因为它大部分时间都在使用,它对服务器进行身份验证,而不是对客户端进行身份验证。服务器不能假设关于客户端的任何事情。
  • 侧信道攻击可能会向窃听者透露一些信息。例如,参与者发送数据的确切时间可能会揭示数据的计算方式以及数据的性质。攻击者也知道每个数据包的大小。如何揭示这一点取决于参与者是否采取预防措施以及信息的性质。与下载文件相比,实时对话更容易受到这种流量分析。

另请参阅观察正在建立的 HTTPS 连接的人怎么可能不知道如何解密它?对于一些背景。

只是添加一个小细节,关于这是如何通过 HTTP 完成的。
您可能想知道(或者您应该知道,如果您熟悉SSL 握手),如何创建 SSL 通道,而不发送未加密的 GET 请求?如果我的请求必须通过代理怎么办?这怎么可能?

HTTP v1.1 引入了一种CONNECT HTTP 方法,它基本上通过代理向服务器发送一个简化的请求,只包含最简单的主机 URL(没有任何额外的参数、标头或正文)。基于此请求,构建 SSL 隧道,然后通过它发送原始 GET(或 POST)请求。