HTTPS URL是否加密是一个常见的问题。从前面的回答中可以看出，HTTPS URL确实是加密的。然而，当解析域名时，您的DNS请求/响应可能不是加密的，并且当然，如果您使用浏览器，您的URL可能也会被记录下来。

URL记录是重要的，因为存在JavaScript黑客攻击，允许完全无关的网站测试给定URL是否在您的历史记录中。您可以通过在URL中包含一个较长的随机字符串来使URL无法猜测，但如果它是公共URL，那么攻击者可以知道它已经被访问过，如果它有一个短秘密，那么攻击者可以以合理的速度使用暴力破解攻击。

难道没有加密的DNS吗？

请提供一个链接到可以“允许完全无关的网站测试给定URL是否在您的历史记录中”的JavaScript黑客攻击。

回答：黑客攻击当然有时间限制，但我当时所说的是像stackoverflow.com/questions/2394890/…这样的东西。在2010年，这些问题正在被调查和改进，这是一个大问题，但我现在并没有真正关注它。

更多例子：webdevwonders.com/…，webdevwonders.com/…

您可以使用OpenDNS的加密DNS服务。我在我的Mac上使用它，但我发现Windows版本不能正常工作。不过，那是一段时间前的事了，现在可能已经正常工作了。对于Linux系统目前还没有。

HTTPS URL是加密的，但DNS请求/响应可能不是加密的。为了解决这个问题，可以使用加密DNS服务，如OpenDNS。

HTTPS URLs是加密的吗？

HTTPS协议是HTTP协议的安全版本，通过使用SSL或TLS加密协议来保护数据的传输。然而，在TLS握手过程中，URL的某些部分可能会以明文形式传输，而不是加密的。

在TLS握手过程中，客户端会发送一个ClientHello包，其中包含URL的域名部分（也就是Server Name）。这个域名部分可能以明文形式存在于ClientHello包中。

但是，URL的其余部分（包括路径和参数）不会在TLS握手过程中传输。这些信息只有在建立了安全的TLS通道之后，通过HTTP请求（如GET /path/?some=parameters&go=here HTTP/1.1）传输，此时这些信息会被加密。

然而，从2019年开始，有一个RFC提案（https://datatracker.ietf.org/doc/html/draft-ietf-tls-esni-03#section-3.2）可以通过加密SNI扩展来进一步保护域名的隐私。该功能仅在TLS 1.3中存在，并且对TLS 1.2及以下版本没有向后兼容性。

需要注意的是，这个加密SNI扩展更多地解决了隐私方面的问题，因为反向DNS查找可能会泄漏目标主机的信息。

此外，2020年的一个RFC提案（https://datatracker.ietf.org/doc/draft-ietf-tls-esni/?include_text=1）还提到了对整个Client Hello消息进行加密的方法。

HTTPS URLs中的域名部分可能以明文形式传输（如果使用了SNI扩展），但URL的其余部分始终是加密的。对于隐私和安全，有一些提案可以进一步加强加密保护。

HTTPS URL是否加密？

HTTPS URL是否加密是一个常见的问题，出现的原因是因为在TLS协商的第一部分中，URL的域名部分是以明文形式发送的，因此服务器的域名可以被嗅探到。但是除了域名以外的URL的其他部分是加密的。

为了解决这个问题，可以考虑以下几个方法：

1. 使用公钥和私钥对请求进行签名。亚马逊就是这样做的，使用公钥和私钥对JSON请求进行签名，并发送公钥。服务器使用公钥查找对应的私钥，并对JSON进行签名。这种方法可以实现临时请求的安全传输。

2. 注意浏览器的历史记录安全性问题。URL数据会保存在浏览器的历史记录中，可能存在长期的安全隐患。

3. 注意DNS解析的加密性。DNS解析的URL可能是未加密的，因此嗅探者仍然可以看到你要访问的域名。

4. 考虑使用DNS over HTTPS (DoH)来解决SNI破坏URL的SSL加密的问题。但即使使用DoH，仍然可以通过IP域名匹配来找出用户连接的域名。

总之，虽然HTTPS URL是加密的，但URL中的域名部分是以明文形式发送的，其他部分是加密的。在实际应用中，需要注意浏览器历史记录、DNS解析和SNI等问题，以确保HTTPS连接的安全性。