Squid, HTTPS pages intermitant and Windows 8 / IE11

Question

I have an odd issue, and have managed to replicate this problem at different locations with different installs of Squid.

I will base my "problem" with my squid server at home.

Running Fedora 20 (32bit), with Squid 3.3.11, firewall and iptables uninstalled/disabled. The network is IPv4. I have a couple of Windows 7 machines with IE11, and 1x Windows 8.1 machine with IE11.

My problem is, on my Windows 8.1 machine with IPv6 protocols turned off, trying to load SSL based web pages (such as https://www.google.co.uk or https://www.facebook.com), the initial page load results in an error. Subsiquent loads either fail, part fail (IE main body of the site loads, but further SSL connections fail, such as image loads) or allow the page to load.). Oddly enough though, I do not re-call having a problem with my banks website! I would suggest that some websites seem to struggle more than others.

A friend of mine also managed to replicate the fault on a squid server he setup with Windows 8.1. He commented that using another browser such as Firefox, the problem is resolved so it seems limited to Windows 8.1, and IE11

Using Wireshark, during the failed attempts, towards the end my machine sends back a load of TCP RST commands.

However loading the same websites on my Windows 7 using IE11, or Windows XP with IE8, the problem does not appear, and until I moved to Windows 8.1, I had 0 problems with my Squid server.

My Squid Config is fairly basic as I just use it for filtering adverts using a block list using SquidGuard, although an experiment ruled out SquidGuard as being the problem when I removed the relevant line from squid.conf.

Thanks for reading and hope we can get to the bottom of this!

Copy of my squid config.

#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

I found it: Disable SPDY/3 Protokol in IE11 (Extras....)

Answer 2

It might be related to IE11 disabling RC4 and using TLS1.2 in the initial handshake, see 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. Unfortunatly lots of hosts still require RC4 and might fail if the client does not offer this cipher. Other hosts will also croak when using TLS1.2, e.g they just close the connection (like currently bmwi.de) or just drop the request (usually an older F5 BIG-IP load balancer in front).

I know from Chrome that it just retries a failed TLS 1.2 request immediately with TLS 1.1. Maybe IE11 does this different, e.g. does not retry immediately but only remembers the failure and work around it if the user retries. Or it behaves this way only when used with a proxy.

That you sometimes get the full page and sometimes only the html on the second request might be the case if the images are loaded from a different host name, e.g. images.whatever instead of www.whatever. In this case it gets at first a failed handshake with www.whatever and after a successful retry it with downgraded SSL it receives the HTML with the includes from images.whatever. It then will access images.whatever and will run in the same problems with SSL, so that the page stays w/o images until another retry.

If my theory is correct, you should see in wireshark in the initial failed connect an SSL Client Hello message with version TLS 1.2 and it should not have RC4 in the list of offered ciphers. On the second (successful) connect you should see RC4 in the cipher list of the Client Hello and maybe it will also use TLS 1.1 or oven TLS 1.0 instead of TLS 1.2.