https是否加密整个URL？
Does https encrypt the whole URL?
我在谷歌上搜索了很多，很多答案都是是的。例如： 但是我们公司的高级安全工程师告诉我 URL 不会被加密。
Image that, if the URL was encrypted, how does the DNS server find the host and connect?
我认为这是非常有说服力的观点，尽管它与大多数答案相反。所以我真的很困惑，我的问题是：
- https是否对请求中的所有内容进行加密？ （包括URL、主机、路径、参数、headers）
- 如果是，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 时，它每次都会发送两次请求（连接和 get/post）？
URL（也称为"Uniform Resource Locator"）包含四个部分：
- 协议（例如 https）
- 主机名（例如whosebug.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 的唯一部分是路径和查询，并且该部分已加密。
如果您查看原始的 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 请求的有效负载中，并且实际上已加密。
URL是从离开浏览器到到达目标服务器的这段时间加密的。
浏览器从 URL 中提取域名和端口并使用它来解析 DNS 本身。然后它启动到目标服务器 IP:port 的加密通道。然后它通过该加密通道发送 HTTP 请求。
重要的是除您之外的任何人，目标服务器只能看到您连接到特定的 IP 地址和端口。他们不能告诉其他任何东西（比如特定的 URLs、GET 参数等）。
在大多数情况下，攻击者甚至看不到域（尽管他们可以推断出是否确实存在 DNS 查找 - 如果它没有被缓存）。
最重要的是要了解 DNS（域名服务）是一种完全不同的服务，使用与 HTTP 不同的协议。浏览器发出 DNS 查找请求以将域名转换为 IP 地址。然后它使用该 IP 地址发出 HTTP 请求。
但是 DNS 服务器在任何时候都不会收到 HTTP 请求，而且除了为用户提供域名 - IP 映射之外，它实际上不会做任何事情。
虽然其他回答就目前而言是正确的，但除了浏览器和服务器之间的加密之外，还有许多其他考虑因素。这里有一些事情需要考虑...
- 服务器IP地址已解析
- 浏览器使用 TLS 与服务器的 IP 地址建立 TCP 套接字连接。这是您在示例中看到的
CONNECT。
- 请求通过加密会话发送到服务器。
如果仅此而已，您就完成了。没问题。
等等，还有更多！
在 GET 而不是 POST 中显示敏感数据时...
- 有人查看服务器日志。这可能是一个史努比员工，但也可能是国家安全局或其他三个字母的政府机构，或者如果在审判中被传唤，日志可能会变成 public 记录。
- 攻击者导致网站加密退回到明文或破解的密码。查看 Qualsys 实验室的 the SSL checker，看看某个站点是否易受此攻击。
- 指向外部站点的页面上的任何 link 都会将页面的URI 显示为引荐来源网址。用户 ID 和密码通常无意中以这种方式泄露给广告网络。我有时会在自己的博客中发现这些。
- URL 在浏览器历史记录中可用，因此可供脚本访问。如果计算机 public（有人在酒店或机场休息室的访客 PC 上查看您的网站），
GET 请求会将数据泄露给使用该设备的任何其他人。
正如我提到的，我有时会在我的博客的引用日志中找到 ID、密码和其他敏感信息。就我而言，我联系了推荐网站的所有者并告诉他们他们正在让他们的用户受到黑客攻击。一个不那么谨慎的人会在他们自己的网站上使用 link 向网站添加评论或更新，目的是在他们的引荐来源日志中收集敏感数据。
所以贵公司的高级安全工程师是正确的，URL 在很多地方都没有加密，这样做是非常重要的。您和其他受访者也是正确的，它 是 在浏览器在 TLS 会话上下文中与服务器对话的非常狭窄的用例中加密的。也许你提到的混淆与这两个用例的范围不同有关。
另请参阅：
我在谷歌上搜索了很多，很多答案都是是的。例如： 但是我们公司的高级安全工程师告诉我 URL 不会被加密。
Image that, if the URL was encrypted, how does the DNS server find the host and connect?
我认为这是非常有说服力的观点，尽管它与大多数答案相反。所以我真的很困惑，我的问题是：
- https是否对请求中的所有内容进行加密？ （包括URL、主机、路径、参数、headers）
- 如果是，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 时，它每次都会发送两次请求（连接和 get/post）？
URL（也称为"Uniform Resource Locator"）包含四个部分：
- 协议（例如 https）
- 主机名（例如whosebug.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 的唯一部分是路径和查询，并且该部分已加密。
如果您查看原始的 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 请求的有效负载中，并且实际上已加密。
URL是从离开浏览器到到达目标服务器的这段时间加密的。
浏览器从 URL 中提取域名和端口并使用它来解析 DNS 本身。然后它启动到目标服务器 IP:port 的加密通道。然后它通过该加密通道发送 HTTP 请求。
重要的是除您之外的任何人，目标服务器只能看到您连接到特定的 IP 地址和端口。他们不能告诉其他任何东西（比如特定的 URLs、GET 参数等）。
在大多数情况下，攻击者甚至看不到域（尽管他们可以推断出是否确实存在 DNS 查找 - 如果它没有被缓存）。
最重要的是要了解 DNS（域名服务）是一种完全不同的服务，使用与 HTTP 不同的协议。浏览器发出 DNS 查找请求以将域名转换为 IP 地址。然后它使用该 IP 地址发出 HTTP 请求。
但是 DNS 服务器在任何时候都不会收到 HTTP 请求，而且除了为用户提供域名 - IP 映射之外，它实际上不会做任何事情。
虽然其他回答就目前而言是正确的，但除了浏览器和服务器之间的加密之外，还有许多其他考虑因素。这里有一些事情需要考虑...
- 服务器IP地址已解析
- 浏览器使用 TLS 与服务器的 IP 地址建立 TCP 套接字连接。这是您在示例中看到的
CONNECT。 - 请求通过加密会话发送到服务器。
如果仅此而已，您就完成了。没问题。
等等，还有更多！
在 GET 而不是 POST 中显示敏感数据时...
- 有人查看服务器日志。这可能是一个史努比员工，但也可能是国家安全局或其他三个字母的政府机构，或者如果在审判中被传唤，日志可能会变成 public 记录。
- 攻击者导致网站加密退回到明文或破解的密码。查看 Qualsys 实验室的 the SSL checker，看看某个站点是否易受此攻击。
- 指向外部站点的页面上的任何 link 都会将页面的URI 显示为引荐来源网址。用户 ID 和密码通常无意中以这种方式泄露给广告网络。我有时会在自己的博客中发现这些。
- URL 在浏览器历史记录中可用，因此可供脚本访问。如果计算机 public（有人在酒店或机场休息室的访客 PC 上查看您的网站），
GET请求会将数据泄露给使用该设备的任何其他人。
正如我提到的，我有时会在我的博客的引用日志中找到 ID、密码和其他敏感信息。就我而言，我联系了推荐网站的所有者并告诉他们他们正在让他们的用户受到黑客攻击。一个不那么谨慎的人会在他们自己的网站上使用 link 向网站添加评论或更新，目的是在他们的引荐来源日志中收集敏感数据。
所以贵公司的高级安全工程师是正确的，URL 在很多地方都没有加密，这样做是非常重要的。您和其他受访者也是正确的，它 是 在浏览器在 TLS 会话上下文中与服务器对话的非常狭窄的用例中加密的。也许你提到的混淆与这两个用例的范围不同有关。
另请参阅：