HTTPS handshake failed

[Kevin]

When I attempt to browse to one of my company's websites with Fiddler running, I get the following error on the CONNECT:

fiddler.network.https> HTTPS handshake to site.mycompany.com failed. System.IO.IOException Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host. < An existing connection was forcibly closed by the remote host

Fiddler is running under the administrator account and can access most other HTTPS sites (ie, Outlook, Facebook, other company sites).  Things I've tried:

• Installing the Fiddler certificate under Local Machine (that compounded the problem, couldn't access the Telerik site then)
• Tried running IE as administrator
• Added CONFIG.oAcceptedServerHTTPSProtocols = System.Security.Authentication.SslProtocols.Ssl3; in the Main function in Fiddler script.

Any ideas?

[Eric Lawrence]

Hi, Kevin--

The message here indicates that the server closed the connection when a handshake was attempted. This typically happens only when the server is buggy in some way. Unfortunately, to debug this, you'd need to use a tool like NetMon or Wireshark to capture the low-level connection Packet Capture to see what went wrong in the handshake. Most known problems are fixed by setting the protocol to SSL3, but it sounds like this didn't work for you.

Adding Fiddler's certificate to the Local Machine's Trusted Root Certification authorities should make no difference whatsoever here (better or worse). The fact that this appears to have changed something is interesting; you might try removing ALL Fiddler-related certificates and see whether anything changes.

Regards,
Eric Lawrence
Telerik

 

 

[Kevin]

I would normally agree, except that if I turn Fiddler off, the connection is made.  The page fails to load only when Fiddler is turned on as the proxy.  I'll try WireShark and see if I can deduce anything else.

[Kevin]

It looks like when Fiddler passes the request through, the protocol is SSL and the server responds with TCP flags of RST, ACK.  When Fiddler is not capturing traffic, the request goes through as TLSv1.2 and the server responds with PSH, ACK.  This particular server doesn't appear to like SSL.

[Eric Lawrence]

Hello, Kevin--

One important point is that web browsers have "fall backs" whereby they will fall back to use earlier protocol versions if higher-version handshakes fail.

Now, in your case, the fact that the server accepts 1.2 and not Fiddler's handshake suggests that the server actually requires TLS1.1 or TLS1.2. That's rare, but getting more common.

By default, Fiddler doesn't enable these protocols (http://blogs.msdn.com/b/ieinternals/archive/2011/03/25/misbehaving-https-servers-impair-tls-1.1-and-tls-1.2.aspx) but if you're using Fiddler 4 on Windows 7 or later, you can enable them.

In the next build of Fiddler (v4.5.0.0), there's UI for this inside Tools > Fiddler Options > HTTPS. For now, you can enable 1.1 and 1.2 by following these instructions: http://blogs.telerik.com/fiddler/posts/13-02-11/fiddler-and-modern-tls-versions

Regards,
Eric Lawrence
Telerik

 

 

[Kevin]

Unfortunately, that didn't fix it.  After setting prefs as mentioned in your TLS blog post, the beginning of the tunnel request looked like this:
A SSLv3-compatible ClientHello handshake was found. Fiddler extracted the parameters below.

Version: 3.3 (TLS/1.2)

But the server killed the response:
HTTP/1.0 200 Connection Established
FiddlerGateway: Direct
StartTime: 11:58:06.106
Connection: close

fiddler.network.https> HTTPS handshake to engage.vertafore.com failed. System.IO.IOException Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host. < An existing connection was forcibly closed by the remote host

Am I out of luck?

[Eric Lawrence]

Hi, Kevin--

FWIW, I don't have any problems using Fiddler to capture HTTPS to engage.vertafore.com, although the root of that site redirects elsewhere immediately.

Are you sure that the site in question doesn't attempt to use HTTPS Client Authentication when accessed on your network?

If you send me a PCAP file, I'm happy to have a look.

Regards,
Eric Lawrence
Telerik

 

 

[Kevin]

Add this to the mix.  It only fails through Fiddler when the request is made from IE.  When using Chrome, it works fine.  I thought Chrome picked up the same internet settings as IE.

[Eric Lawrence]

I'm not sure what "picked up the same internet settings as IE" means.

By default, Chrome respects IE's proxy settings.
Chrome uses different settings for HTTPS ciphers and whatnot.

However, this shouldn't be relevant at all, insofar as Fiddler would hide the difference between Chrome and IE here because it's intercepting the secure traffic and regenerating the traffic itself; nothing should be different in terms of the HTTPS handshake coming out of Fiddler.

A PCAP is probably the way to go.

Regards,
Eric Lawrence
Telerik

 

 

[Elly]

This error usually means the server is blocking the SSL handshake, often due to outdated TLS versions or deep packet inspection. Make sure Fiddler is set to use modern protocols like TLS 1.2 or 1.3, as some servers reject older ones like SSL 3.0. You can set this in FiddlerScript using CONFIG.oAcceptedServerHTTPSProtocols.  Also, ensure the server isn’t using HSTS or blocking man-in-the-middle tools like Fiddler. Installing the Fiddler cert correctly and restarting the browser can help fix SSL handshake issues, too. The initial stage in the SSL/TLS connection process enables two parties to communicate securely over the Internet. There are many reasons for the error  to be occured which are as follows:-

1) Incorrecr date/Time setting

2) Invalid SSL/TLS certificate

3) Incorrect cipher suir selection

4) Server configuration issues

5) Network connectivity

I found the relevant resource for the error solution at Certera.com. I hope it helps!