Squid、HTTPS 页面间歇和 Windows 8 / IE11

Question

我有一个奇怪的问题，并设法在不同的位置用不同的 Squid 安装了这个问题。

我将把我的“问题”放在家里的鱿鱼服务器上。

运行 Fedora 20（32 位），卸载/禁用 Squid 3.3.11，防火墙和 iptables。网络是 IPv4。我有几台装有 IE11 的 Windows 7 机器和 1 台装有 IE11 的 Windows 8.1 机器。

我的问题是，在关闭 IPv6 协议的 Windows 8.1 机器上，尝试加载基于 SSL 的网页（例如 https://www.google.co.uk 或 https://www.facebook.com），初始页面加载会导致错误。后续加载失败、部分失败（站点的 IE 主体加载，但进一步的 SSL 连接失败，例如图像加载）或允许页面加载。）。奇怪的是，我不会再打电话给我的银行网站有问题！我建议有些网站似乎比其他网站更困难。

我的一个朋友也设法在他使用 Windows 8.1 设置的 squid 服务器上复制了故障。他评论说，使用其他浏览器如 Firefox，问题已解决，因此它似乎仅限于 Windows 8.1 和 IE11

使用 Wireshark，在失败的尝试期间，我的机器在接近尾声时会发回大量 TCP RST 命令。

但是，在我的 Windows 7 上使用 IE11 或在 Windows XP 上使用 IE8 加载相同的网站时，问题并未出现，并且在我迁移到 Windows 8.1 之前，我的 Squid 服务器出现了 0 个问题。

我的 Squid Config 相当基本，因为我只是将它用于使用 SquidGuard 的阻止列表过滤广告，尽管当我从 squid.conf 中删除相关行时，一项实验排除了 SquidGuard 的问题。

感谢您的阅读，希望我们能够深入了解这一点！

我的 squid 配置的副本。

#squid normally listens to port 3128
http_port 3128

#Allow local machine
#acl manager proto cache_object
acl localhost src 192.168.20.6

# Only allow cachemgr access from localhost
http_access allow manager localhost
http_access deny manager

http_access allow localhost

# Define Local network
acl localnet src 192.168.20.0/24
http_access allow localnet

#Redirect for SquidGuard
redirect_program /usr/bin/squidGuard -c /etc/squid/squidGuard.conf

# And finally deny all other access to this proxy
http_access deny all

Answer 1

我找到了：Disable SPDY/3 Protokol in IE11 (Extras....)

Answer 2

这可能与 IE11 禁用 RC4 并在初始握手中使用 TLS1.2 有关，请参阅http://blogs.msdn.com/b/ie/archive/2013/11/12/ie11-automatically-makes-over-40-of-the-web-more-secure-while-making-sure-sites-continue-to-work.aspx。不幸的是，许多主机仍然需要 RC4，如果客户端不提供此密码，可能会失败。其他主机在使用 TLS1.2 时也会发出嘶嘶声，例如它们只是关闭连接（如当前的 bmwi.de）或只是丢弃请求（通常是前面的较旧的 F5 BIG-IP 负载均衡器）。

我从 Chrome 知道它只是立即使用 TLS 1.1 重试失败的 TLS 1.2 请求。也许 IE11 会有所不同，例如不会立即重试，而只会在用户重试时记住失败并解决它。或者它仅在与代理一起使用时才会如此。

如果图像是从不同的主机名加载的，例如，您有时会获得完整的页面，有时可能只会获得第二个请求中的 html。 images.whatever 而不是 www.whatever。在这种情况下，它首先与 www.whatever 握手失败，在使用降级 SSL 成功重试后，它会收到包含来自 images.whatever 的 HTML。然后它将访问 images.whatever 并在 SSL 的相同问题中运行，因此页面在再次重试之前保持没有图像。

如果我的理论是正确的，您应该在wireshark 中看到最初失败的连接SSL 客户端Hello 消息，版本为TLS 1.2，并且它不应该在提供的密码列表中包含RC4。在第二次（成功）连接时，您应该会在 Client Hello 的密码列表中看到 RC4，并且它可能还会使用 TLS 1.1 或烤箱 TLS 1.0 而不是 TLS 1.2。