HTTPS协议等效于通过SSL或 TLS连接（通过 TCP）使用 HTTP。

因此，首先向服务器打开一个TCP 连接（在端口 443 上）。这通常足以向www.mysite.com攻击者透露服务器的主机名（即在您的情况下）。直接观察IP地址，并且：

1. 您之前通常会进行未加密的 DNS 查询，
2. 许多 HTTPS 服务器每个 IP 地址只为一个域提供服务，
3. 服务器的证书以明文形式发送，并包含服务器名称（可能在多个之间），
4. 在较新的 TLS 版本中，有服务器名称指示，客户端通过它向服务器指示希望使用哪个主机名，因此服务器可以提供正确的证书，如果它有多个。（这样做是为了能够远离 2。）

然后发生 TLS 握手。这包括密码套件的协商，然后是密钥交换。假设您的浏览器和服务器中的至少一个没有NONE在接受的套件中包含密码，那么密钥交换之后的所有内容都会被加密。

并且假设没有成功的中间人攻击（即攻击者拦截连接，并提供您的浏览器接受的伪造服务器证书），密钥交换是安全的，没有窃听者可以解密任何内容然后在您和服务器之间发送，并且没有攻击者可以在不被注意到的情况下更改内容的任何部分。这包括 URL 和 HTTP 请求的任何其他部分，以及来自服务器的响应。

当然，正如 DW 所提到的，从加密的数据流中可以看到请求（其中包含的可变数据并不比 URL 多多少，可能是一些 Cookie）和响应的长度。这可能会破坏保密性，特别是在服务器上只有少量不同资源的情况下。还有任何后续资源请求。

不过，您在 URL（或请求的任何其他部分）中的密码应该仍然是安全的 - 最多可以知道其长度。

您应该假设该 URL 不受保护，即被动窃听者可能能够了解您正在访问的 URL。

我意识到这与其他人的说法相矛盾，所以我最好解释一下。

确实，域名发送后的所有内容都是加密的。例如，如果 url 是https://www.example.com/foo/bar.html，则www.example.com攻击者可以看到，而 HTTP 请求 ( GET /foo/bar.html HTTP/1.0) 是加密的。这确实可以防止窃听者直接看到 URL 的路径部分。 但是，窃听者可能会看到 URL 的路径部分的长度。此外，其他信息（例如您访问的页面的长度）也可能对窃听者可见。这对攻击者来说是进退两难的一步。如果攻击者可以窃听您的 https 流量，则已经有一些研究使用此门来了解您正在访问的 URL 。

虽然不能保证这些攻击会成功，但我建议谨慎地假设最坏的情况：假设窃听者可能能够了解您正在访问的 URL。因此，您不应假设SSL/TLS 对窃听者隐藏了您正在访问的页面。

是的，https 确实为您访问的 URL 提供了完整性。

PS 另一个警告：在实践中，如果网站未使用HSTS，则 sslstrip 和其他中间人攻击可能会成功针对许多或大多数用户。这些攻击可能会违反 URL 的机密性和完整性。因此，如果用户通过不安全的网络（例如，开放的 Wifi）访问未使用 HSTS 的网站，您应该警惕攻击者可能能够了解用户正在访问的页面。针对 sslstrip 威胁的一种部分缓解措施是让用户在任何地方使用 HTTPS，让网站采用 HSTS。

正如@Paŭlo Ebermann 和@Jeff Ferland 告诉你的那样，GET 请求在 SSL 下加密，因此是安全的。 但是，不要忘记许多 Web 服务器会记录 GET 请求和参数，并且您通过 GET 发送的任何凭据或其他敏感信息都可能会写入某处的日志中。因此，您应该在提交敏感数据时使用 POST（也将在 SSL 下加密）。

这属于“加密不是解决所有问题的神奇安全”的类别。

在您的会话开始之前，以下内容会泄漏：

• 服务器的 IP 地址
• 服务器证书
  • 这将包括在证书上发布的域名，但这并不能保证它与您使用的域名相匹配。
• 您的 DNS 查询

GET ...在 SSL 会话开始之前，不会向服务器发送与创建 SSL 连接 ( ) 无关的数据或请求。URL 作为页面请求的一部分发送，并与会话中的任何流量一样受到保护。