使用 HTTP 还是 HTTPS 由客户端决定。

如果用户直接访问http://example.com，攻击者可以简单地劫持该连接并执行中间人攻击。如果用户直接访问https://example.com，那么攻击者必须以某种方式欺骗 SSL/TLS 连接；在不向用户显示无效证书警告的情况下这样做需要攻击者有权访问证书颁发机构的私钥。这种情况永远不应该发生。没有这个，用户的浏览器将拒绝连接，不允许攻击者重定向。

在谷歌和许多其他网站的情况下，他们设置了 HTTP 严格传输安全 (HSTS) 标头，这会导致用户的浏览器缓存一条规则，即他们永远不应该通过明文 HTTP 访问该网站，即使用户要求它或谷歌本身重定向到一个 HTTP URL。浏览器会自动将 URL 重写为 HTTPS，或者完全阻止请求。这也可以防止用户在大多数浏览器中单击证书警告；该选项根本不存在。

不，DNS 查找不会告诉客户端它应该通过 HTTP 还是 HTTPS 连接。浏览器决定 - 如果您输入一个 HTTP URL，它将在端口 80 上不使用 TLS 进行请求，如果您输入 HTTPS，它将在端口 443 上使用 TLS 进行请求。因此，由客户端而不是服务器决定。

如果服务器通过协议收到请求，它不喜欢它可以通过响应 300 状态代码和位置标头来发出重定向。但是，如果原始请求是通过 HTTPS 进行的，那么中间的人将需要一个有效的证书才能发送该响应。如果他有这个，一开始就不需要重定向到 HTTP。

首先，我认为 OP 错过的最大事情是 SSL/TLS 协商首先发生。只有在协商和验证安全连接之后，才能进行任何 HTTP 通信。HTTPS 是一个很大的误称，它只是您的普通旧 HTTP，仅通过完全独立的 SSL/TLS 发送。

如果真实站点有 SSL/TLS 证书，那会阻止黑客将 google.com 重定向到他们自己的服务器吗？

在任何 HTTP 发生之前检查证书并建立 TLS。使用错误的证书，将永远不会建立连接。没有重定向的空间。

Web 服务器不决定是通过 HTTP 还是 HTTPS 连接？

不，客户有。通过打开套接字并以纯文本形式发送 HTTP 请求，或者通过打开套接字，执行完整的 SSL/TLS 协商，然后发送 HTTP 请求。

并且 DNS 查找是在他们连接到服务器之前完成的。

是的，但客户端会根据 DNS 名称检查证书。所以我可以通过 DNS 欺骗你而不是 Google 来找我，但我仍然需要颁发给我的证书google.com

他们不能只是告诉客户端通过 HTTP 而不是 HTTPS 连接吗？

不，他们永远没有机会这样做。

如果您碰巧有一个可以验证任何域的任何证书的证书颁发机构，那就是您遇到大问题的时候。在浏览器仅对他们感兴趣的域进行证书固定之前，其他所有人都必须依赖 CA 的行为不坏，这就是为什么有一个整理的 SSL 证书存储库，您可以使用它来验证是否它从欺骗改变。或者说应该有。