HTTPS handshake failed

9 posts, 0 answers
  1. Kevin
    Kevin avatar
    5 posts
    Member since:
    Feb 2015

    Posted 25 Feb 2015 Link to this post

    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?

  2. Eric Lawrence
    Admin
    Eric Lawrence avatar
    833 posts

    Posted 26 Feb 2015 Link to this post

    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
     

    Check out the Telerik Platform - the only platform that combines a rich set of UI tools with powerful cloud services to develop web, hybrid and native mobile apps.

     
  3. Kevin
    Kevin avatar
    5 posts
    Member since:
    Feb 2015

    Posted 27 Feb 2015 in reply to Eric Lawrence Link to this post

    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.
  4. Kevin
    Kevin avatar
    5 posts
    Member since:
    Feb 2015

    Posted 27 Feb 2015 in reply to Kevin Link to this post

    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.
  5. Eric Lawrence
    Admin
    Eric Lawrence avatar
    833 posts

    Posted 27 Feb 2015 Link to this post

    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
     

    Check out the Telerik Platform - the only platform that combines a rich set of UI tools with powerful cloud services to develop web, hybrid and native mobile apps.

     
  6. Kevin
    Kevin avatar
    5 posts
    Member since:
    Feb 2015

    Posted 04 Mar 2015 in reply to Eric Lawrence Link to this post

    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?
  7. Eric Lawrence
    Admin
    Eric Lawrence avatar
    833 posts

    Posted 05 Mar 2015 Link to this post

    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
     

    Check out the Telerik Platform - the only platform that combines a rich set of UI tools with powerful cloud services to develop web, hybrid and native mobile apps.

     
  8. Kevin
    Kevin avatar
    5 posts
    Member since:
    Feb 2015

    Posted 06 Mar 2015 in reply to Eric Lawrence Link to this post

    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.
  9. Eric Lawrence
    Admin
    Eric Lawrence avatar
    833 posts

    Posted 10 Mar 2015 Link to this post

    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
     

    Check out the Telerik Platform - the only platform that combines a rich set of UI tools with powerful cloud services to develop web, hybrid and native mobile apps.

     
Back to Top