ERR_CONNECTION_CLOSED on some https websites

[Toby200]

Overview:
I'm getting an ERR_CONNNECTION_CLOSED when trying to access specific websites over https. This seems a fairly common issue, but I haven't been able to find anything quite like what's happening to me. I'm using a brand new Dell XPS laptop with Windows 10, build 17134.

 

Here's a quick summary, with more detail below:

• The issue is isolated to the combination of laptop + one wifi network. Other Win 10 PCs on same network work. The laptop on another network works too.
• Only some https websites are impacted, others work fine.
• The issue is not browser specific, and isn't fixed using incognito
• A factory reset has not helped
• Restarting the router has not helped
• If I setup a manual proxy, websites all load fine

Details:
The first sign of problems was that Windows wouldn't activate as it couldn't reach the activation server. I then followed a link to a microsoft help page using Microsoft's Edge browser and got this ERR_CONNNECTION_CLOSED error back. 

I've since tried:

Connecting using a different wifi network. I've tried 4 different wifi networks; they all work fine except my home wifi (TPLink Archer VR2600 on BT Infinity VDSL, both 2.4GHz and 5GHz networks).  I activated windows, ran a full update etc whilst connected to a working network.

Uninstalling McAfee software and disabling windows defender and firewall

Chrome, Chrome in incognito mode, Edge, Firefox and Opera - all browsers display the same behaviour.

Different https sites - some are fine (Various google sites, bbc.co.uk, github, superuser.com and loads more), others are not (netflix.com, microsoft.com, mozilla.org, itv player (website is ok but player is not))

Rebooted the router

Using [mitmproxy](https://mitmproxy.org/) to view the messages. As soon as I put mitmproxy in the middle - everything works fine. I'm sure there's a clue here but I don't know what it means! Other https proxies work too.

I installed git and using git bash ran `curl https://www.mozilla.org/en-GB/`. This worked fine, but the site won't load in a browser

I ran a factory reset - the same issue persists

I've tested with my desktop PC (windows 10, same build 17134) on the same networks and it has no problems at all, nor does a Windows 8 laptop.

I ran a client ssl/tls capabilities check on ssllabs.com and this came back good, though did flag up that TLS 1.0 is enabled along with some weak cipher suites.

I ran malwarebytes anti-malware and it came back clean

I suspect there's some Windows level setting causing this, though I don't understand why it would work on other wifi networks. I'm really at a blank as to where to go next with it, so hope someone can help!
 

[KuJoe]

Can you compare the DNS settings between the laptop and one of the PCs that works fine?

[Toby200]

Hi KuKoe thanks for the prompt response!

 

Both computers are setup to use the DNS from the router. Originally this was pointing to a PiHole server on my local network, but I changed this back to google when I started seeing problems. I have primary set to 8.8.8.8 and secondary to 8.8.4.4. 

 

An nslookup returns the same results on both the desktop and laptop. If I try to connect to mozilla.org by IP (i.e https://63.245.208.195), I get a cert warning as the IP does not match the name - so it's connecting and receiving the certificate ok - but if I then click to proceed, I'm back at the connection closed error.

[homeap5]

Date and time is set correctly on your PC?

[Toby200]

Yes, date and time are set to automatic and are correct. Thank you for the suggestion.

[homeap5]

Change DNS servers both - on computer and router.

[Toby200]

I've done a packet capture in wireshark to see if that sheds any more light on this (raw capture and images from wireshark attached)

 

One thing stands out - the initial "Client Hello" from my laptop to the server is a different length on the working connection than on the bad one. The difference is that the good setup is sending an "Extension: pre_shared_key" of length 235 with a PSK Identity. On the bad setup, there's just "padding" of length 197 that just consists of 0s. 

 

Edit: I tried disabling TLSv1.3 in chrome, so it then used TLSv1.2 which doesn't have the pre-shared key. But it still doesn't work, so it's not that. I've updated with a screengrab of the TLSv1.2 packets too.

 

Also DNS looks fine - can see destinations resolve fine in the packet capture

 

wifi-good-mozilla.pcapng

wifi-mozilla.pcapng

[Roberito]

im having the same problem with no luck resolving i did hear that opening up cmd.exe and typing "ipconfig /flushdns" fixes the problem for some people i tried it and had no luck but its worth a shot for you

[Toby200]

Thanks Roberito - I have tried that but to no avail. Let me know if you find anything that works.

[Roberito]

tried using it this morning and its back to normal idk what happened i hadn't tried anything new

EDIT:

apparently it was only a few sites i had back but now it came back even worse i cant even access google or LTT im having to use the VPN feature on opera to connect to anything

[Toby200]

That seems a bit odd. I'm a little suspicious there's some issue with my router  (possibly a timing thing that only shows up with my laptop), so hoping to test it when I'm next out and there's other wifis to try it on. I also tested with an ethernet cable connection to the same router and that was fine. It's all a bit confusing!

[JaredvVC]

I know that this thread is quite old but someone found the solution?