System.Security.Authentication.AuthenticationException

[Ganesh]

Hi Eric,

I have a Web Application and added the proper host to the Filters tab. When I launch the Web Application nothing gets recorded in Fiddler. I tried with other Web Applications and they get recorded without any issue. I have checked the following

1. Capture Traffic Enabled.

2. Decrypt HTTPS traffic Enabled.

3. Searched the forum and enabled the "Troubleshoot" option in Fiddler and captured the error message from the Fiddler logs.

12:42:51:3835 fiddler.network.https> HTTPS handshake to xxx-xxx.xxx.com (for #348) 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

4. Checked the forum with this error message and I haven't found the exact one, but similar one to this has the troubleshooting steps to add CONFIG.oAcceptedServerHTTPSProtocols = System.Security.Authentication.SslProtocols.Ssl3; under Main() in the FiddlerScript but had no luck.

5. I had Wireshark up and running and noticed that the "Protocol" is "TCP" when I launched my application. Is this the issue?

Can you please let me know if I can capture the traffic from my site using Fiddler?

Application launches fine without Fiddler.

Fiddler Version: 

Fiddler Web Debugger (v4.6.0.2)

Built: Monday, August 17, 2015

Thanks,

Ganesh

[EricLaw]

Without the URL or hostname of your site, we'll just be shooting in the dark.

The most likely explanation is that your site requires TLS/1.1 or TLS/1.2 but you only have TLS/1.0 enabled inside Tools > Fiddler Options > HTTPS.

You can see what TLS versions your site supports by using the "Server Test" link at https://ssllabs.com/

[Ganesh]

I'll check that and will update here.

Thanks,
Ganesh

[Ganesh]

I have updated the "Enabled Protocols" in Fiddler to ssl3;tls1.0;tls1.1;tls1.2 and tried accessing the application but still Fiddler is not capturing any sessions. My application URL is internal and cannot be accessed from outside network and hence didn't do the server test. However, I checked Wireshark and the Protocol shows as TCP. Also, I created a LoadRunner script and I had to add  web_set_sockets_option("SSL_VERSION","TLS"); function for my script to work. 

My application URL has a port number 8443, i.e., https://xxx-xx.xxxx.com:8443/

Please advise.

Thanks,

Ganesh

[Ganesh]

One small correction:

I have updated the "Enabled Protocols" in Fiddler to ssl3;tls1.0;tls1.1;tls1.2 and tried accessing the application but still application doesn't load with Fiddler running in the background.

[EricLaw]

1. What version of Windows are you running?

2. When your application works, capture it with Wireshark, and look at the HTTPS version negotiated in the ServerHello message.

[Ganesh]

1. Windows 7

2. I checked the Wireshark again and I don't see any HTTPS traffic. I see everything recorded as TCP ([SYN], [SYN, ACK]). Is this the issue, as Fiddler captures only HTTP traffic? However, I'm able to record the transactions with VuGen (LoadRunner) using Web(HTTP/HTML) protocol.

[Ganesh]

I took help from my colleague and here is what we did.

We had Fiddler up and running along with Wireshark and captured the trace. Filtered the Wireshark captures by the port number of the application which is 8443. Then selected one packet and decoded the request (Right click -> Decode as" and selected the protocol as "SSL"). The protocol column in the packets now show "TLSV1".After the "Client Hello" packet there is "Fatal, Description: Handshake failure" packet as shown in the attached snapshot. Please advise.

[EricLaw]

We need to see the data that's inside that FATAL Alert packet. 

It would also be very helpful to see the ClientHello and ServerHello from a working handshake (e.g. without Fiddler).

[Ganesh]

I lost access to the application. As soon as the access issue is resolved, I will try to do it. Will keep you posted.

Thanks,

Ganesh

[Ganesh]

I got access back to the application and I captured the packets using Wireshark and attached the snapshot for the same.

Client Sends 26 Cipher Suites in the "Client Hello" packet, Servers Acknowledges it and sends "Server Hello" by picking one Cipher from the list client sent in the success scenario.

Not sure if this helps, otherwise please let me know what exactly you need from me to debug this issue.

Thanks,

Ganesh

[EricLaw]

The PCAP file exported from Wireshark would be useful. Sending screenshots is much less useful.

[Ganesh]

Sorry, I'm not supposed to send that data.

I added the CONFIG.oAcceptedClientHTTPSProtocols = System.Security.Authentication.SslProtocols.Ssl3; in FiddlerScript under Main() and get the below message on accessing the application with Fiddler running.

12:30:35:9960 !SecureClientPipeDirect failed: System.ComponentModel.Win32Exception The client and server cannot communicate, because they do not possess a common algorithm on pipe to (CN=xxx-xxx.xxxx.com, O=DO_NOT_TRUST, OU=Created by http://www.fiddler2.com)

I also performed resetting the certificates by following the step in this post. https://groups.google.com/forum/#!topic/httpfiddler/Jk1RWk4iWqY but no luck.

Thanks,

Ganesh

[EricLaw]

Your issue isn't related to certificates, so resetting certificates won't help.

Changing the protocol to SSL3 is almost certain not to work; support for that protocol is fading fast.

You might try using the Enabled Protocols feature inside Tools > Fiddler Options > HTTPS to set the supported protocol to exactly tls1.0 and see if that makes a difference.

It's impossible to debug from the screenshot as it's missing the TLS Fatal Alert value, as well as any indication as to who sent the alert. (Incidentally, whomever created a policy that says you can run my full-trust software but not share a PCAP privately with me doesn't understand very much about computer security.)

[Ganesh]

Eric, "Enabled Protocols" feature doesn't exactly take TLS/1.0. It says the valid tokens are tls1.0. I have already tried with tls1.0; tls1.1 and other valid tokens that it shows.

I totally understand. I will talk to my Security Team here again and see if I can send it to you. Will keep you posted.

Thanks once again for trying to help me on this issue!

-Ganesh

[term srv]

Click on 'Client Hello' to select it.
Click on 'Secure Sockets Layer' to select it.
Right-click on 'Secure Sockets Layer' and choose expand subtrees.
File > Export Packet Dissections > As Plain Text file:
. Choose option: Selected packet
. Choose option: Packet details > As displayed

Do that again for both the client hello and server hello without Fiddler. Compare the client hellos and see what's different. Also check the IP addresses, maybe one address is good and one isn't. I have a similar problem with eBay at the moment; Fiddler is not at fault though, it is the Windows SSL.

When you do it without Fiddler what are you using, Internet Explorer? If not try IE and see if you have the same problem.

If you are going to post the client/server hellos publicly remove identifying information from the headers, everything above "Secure Sockets Layer", and also possibly the server name extension in the record:
                    Server Name length: 3
                    Server Name: foo

 If there are certificates embedded it's more difficult, so if you have a security team you may want to run that by them.

I've noticed occasionally I will be unable to connect to something in Fiddler but it's not due to Fiddler it's Windows SSL schannel that's the cause. Eric is on the money, you should try just TLS 1.0 and see what happens.

BTW the error in the message you see posted earlier this afternoon like a no-cipher-overlap type message, in other words the client says I have these ciphers and the server doesn't accept any of what the client offers so the connection isn't made. Check the server hello for what cipher it selects. Is the server public? If so post it here and I'll try for you.

[Ganesh]

Thanks for trying to help!

I'm using IE to access the application.

There are the two Cipher Suites that are not present in the "Client Hello" packet when I have Fiddler running but present in the packet without Fiddler.

Cipher Suite: TLS_RSA_WITH_RC4_128_SHA (0x0005)

Cipher Suite: TLS_RSA_WITH_RC4_128_MD5 (0x0004)

"Server Hello" packet uses "TLS_RSA_WITH_RC4_128_SHA (0x0005)" cipher.

-Ganesh

[term srv]

Is RC4 the only cipher that overlaps? RC4 is being phased out. The reason it's not in Fiddler's cipher list may have something to do with Microsoft's disabling of RC4 in some .NET recently:
https://technet.microsoft.com/en-us/library/security/2960358

Check if you have those SchUseStrongCrypto registry keys, maybe you can set them to 0 and that will help. Again, if the server is public let me know and I'll try it tonight to see what works.

[Ganesh]

Thanks again! 

There are two entries of SchUseStrongCrypto registry keys (one for v2.0 and other for v4) and I updated the key value to 0 from 1 for both the keys. I launched Fiddler and then the application in IE browser, but application doesn't launch. This is an internal site and can't be accessed from outside.

-Ganesh

[Ganesh]

RC4 is the only cipher that is seen in the Server Hello packet. Tried couple of times.

[EricLaw]

The server will generally pick the same thing from the client's list given the same list. The way to test this would be to use a different client, e.g. by watching in Wireshark as e.g. Chrome connects to the target.

If the server were public, you could use SSLLabs' server test to hit it and get the full list of supported ciphers.

[term srv]

Sorry perhaps you misunderstood, what I was suggesting is you shut off the strong crypto requirement which means setting those values to 0 not to 1. Also, schannel has separate keys for controlling whether or not RC4 is enabled. For example in the Windows 7 x64 Enterprise computer I'm using right now all RC4 ciphers are disabled:

"HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 128/128"   Enabled = DWORD 0
"HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 40/128"   Enabled = DWORD 0
"HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 56/128"   Enabled = DWORD 0

I don't know if a reboot is required after any of those things but I'd guess so. I recall it's rare a server supports only RC4 though, I saw once on a pie chart it was like a sliver of the internet. Still if you could enable RC4 so Fiddler sends it in the client hello you could find out if that works.

[Ganesh]

Hi, I'm sorry. It was a typo in my previous reply. Actually it was 1 and I changed it to 0. I will do it again and restart the machine to see if it works.

Eric, I'm still waiting on the Security team to give go ahead. Will keep you posted.

[EricLaw]

As far as I know, you can't enable RC4 via the registry key if .NET 4.6 is installed.

If this server is one inside your organization, it'd probably be simplest to just look at its configuration directly.

[Ganesh]

I got pulled into something else today and I will not have time to check what "term srv" has asked me to do. 

I will do that as soon as I get time and I will update here.

Thanks once again for helping me out!

-Ganesh

[Ganesh]

I tried but no luck. Sorry I can't send the Wireshark capture.

[jayashree nagarajachar]

I just had to add tls1.2 in Tools > Fiddler Options > Https . It gave me proper response for my request.

Thanks guys.

[Not My Name]

Thank you very much. Your response was my solution.