Question

我google了很多，很多答案都是是。例如：Is GET data also encrypted in HTTPS?但我们公司的高级安全工程师告诉我，URL不会被加密。

图片，如果URL已加密，DNS服务器如何找到主机并连接？

我认为这是非常强烈的观点，尽管它反对大多数答案。所以我真的很困惑，我的问题是：

https是否加密了请求中的所有内容？（包括URL，主机，路径，参数，标题）
如果是，DNS服务器如何解密请求并将其发送到主机服务器？

我尝试访问https://www.amazon.com/gp/css/homepage.html/ref=ya_surl_youracct，我的IE向服务器发送了两个请求：

首先：

CONNECT www.amazon.com:443 HTTP/1.0
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko
Host: www.amazon.com
Content-Length: 0
DNT: 1
Connection: Keep-Alive
Pragma: no-cache

第二

GET /gp/css/homepage.html/ref=ya_surl_youracct HTTP/1.1
Accept: text/html, application/xhtml+xml, */*
Accept-Language: en-US,zh-CN;q=0.5
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko
Accept-Encoding: gzip, deflate
Host: www.amazon.com
DNT: 1
Connection: Keep-Alive

似乎我的浏览器已请求两次：第一次是与主机建立连接（没有加密），第二次是通过https发送加密请求？我对吗？如果我正确理解这一点，当客户端使用https调用RESTFUL API时，它每次都会发送两次请求（连接和获取/发布）？

Answer 1

网址 IS 从浏览器离开目标服务器时加密。

浏览器会从URL中提取域名和端口，并使用它来解析DNS本身。然后它启动加密通道到目标服务器IP：端口。然后它通过该加密通道发送HTTP请求。

重要的部分是任何人，但您和目标服务器只能看到您正在连接到特定的IP地址和端口。他们无法说出任何其他内容（例如特定网址，GET参数等）。

在大多数情况下，攻击者甚至无法看到域名（尽管他们可以推断出是否存在DNS查找 - 如果它没有被缓存）。

要理解的重要一点是，DNS（域名服务）是一种完全不同的服务，具有与HTTP不同的协议。浏览器发出DNS查询请求以将域名转换为IP地址。然后它使用该IP地址发出HTTP请求。

但DNS服务器在任何时候都没有收到HTTP请求，除了为用户提供域名 - IP映射之外，它实际上什么都不做。

Answer 2

虽然其他响应是正确的，但除了浏览器和服务器之间的加密之外，还有许多其他注意事项。以下是一些需要考虑的事情......

解析服务器的IP地址。
浏览器使用TLS与服务器的IP地址建立TCP套接字连接。这是您在示例中看到的CONNECT。
请求通过加密会话发送到服务器。

如果这就是全部，那么你就完成了。没问题。

但等等，还有更多！

将字段放在GET而不是POST时会显示敏感数据......

有人查看服务器日志。这可能是一个史努比的员工，但它也可能是国家安全局或其他三个字母的政府机构，如果在审判中传唤，日志可能会成为公共记录。
攻击者导致网站加密回退到明文或破解密码。请查看Qualsys实验室的the SSL checker，了解网站是否容易受到此攻击。
页面上指向外部网站的任何链接都会将该页面的URI显示为引荐来源。用户ID和密码无意中通常以这种方式赠送给广告网络。我有时会在自己的博客中发现这些内容。
该URL在浏览器历史记录中可用，因此可供脚本访问。如果计算机是公共的（有人从酒店或机场休息室的客户PC检查您的网站），GET请求会将数据泄露给使用该设备的其他人。

正如我所提到的，我有时会在博客的引荐记录日志中找到ID，密码和其他敏感信息。在我的情况下，我联系推荐网站的所有者并告诉他们他们正在暴露他们的用户黑客攻击。一个不那么谨慎的人会在网站上添加评论或更新链接到他们自己的网站，目的是在他们的推荐人日志中收集敏感数据。

因此，贵公司的高级安全工程师认为，URL在许多地方都没有加密，因为这样做非常重要。您和其他受访者也是正确的，它是在浏览器的非常狭窄的用例中加密，在TLS会话的上下文中与服务器通信。也许您提到的混淆与这两个用例范围的差异有关。

请参阅：

Testing for Exposed Session Variables (OTG-SESS-004)
Session Management - How to protect yourself（请注意，＆＃34;始终使用POST＆＃34;会在此页面上反复重复。）
Client account hijacking through abusing session fixation on the provider

Answer 3

URL（也称为“统一资源定位器”）包含四个部分：

协议（例如https）
主机名（例如stackoverflow.com）
端口（并非总是包含在内，http通常为80，https为443）
路径和文件名称或查询

一些例子：

ftp://www.ftp.org/docs/test.txt
mailto:user@test101.com
news:soc.culture.Singapore
telnet://www.test101.com/

作为整个单元的URL实际上并未加密，因为它未完整传递。 URL实际上被分成比特，每个部分以不同的方式使用。例如。协议部分将告诉您的浏览器如何使用URL的其余部分，主机名将告诉它如何查找预期收件人的IP地址，并且端口将告诉它，以及使用哪个端口。 有效负载本身传递的URL的唯一部分是路径和查询，并且该部分已加密。

如果您查看raw中的HTTP请求，它看起来像这样：

GET /docs/index.html HTTP/1.1
Host: www.test101.com
Accept: image/gif, image/jpeg, */*
Accept-Language: en-us
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
(blank line)
--Body goes here--

您在上面的示例中看到的内容已通过。请注意，完整的URL无处可见。实际上可以完全省略主机头（它不用于路由）。此处显示的URL的唯一部分位于GET动词的右侧，并且仅包括原始URL的最右侧部分。协议和端口号在消息本身中没有出现。

简短回答：URL中端口号右侧的所有内容都包含在https请求的有效负载中，实际上是加密的。

https加密整个URL吗？

3 个答案: