使用TLS/SSL(HTTPS)加密时是否加密了所有URL？我想知道,因为我希望在使用TLS/SSL(HTTPS)时隐藏所有URL数据.
如果TLS/SSL为您提供全面的URL加密,那么我不必担心从URL隐藏机密信息.
1> Marc Novakow..：
是的,SSL连接位于TCP层和HTTP层之间.客户端和服务器首先建立安全的加密TCP连接(通过SSL/TLS协议),然后客户端将通过该加密的TCP连接发送HTTP请求(GET,POST,DELETE ...).
值得注意的是@Jalf在关于问题本身的评论中提到的事情.URL数据也将保存在浏览器的历史记录中,这可能是长期不安全的.
但请注意,URL的DNS解析可能未加密.因此,有人嗅探您的流量可能仍然可能会看到您尝试访问的域.
不只是GET或POST.也可以是DELETE,PUT,HEAD或TRACE.
SNI打破了URL加密的"主机"部分.你可以用wireshark自己测试一下.有一个SNI选择器,或者您可以在连接到远程主机时查看SSL数据包.
是的,它可能是浏览器历史记录的安全问题.但在我的情况下,我不使用浏览器(原来的帖子也没有提到浏览器).在本机应用程序中使用幕后自定义https调用.这是确保应用程序的服务器连接安全的简单解决方案.
2> evilSnobu..：
由于没有人提供线捕获,这里是一个.
服务器名称(URL的域部分)ClientHello以纯文本形式显示在数据包中.
以下显示了一个浏览器请求:
https://i.stack.imgur.com/path/?some=parameters&go=here
有关 TLS版本字段的更多信息,请参阅此答案(其中有3个 - 不是版本,每个字段都包含版本号!)
来自https://www.ietf.org/rfc/rfc3546.txt:
3.1.服务器名称指示
[TLS]没有为客户端提供一种机制来告诉服务器它正在联系的服务器的名称. 客户端可能希望提供此信息以促进与在单个底层网络地址处托管多个"虚拟"服务器的服务器的安全连接.
为了提供服务器名称,客户端可以在(扩展)客户端hello中包含"server_name"类型的扩展名.
简而言之:
FQDN(URL的域部分)可能被发送以明文内部ClientHello分组如果使用SNI扩展
URL(/path/?some=parameters&go=here)的其余部分没有业务,ClientHello因为请求URL是HTTP事物(OSI第7层),因此它永远不会出现在TLS握手(第4层或第5层)中.这会后来在一个GET /path/?some=parameters&go=here HTTP/1.1HTTP请求中,后的安全 TLS通道建立.
执行摘要
域名可以明确传输(如果在TLS握手中使用SNI扩展),但URL(路径和参数)始终是加密的.
完美的答案,从A到Z的完整解释.我喜欢执行摘要.让我的一天成为@evilSnobu
完美的答案,upvote!仍然考虑客户端部分,因为浏览器历史可能是泄漏.但是,关于传输层,URL参数是加密的.
您可能想用TLS 1.3加密SNI扩展名的事实来更新此答案，而最大的CDN就是这样做的：https://blog.cloudflare.com/encrypted-sni/当然，数据包嗅探器可以做到反向DNS查找您要连接的IP地址。
3> Zach Scriven..：
正如其他 答案已经指出的那样,https"URL"确实是加密的.但是,您在解析域名时的DNS请求/响应可能不是,当然,如果您使用的是浏览器,您的URL也可能被记录下来.
并且URL记录很重要,因为有Javascript黑客允许完全不相关的网站测试给定的URL是否在您的历史记录中.您可以通过在其中包含一个长的随机字符串来创建一个不可思议的URL,但如果它是一个公共URL,则攻击者可以告诉它已被访问过,如果它有一个短信,那么攻击者就可以强行攻击以合理的速度.
@SteveJessop,请提供*"Javascript hacks的链接,允许完全不相关的网站测试给定的URL是否在您的历史记录中"*
@Pacerier:当然是黑客攻击日期,但当时我所谈论的内容是/sf/ask/17360801/没有检查的吧.在2010年这是一个很大的问题,这些问题正在被调查,攻击得到了改进,但我现在并没有真正关注它.
@Pacerier:更多例子:http://webdevwonders.com/use-http-status-code-to-check-facebook-login-status/,http://webdevwonders.com/use-iframe-in-scrollable-div -to-读取浏览历史/
4> Peter Štibra..：
整个请求和响应都是加密的,包括URL.
请注意,当您使用HTTP代理时,它知道目标服务器的地址(域),但不知道此服务器上的请求路径(即请求和响应始终是加密的).
5> 小智..：
我同意以前的答案:
要明确:
使用TLS,URL的第一部分(https://www.example.com/)在构建连接时仍然可见.第二部分(/ herearemygetparameters/1/2/3/4)受TLS保护.
但是,为什么不应该在GET请求中放置参数有很多原因.
首先,正如其他人已经提到的那样: - 通过浏览器地址栏泄漏 - 历史泄漏
除此之外,您通过http referer泄露URL:用户在TLS上看到站点A,然后单击指向站点B的链接.如果两个站点都在TLS上,则对站点B的请求将包含站点A中的完整URL.请求的referer参数.站点B的管理员可以从服务器B的日志文件中检索它.)
@EJP,由于所有现代网络浏览器都使用的[SNI](https://en.wikipedia.org/wiki/Server_Name_Indication),域名可见.另请参阅EFF的[this diagram](https://www.eff.org/files/tor-https-1.png),表明任何人都可以看到您正在访问的网站的域名.这与浏览器可见性无关.这是关于窃听者可见的内容.
@trusktr:浏览器不应该从HTTPS页面发送Referer标头.这是[HTTP规范的一部分](https://tools.ietf.org/html/rfc2616#section-15.1.3).
@MartinGeisler,关键字是"应该".浏览器并不太关心"应该"(而不是"必须").从您自己的链接:*"强烈建议用户能够选择是否发送Referer字段.例如,浏览器客户端可以有一个切换开关用于公开/匿名浏览,这将分别**启用**/禁用发送Referer和From信息"*.Ops,这正是Chrome所做的.即使您处于隐身模式**,Chrome也会泄漏推荐人**.
@EJP你不明白Tobias在说什么.他说如果你点击网站A上的链接将你带到网站B,那么网站B将获得引荐来源网址.例如,如果您访问http://siteA.com?u=username&pw=123123,则siteB.com(链接到siteA.com页面)将收到"http://siteA.com?u" = username&pw = 123123"作为引用URL,由浏览器发送到HTTPS内的siteB.com.如果这是真的,那就非常糟糕.这是真正的托比亚斯吗？
6> 小智..：
来自Marc Novakowski的有用答案的补充 - URL存储在服务器上的日志中(例如,在/ etc/httpd/logs/ssl_access_log中),因此如果您不希望服务器在更长时间内维护信息术语,不要把它放在URL中.
7> SoapBox..：
是的,不是.
服务器地址部分未加密,因为它用于设置连接.
这可能会在未来使用加密的SNI和DNS进行更改,但截至2018年,两种技术都不常用.
路径,查询字符串等是加密的.
请注意,对于GET请求,用户仍然可以将URL剪切并粘贴到位置栏之外,您可能不希望将机密信息放在那里,任何看到屏幕的人都可以看到.
想要+1这个,但我发现"是和否"误导 - 你应该改变它只是指出服务器名称将使用DNS解决而不加密.
根据我的理解,OP在正确的意义上使用URL这个词.我认为这个答案更具误导性,因为它没有明确区分URL中的主机名和DNS解析中的主机名.
@EJP,@ trusktr,@ Lawrence,@ Guillaume.你们所有人都错了.**这与DNS无关.**SNI"[发送虚拟域名作为TLS协商的一部分](https://en.wikipedia.org/wiki/Server_Name_Indication#How_SNI_fixes_the_problem)",所以甚至如果您不使用DNS或DNS已加密,则嗅探器仍然可以看到您的请求的主机名**.
URL已加密.HTTP事务的每个方面都是加密的.不仅仅是"其他一切".期.-1.
@EJP但DNS查找**确实**使用URL的一个部分,因此对于非技术人员,整个URL不加密.仅仅使用Google.com查找非技术性内容的非技术人员不知道数据最终位于何处或如何处理.该域是用户访问的URL的一部分,并非100%加密,因为我作为攻击者可以嗅探他正在访问的站点.只有URL的/ path固有地加密给外行(这无关紧要).
差异是......？
这不是HTTPS交易的一部分,与您在此处继续给出的误导性印象相反.
8> pbhj..：
监控流量的第三方也可以通过检查您的流量来确定所访问的页面,并将其与访问该站点时其他用户拥有的流量进行比较.例如,如果一个站点上只有2个页面,一个比另一个大得多,那么比较数据传输的大小就会告诉你访问了哪个页面.有些方法可以从第三方隐藏,但它们不是正常的服务器或浏览器行为.例如,参见SciRate的这篇论文,https: //scirate.com/arxiv/1403.0297 .
一般来说,其他答案是正确的,但实际上这篇论文表明访问的页面(即URL)可以非常有效地确定.
根据我的引用:"我们针对超过6000个网页提供流量分析攻击,这些网页涵盖了医疗保健,金融,法律服务和流媒体视频等10个广泛使用的行业领先网站的HTTPS部署.我们的攻击识别了同一个网站,准确度为89%[...].看来你的可行性结论是错误的.
对于有兴趣阅读更多关于此类漏洞的人来说,这些类型的攻击通常被称为[旁道攻击](https://en.wikipedia.org/wiki/Side-channel_attack).
9> 小智..：
您也不能总是依靠完整URL的私密性。例如，有时在企业网络中，像公司PC这样的提供的设备都配置了额外的“受信任”根证书，以便您的浏览器可以安静地信任对HTTPS流量的代理（中间人）检查。这意味着公开了完整的URL供检查。通常将其保存到日志中。
此外，您的密码也会被公开并可能被记录下来，这是使用一次性密码或经常更改密码的另一个原因。
最后，如果未进行其他加密，则请求和响应内容也将公开。
Checkpoint此处介绍了一种检查设置的示例。也可以通过这种方式设置使用提供的PC的老式“网吧”。
京公网安备 11010802040832号 | 京ICP备19059560号-6 