Handshake failure after upgrading to fiddler 4.6.0.2

13 posts, 0 answers
  1. Ian
    Ian avatar
    4 posts
    Member since:
    Apr 2015

    Posted 09 Sep 2015 Link to this post

    When attempting to contact the remote server we get error:

    fiddler.network.https> HTTPS handshake to testservices.bacs.co.uk (for #2) failed. System.IO.IOException The handshake failed due to an unexpected packet format.

    The initial contact works:

    A SSLv3-compatible ClientHello handshake was found. Fiddler extracted the parameters below.
    Version: 3.3 (TLS/1.2)
    Random: 55 EF F1 1D BF EC E6 4D C4 4F DB A2 41 4F A5 92 99 ED 52 96 5C CC 17 3F 21 89 56 49 80 C3 E2 5D
    "Time": 02/12/1985 18:05:09
    SessionID: empty
    Extensions:
    server_name xxxxxxxxxxx.co.uk  (changed for security)
    status_request OCSP - Implicit Responder
    elliptic_curves secp256r1 [0x17], secp384r1 [0x18]
    ec_point_formats uncompressed [0x0]
    signature_algs sha512_rsa, sha512_ecdsa, sha256_rsa, sha384_rsa, sha1_rsa, sha256_ecdsa, sha384_ecdsa, sha1_ecdsa, sha1_dsa
    SessionTicket empty

    ..... etc.

  2. Eric Lawrence
    Admin
    Eric Lawrence avatar
    833 posts

    Posted 09 Sep 2015 Link to this post

    Hello, Ian--

    The server in question doesn't appear to respond to HTTPS requests after successfully negotiating a handshake.

    It may be helpful to collect a packet dump with Wireshark or Netmon to understand what the server is sending back instead of a valid handshake response on subsequent connection attempts.

    Regards,
    Eric Lawrence
    Telerik
    Do you want to have your say when we set our development plans? Do you want to know when a feature you care about is added or when a bug fixed? Explore the Telerik Feedback Portal and vote to affect the priority of the items
  3. David
    David avatar
    4 posts
    Member since:
    Oct 2015

    Posted 25 Oct 2015 Link to this post

    I'm seeing the same issue with this website: https://online.peopleschoicecu.com.au/

    Other subdomains are fine, e.g. https://digitalonline.peopleschoicecu.com.au/

    I'm perfectly happy to blame the server, but I'm interested why there wasn't a problem until the latest Fiddler update.

  4. Eric Lawrence
    Admin
    Eric Lawrence avatar
    833 posts

    Posted 26 Oct 2015 Link to this post

    Hello, David

    It's quite likely that the Fiddler update has nothing to do with it (since the default HTTPS configuration hasn't changed in more than a year).

    Inside Tools > Fiddler Options > HTTPS, which HTTPS protocols do you have enabled?

    The first site you mention (https://www.ssllabs.com/ssltest/analyze.html?d=online.peopleschoicecu.com.au) gets an "F" from SSLLabs as it supports *only* TLS v1.0 with three ciphers. 

    The second site you mention (https://www.ssllabs.com/ssltest/analyze.html?d=digitalonline.peopleschoicecu.com.au) gets an "A-" from SSLLabs as it supports TLS1.0 to TLS1.2 with a total of five ciphers.

    The first site's HTTPS configuration appears to be so bad that if you even *offer* TLS/1.1 or TLS/1.2, it fails the connection without simply using TLS/1.0 as it's supposed to.


    To work with this site, you'd need to disable TLS/1.1 and later in your Fiddler configuration or (more secure) configure this particular site to use a weak configuration. Click Rules > Customize Rules. Scroll to OnBeforeRequest and inside it add:

      // Hack to workaround buggy bank site
      if (oSession.HTTPMethodIs("CONNECT") && oSession.HostnameIs("online.peopleschoicecu.com.au"))
      { 
    oSession["x-OverrideSslProtocols"] = "tls1.0";
      }


    Regards,
    Eric Lawrence
    Telerik
    Do you want to have your say when we set our development plans? Do you want to know when a feature you care about is added or when a bug fixed? Explore the Telerik Feedback Portal and vote to affect the priority of the items
  5. David
    David avatar
    4 posts
    Member since:
    Oct 2015

    Posted 26 Oct 2015 in reply to Eric Lawrence Link to this post

    Hi Eric,

    Thanks for the quick reply.

    My HTTPS Protocols are set to '<client>;ssl3;tls1.0'.

    The workaround you suggest is effective - thanks.​

    I've verified on three separate machines that the upgrade from 4.6.0.2 to 4.6.1.0 results in a System.Security.Authentication.AuthenticationException being raised for the CONNECT request.

    Here's a comparison of the request and result from 4.6.0.2 and 4.6.1.0:

    4.6.0.2:

    CONNECT online.peopleschoicecu.com.au:443 HTTP/1.1
    Host: online.peopleschoicecu.com.au
    Connection: keep-alive
    User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2490.80 Safari/537.36
      
    A SSLv3-compatible ClientHello handshake was found. Fiddler extracted the parameters below.
      
    Version: 3.3 (TLS/1.2)
    Random: D4 31 B7 07 02 A7 E7 0E C6 38 59 BB 11 AE A5 FB 22 B1 05 01 3D 6D CB 4C F9 51 38 6A 80 9E BB 71
    "Time": 7/02/1974 4:19:16 PM
    SessionID: empty
    Extensions:
        renegotiation_info  00
        server_name online.peopleschoicecu.com.au
        extended_master_secret  empty
        SessionTicket   empty
        signature_algs  sha512_rsa, sha512_ecdsa, sha384_rsa, sha384_ecdsa, sha256_rsa, sha256_ecdsa, sha224_rsa, sha224_ecdsa, sha1_rsa, sha1_ecdsa
        status_request  OCSP - Implicit Responder
        NextProtocolNego    empty
        SignedCertTimestamp (RFC6962)   empty
        ALPN        http/1.1, spdy/3.1, h2-14, h2
        channel_id(GoogleDraft) empty
        ec_point_formats    uncompressed [0x0]
        elliptic_curves secp256r1 [0x17], secp384r1 [0x18]
    Ciphers:
        [C02B]  TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
        [C02F]  TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
        [009E]  TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
        [CC14]  TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
        [CC13]  TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
        [CC15]  TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256
        [C00A]  TLS1_CK_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
        [C014]  TLS1_CK_ECDHE_RSA_WITH_AES_256_CBC_SHA
        [0039]  TLS_DHE_RSA_WITH_AES_256_SHA
        [C009]  TLS1_CK_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
        [C013]  TLS1_CK_ECDHE_RSA_WITH_AES_128_CBC_SHA
        [0033]  TLS_DHE_RSA_WITH_AES_128_SHA
        [009C]  TLS_RSA_WITH_AES_128_GCM_SHA256
        [0035]  TLS_RSA_AES_256_SHA
        [002F]  TLS_RSA_AES_128_SHA
        [000A]  SSL_RSA_WITH_3DES_EDE_SHA
      
    Compression:
        [00]    NO_COMPRESSION
      
    -----
      
    HTTP/1.1 200 Connection Established
    FiddlerGateway: Direct
    StartTime: 08:45:24.451
    Connection: close
      
    Encrypted HTTPS traffic flows through this CONNECT tunnel. HTTPS Decryption is enabled in Fiddler, so decrypted sessions running in this tunnel will be shown in the Web Sessions list.
      
    Secure Protocol: Tls
    Cipher: TripleDes 168bits
    Hash Algorithm: Sha1 160bits
    Key Exchange: RsaKeyX 2048bits
      
    == Server Certificate ==========
    [Subject]
      CN=online.peopleschoicecu.com.au, OU=Digital, O=People's Choice Credit Union (Australian Central Credit Union Ltd), L=Adelaide, S=South Australia, C=AU, PostalCode=5000, STREET=60 Light Square, SERIALNUMBER=087 651 125, OID.1.3.6.1.4.1.311.60.2.1.3=AU, OID.2.5.4.15=Private Organization
      
    [Issuer]
      CN=DigiCert SHA2 Extended Validation Server CA, OU=www.digicert.com, O=DigiCert Inc, C=US
      
    [Serial Number]
      075E916FB874EFDC28EFEBE57D4E941C
      
    [Not Before]
      5/05/2015 10:00:00 AM
      
    [Not After]
      28/07/2017 10:00:00 PM
      
    [Thumbprint]
      25B606FC2E967B9CDB81229B03E92AE88F749DC9

    4.6.1.0:

    CONNECT online.peopleschoicecu.com.au:443 HTTP/1.1
    Host: online.peopleschoicecu.com.au
    Connection: keep-alive
    User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2490.80 Safari/537.36
     
    A SSLv3-compatible ClientHello handshake was found. Fiddler extracted the parameters below.
     
    Version: 3.3 (TLS/1.2)
    Random: FC 39 DE 18 7F F9 D9 DF 1A AC 9F 81 B5 61 B2 45 5B 2F 30 24 E9 C7 AC F9 B5 44 E4 BD BF 26 6A 8C
    "Time": 23/03/1983 8:37:00 AM
    SessionID: D9 06 00 00 42 9C A6 C9 6D 4B 2D 7F EB 12 9E 6B 0E 8D 0C 16 96 F6 A2 F5 43 ED CB 51 48 F9 26 A5
    Extensions:
        renegotiation_info  00
        server_name online.peopleschoicecu.com.au
        extended_master_secret  empty
        SessionTicket   empty
        signature_algs  sha512_rsa, sha512_ecdsa, sha384_rsa, sha384_ecdsa, sha256_rsa, sha256_ecdsa, sha224_rsa, sha224_ecdsa, sha1_rsa, sha1_ecdsa
        status_request  OCSP - Implicit Responder
        NextProtocolNego    empty
        SignedCertTimestamp (RFC6962)   empty
        ALPN        http/1.1, spdy/3.1, h2-14, h2
        channel_id(GoogleDraft) empty
        ec_point_formats    uncompressed [0x0]
        elliptic_curves secp256r1 [0x17], secp384r1 [0x18]
        padding 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    Ciphers:
        [C02B]  TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
        [C02F]  TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
        [009E]  TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
        [CC14]  TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
        [CC13]  TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
        [CC15]  TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256
        [C00A]  TLS1_CK_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
        [C014]  TLS1_CK_ECDHE_RSA_WITH_AES_256_CBC_SHA
        [0039]  TLS_DHE_RSA_WITH_AES_256_SHA
        [C009]  TLS1_CK_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
        [C013]  TLS1_CK_ECDHE_RSA_WITH_AES_128_CBC_SHA
        [0033]  TLS_DHE_RSA_WITH_AES_128_SHA
        [009C]  TLS_RSA_WITH_AES_128_GCM_SHA256
        [0035]  TLS_RSA_AES_256_SHA
        [002F]  TLS_RSA_AES_128_SHA
        [000A]  SSL_RSA_WITH_3DES_EDE_SHA
     
    Compression:
        [00]    NO_COMPRESSION
     
    -----
     
    HTTP/1.1 200 Connection Established
    FiddlerGateway: Direct
    StartTime: 08:50:14.139
    Connection: close
     
    fiddler.network.https> HTTPS handshake to online.peopleschoicecu.com.au (for #107) failed. System.Security.Authentication.AuthenticationException A call to SSPI failed, see inner exception. < The message received was unexpected or badly formatted
     
    Win32 (SChannel) Native Error Code: 0x80090326

  6. Romasato
    Romasato avatar
    2 posts
    Member since:
    Oct 2015

    Posted 27 Oct 2015 in reply to David Link to this post

    Hi guys,

     This is the same issue I started having after upgrading to the latest Fiddler version (4.6.1.0) - can't use Fiddler on Firefox to load HTTPS sites where I could just fine with previous Fiddler versions. Something has definitely changed. I've tried re-importing Fiddler certificate with no positive effect.

     The suggested workaround oSession["x-OverrideSslProtocols"] = "tls1.0"; more or less works, but not for every request - some of CONNECT requests are still failing with the message "System.ComponentModel.Win32Exception The client and server cannot communicate, because they do not possess a common algorithm".

     Any further ideas?

    Is there a way to downgrading to specific Fiddler version? Where could I find older ones? 

    Thanks

  7. Romasato
    Romasato avatar
    2 posts
    Member since:
    Oct 2015

    Posted 27 Oct 2015 in reply to Romasato Link to this post

    Btw, when a page does not load on initial try in Firefox because of HTTPS issues, I just hold CTRL+R and somehow it is forced to load and starts loading fine afterwards. Very strange. Not sure why the intermittent issue loading even the same page - should it not consistently either fail or not ?
  8. Eric Lawrence
    Admin
    Eric Lawrence avatar
    833 posts

    Posted 27 Oct 2015 Link to this post

    This thread has been made enough of a mess that it's not really going to be possible to sort through it in a non-confusing way.

    For anyone with a problem using HTTPS decryption in Fiddler, the following questions must be answered for me to have any chance of helping you.

      Q1> What version of Fiddler and Windows are you using?

      Q2> Which HTTPS protocols are enabled (Tools > Fiddler Options > HTTPS > "Protocols" link at the right.

      Q3> Which certificate maker are you using? (Tools > Fiddler Options > HTTPS > click "Certificates Generated By")

      Q4> What app(s) traffic are you trying to capture? What version? Have you tried a different browser or client? What HTTPS servers are you trying to reach?

      Q5> What text appears on Fiddler's Log tab at the point of failure? What, if anything, appears in the client?


    To some of the implied questions below:

    1. I have no problem capturing traffic from Firefox 44 to any HTTPS site I've tried. If you continue to have problems, please start a new thread with answers to the questions above.
    2. "The client and server cannot communicate" will be shown if, for instance, you enable only TLS/1.0 and the server demands TLS/1.2 with a cipher not available in TLS/1.0. 
    3. "The suggested workaround" applies for a specific site which is known to be TLS Version Intolerant. 
    4. Support for the <client> token was introduced in Fiddler 4.6.0.3 and would be ignored by 4.6.0.2 and earlier. As a consequence, in the scenario described, Fiddler 4.6.0.2 offers [SSL3;TLS1] to the server and the handshake succeeds; Fiddler 4.6.1.0 offers [SSL3;TLS1;TLS1.2] to the server and because the server is buggy, the handshake fails.

    Regards,
    Eric Lawrence
    Telerik
    Do you want to have your say when we set our development plans? Do you want to know when a feature you care about is added or when a bug fixed? Explore the Telerik Feedback Portal and vote to affect the priority of the items
  9. David
    David avatar
    4 posts
    Member since:
    Oct 2015

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

    Thank you, Eric - that answers my question exactly. Hopefully the website owner will fix their buggy configuration at some point!

  10. Eric Lawrence
    Admin
    Eric Lawrence avatar
    833 posts

    Posted 28 Oct 2015 Link to this post

    A bit of further information has come to light for those interested in these topics.

    1> Romas: Another user posted a better description of a problem with Firefox 36+ and the latest Fiddler. The problem is that Firefox does not accept wildcard certicates generated by makecert. See the link above for the fix/workaround.

    2> David: Many browsers will fall back to earlier TLS versions if offering later versions causes a connection failure; your post inspired me to look into why that wasn't happening when Fiddler was running.

    The culprit was found and corrected in Fiddler 4.6.1.2 (available from getfiddler.com); clients that perform fallbacks (like IE) should now do so correctly when Fiddler is running.

    Unfortunately, this won't help online.peopleschoicecu.com.au in the latest build of Chrome because Chrome refuses to fallback to TLS1.0 by default (use --ssl-version-fallback-min=tls1 in the command line to change that).

    Interestingly, Chrome works by default without fallback when Fiddler isn't running, and I found out that relates to a trick Chrome uses. In HTTPS, the handshake has version numbers in two places, the RecordLayer and the ClientHello. Chrome sends a TLS1.0 [03 01] version as the RecordLayer version and TLS1.2 [03 03] as the ClientHello version. The site in question only fails if the RecordLayer version is above TLS1.0 (e.g. [03 02] or [03 03]). So Chrome succeeds by default. In contrast, SChannel (the crypto stack used by most Windows programs including IE and Fiddler) always matches the RecordLayer version and the ClientHello version, and thus it sends [03 03] and [03 03], which exposes the site's bug. I contacted the site owners and they claim they have a plan to "mitigate" their outdated server, although it's not entirely clear to me what plan that is.

    Regards,
    Eric Lawrence
    Telerik
    Do you want to have your say when we set our development plans? Do you want to know when a feature you care about is added or when a bug fixed? Explore the Telerik Feedback Portal and vote to affect the priority of the items
  11. David
    David avatar
    4 posts
    Member since:
    Oct 2015

    Posted 28 Oct 2015 in reply to Eric Lawrence Link to this post

    Great, I can open the website in Edge and IE when Fiddler 4.6.1.2 is running. Chrome gives me a relevant 'ERR_SSL_FALLBACK_BEYOND_MINIMUM_VERSION' error if I don't forcibly change the minimum version fallback setting.

    The website in question is the bank's old online banking system, so it wouldn't surprise me if they simply turn it off in the near future - the new system has been up and running for months.

  12. Sam
    Sam avatar
    1 posts
    Member since:
    Sep 2016

    Posted 23 Sep Link to this post

    Hello, I've been reading through the documentation and various forum posts related to this issue. This thread seems to be the most relevant to my situation. Here's some of the specifics of my setup:

    1.) Windows 8.1 (VM) & Fiddler 4.6.2.32002

    2.) I've tried just about every permutation, but the version that allows me to see specific error message in the LOG is HTTPS protocols of "<client>;ssl2;ssl3;tls1.0;tls1.1;tls1.2"

    3.) Certificate Maker: CertEnroll engine

    4.) Trying to reach:

    a.) https://sslanalyzer.comodoca.com/?url=https%3A%2F%2Frecon-rest.net.wwe.com

    b.) https://sslanalyzer.comodoca.com/?url=https%3A%2F%2Fs3.amazonaws.com

    c.) https://sslanalyzer.comodoca.com/?url=https%3A%2F%2Fsecure.net.wwe.com%2F

    5.) LOG statements:

    a.) 11:50:32:0159 fiddler.network.https> HTTPS handshake to recon-rest.net.wwe.com (for #15) failed. System.ComponentModel.Win32Exception The client and server cannot communicate, because they do not possess a common algorithm

    b.) 12:08:23:0180 fiddler.network.https> HTTPS handshake to s3.amazonaws.com (for #745) failed. System.ComponentModel.Win32Exception The client and server cannot communicate, because they do not possess a common algorithm

    c.) 11:55:03:2740 fiddler.network.https> HTTPS handshake to secure.net.wwe.com (for #203) failed. System.ComponentModel.Win32Exception The client and server cannot communicate, because they do not possess a common algorithm

     

    I think C (secure.net.wwe.com) may be a lost cause until they update the cert on on the server (as I see there is no matching algorithm), but A and B seem like there is actually a matching algorithm (0xA), and that algorithm seems to be supported in Windows 8.1: https://msdn.microsoft.com/en-us/library/windows/desktop/mt767781(v=vs.85).aspx.

    Please let me know if there is anything I'm missing in setting up Fiddler to be able to successfully decrypt this traffic.

    Thanks,

    -Sam

     

  13. sunil
    sunil avatar
    3 posts
    Member since:
    Sep 2014

    Posted 18 Oct in reply to Sam Link to this post

    Hi,

    I am getting below error when i am connecting fiddler with iPad and seeing hyatt app traffice on remote server.

    CONNECT gss.hyatt.com:443 HTTP/1.1
    Host: gss.hyatt.com
    User-Agent: HyattAppProdAppStore/3.2 (iPad; iOS 10.0.2; Scale/2.00)
    Connection: keep-alive
    Connection: keep-alive

    A SSLv3-compatible ClientHello handshake was found. Fiddler extracted the parameters below.

    Version: 3.3 (TLS/1.2)
    Random: 58 06 0C 06 14 1B 3E F0 AD 2C D3 D1 EA 9C 74 D1 36 13 77 1B 46 84 0F 20 DC AB A3 1B 92 5C DB F0
    "Time": 3/19/1973 10:55:52 PM
    SessionID: empty
    Extensions: 
    server_name gss.hyatt.com
    elliptic_curves secp256r1 [0x17], secp384r1 [0x18], secp521r1 [0x19]
    ec_point_formats uncompressed [0x0]
    signature_algs sha256_rsa, sha1_rsa, sha384_rsa, sha512_rsa, sha256_ecdsa, sha1_ecdsa, sha384_ecdsa, sha512_ecdsa
    NextProtocolNego empty
    ALPN http/1.1, http/1.0
    status_request OCSP - Implicit Responder
    SignedCertTimestamp (RFC6962) empty
    extended_master_secret empty
    Ciphers: 
    [00FF] TLS_EMPTY_RENEGOTIATION_INFO_SCSV
    [C02C] TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
    [C02B] TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
    [C024] TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
    [C023] TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
    [C00A] TLS1_CK_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
    [C009] TLS1_CK_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
    [C030] TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
    [C02F] TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
    [C028] TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
    [C027] TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
    [C014] TLS1_CK_ECDHE_RSA_WITH_AES_256_CBC_SHA
    [C013] TLS1_CK_ECDHE_RSA_WITH_AES_128_CBC_SHA

    Compression: 
    [00] NO_COMPRESSION

    Thanks,

    Sunil

Back to Top