【问题标题】:Is GET data also encrypted in HTTPS?GET 数据是否也在 HTTPS 中加密?
【发布时间】:2011-05-07 18:58:27
【问题描述】:

当你得到

https://encrypted.google.com/search?q=%s

%s 查询是否加密?还是只是回应? 如果不是,为什么 Google 还要对其公开内容进行加密?

【问题讨论】:

    标签: https http-get


    【解决方案1】:

    整个请求都被加密了,包括 URL,甚至是命令 (GET)。代理服务器等介入方唯一可以收集的信息是目标地址和端口。

    但是请注意,TLS 握手的 Client Hello 数据包可以通过 SNI extension(感谢 @hafichuk)以纯文本形式公布完全限定域名,所有现代主流浏览器都使用该域名,尽管有些仅在较新的浏览器上使用操作系统。

    编辑:(因为这只是给我一个“好答案”徽章,我想我应该回答整个问题......)

    整个响应也是加密的;代理不能拦截它的任何部分。

    Google 通过 https 提供搜索和其他内容,因为并非所有内容都是公开的,而且您可能还希望对 MITM 隐藏一些公开内容。无论如何,最好让谷歌answer for themselves

    【讨论】:

    • 我对 URL 被加密的说法有点不高兴。主机名不被视为 url 的一部分吗?如果是这样,则该陈述是错误的。无法向 ISP/代理服务器隐藏主机名/IP 地址,就像在发送物理邮件时无法隐藏目标地址一样。
    • @Abhishek:主机名不在 TCP/IP 标头中。我在回答中涵盖了 IP 地址。
    • 加密。这是为了支持基于名称的虚拟主机(相对于基于 IP)。 @MarceloCantos 完全正确,URL 的其余部分(即 GET 命令)已加密。这在RFC 4366 中有介绍
    • @hafichuk:谢谢。我没有意识到 TLS 可以宣传 fqdn。上次我尝试设置 https 多服务器时(我承认是几年前),通过单个 ip 似乎是不可能的。
    • 对包含域名的 TLS 非常重要的补充:不要忘记明文 DNS 请求也包括域名。有可能看到您加密的 HTTPS 流量的人也可以看到您的 DNS 请求。
    【解决方案2】:

    在传输请求之前,连接会被加密。所以是的,请求也被加密了,包括查询字符串。

    【讨论】:

      【解决方案3】:

      一切都是加密的,但是您需要记住,您的查询将保留在服务器的日志中,并且可以被各种日志分析器等访问(这通常不是 POST 请求的情况)。

      【讨论】:

      • 哪些服务器?谁可以访问?
      • @Jader 至少是该服务器的管理员和黑客。使用 POST 请求,信息不会保留在日志中,因此除非明确记录,否则日志没有问题。 GET 查询确实保留在日志中,如果日志发生任何情况(或管理员决定将这些日志用于任何不良活动),您就有麻烦了。
      【解决方案4】:

      SSL 发生在头部解析之前,这意味着:

      Client creates Request
      Request gets encrypted
      Encrypted request gets transmitted to the Server
      Server decrypts the Request
      Request gets parsed
      

      一个请求看起来像这样(不记得确切的语法,但这应该足够接近):

      GET /search?q=qwerty HTTP/1.1
      Host: www.google.de
      

      这也是为什么在同一个 IP 上为多个主机使用不同的 SSL 证书是有问题的,所请求的主机名在解密之前是未知的。

      【讨论】:

      • HTTP/1.1 位于第一行的末尾。
      • @Marcelos Cantos:谢谢,我已经有一段时间没有手动编写 HTTP 请求了。
      【解决方案5】:

      是的,它是安全的。 SSL 加密一切。

      POST 请求的摘录:

      POST /foo HTTP/1.1
      ... some other headers
      

      GET 请求摘录:

      GET /foo?a=b HTTP/1.1
      ... some other headers
      

      在这两种情况下,在套接字上发送的任何内容都是加密的。客户端在 GET 请求期间在其浏览器中看到参数这一事实并不意味着中间人会看到相同的参数。

      【讨论】:

        【解决方案6】:

        HTTPS 在任何 HTTP 数据传输之前建立底层 SSL 连接 转移。这可确保所有 URL 数据(除了 主机名,用于建立连接)单独携带 在这个加密的连接中,并受到保护 中间人攻击的方式与任何 HTTPS 数据相同。

        以上内容来自 Google Answers 的非常全面的答案,位于此处:

        http://answers.google.com/answers/threadview/id/758002.html#answer

        【讨论】:

          【解决方案7】:

          使用 HTTPS 时 GET 请求被加密 - 实际上这就是安全网站需要具有唯一 IP 地址的原因 - 在解密之前无法从请求中获取预期的主机名(或虚拟目录)。

          【讨论】:

          • JFYI:有一个 TLS 扩展可以让客户端指定主机名,因此服务器可以选择相应的证书。
          • @Eugene:谢谢 - 我知道 TLS 扩展,但只是在最松散的意识中 - 我不知道细节或它实际上可能(或可能不)有多广泛使用。
          【解决方案8】:

          URL 本身是加密的,因此查询字符串中的参数不会直接通过网络传输。

          但是,请记住,包含 GET 数据的 URL 通常由网络服务器记录,而 POST 数据很少记录。因此,如果您打算做类似/login/?username=john&password=doe 的事情,那么不要;请改用 POST。

          【讨论】:

          • +1 谢谢。这是在我自己的物理服务器上,所以我不太担心日志,但对于在共享托管环境中考虑这一点的任何人来说,这是一个很好的考虑。考虑到这一点也很重要,因为我会以这种方式转移信用卡号码,并且肯定不想记录它们:)
          • 它是你自己的盒子并不重要。您也不希望拥有它的其他任何人(即邪恶的黑客)以纯文本形式查看这些密码。或者那些 CC 号码(假设您没有将这些号码也存储在其他地方)。
          • 您应该将这些放在 POST 正文中,而不是 URL 查询字符串中。
          • 您是否担心 wbeserver 对其日志的访问限制少于对网站数据(数据库、文件等)的访问限制?恕我直言,只要数据安全地访问网络服务器,一切都很好。唯一有权访问网络服务器的人应该被认为是可靠的,因为如果他们不可靠,您将无法阻止他们以某种方式读取数据。
          • 当密码通过 GET 发送并记录在访问日志中时,它们是 NOT 散列的。我相信这是最大的问题。如果您可以在 Web 服务器的访问日志中查找它们,那么在数据库中拥有散列密码并不重要。它们应该在数据库中进行哈希处理,如果没有,请修复它。
          【解决方案9】:

          安全发送主机名之后的 URL 部分。

          例如, https://somewhere.com/index.php?NAME=FIELD

          /index.php?NAME=FIELD 部分已加密。 somewhere.com 不是。

          【讨论】:

            【解决方案10】:

            我刚刚通过 HTTPS 连接到一个网站并传递了一堆 GET 参数。然后我用wireshark嗅探网络。使用 HTTP,发送的 URL 是未加密的,这意味着我可以很容易地看到 URL 中的所有 GET 参数。使用 HTTPS,一切都被加密了,我什至看不到哪个数据包是 GET 命令,更不用说它的内容了!

            【讨论】:

              【解决方案11】:

              上面有点混乱:

              1. 不管怎么说,不再需要拥有唯一的 IP 地址,因为 SNI 字段告诉服务器使用哪个证书
              2. 除了非常早的 SNI 请求外,所有内容都已加密。这告诉服务器使用哪个名称以及使用哪个证书。也就是说,服务器名称指示符未加密发送,以便服务器和客户端可以建立并使用安全连接进行其他所有操作。

              所以,回答原来的问题。除了主机名(我猜是端口)之外的所有内容都在两个方向上都是安全的。

              【讨论】:

                猜你喜欢
                • 2012-04-09
                • 2018-01-11
                • 1970-01-01
                • 2015-11-27
                • 2010-09-16
                • 2011-09-05
                • 1970-01-01
                • 1970-01-01
                相关资源
                最近更新 更多