Jump to content
Welcome to our new Citrix community!

SSL/TLS Handshake deeper dive


Chad Buser
Go to solution Solved by Steven Wright,

Recommended Posts

Hi I'm trying to understand and looking for suggestions on why the Client Key Exchange did not take place in this connection. I have a powershell script (forcing TLS 1.2) where I connect to a set of ADCs to do stuff. Here is the error I get from the script:

System.Net.WebException: The request was aborted: Could not create SSL/TLS secure channel.

I'd like to see something more in Wireshark as to why the Client Key Exchange did not take place if possible. Both ADCs agree on the same Cipher however, the successful ADC 'ns-server-certificate' connects with SHA1 and a 2048 key size whereas the other ADC fails with SHA256 and a 512 key size. I know how we got in this position and how to fix it. However, If I look at the wireshark trace, I see how the successful connection progresses from:

Client Hello

Server Hello

Certificate, Server Hello Done

Client Key Exchange, Change CIpher Spec, Encrypted

Change CIpher Spec, Encrypted Handshake Message

Application Data

vs, the unsuccessful connection:

Client Hello

Server Hello

Certificate, Server Hello Done

However, it seems that Wireshark just reports on the connection with no real errors.

If I run the nstrace with 'capsslkeys ENABLED' will this give me the output I'm looking for or is it unrealistic to assume Wireshark is going to give me any output that matches the script error?

Best

Chad

Link to comment
Share on other sites

  • Solution

Hi Chad,

>If I run the nstrace with 'capsslkeys ENABLED' will this give me the output I'm looking for or is it unrealistic to assume Wireshark is going to give me any output that matches the script error?

I don't believe nstrace set to capture SSL keys will give you the response you're looking for. The option 'capsslkeys ENABLED' will cause nstrace to record the pre-shared master key received during the handshake phase "Client Key Exchange, Change Cipher Spec, Encrypted," but that phase doesn't appear to have been reached yet. Since the client (the PowerShell script) stops immediately after the server exchange, it's likely that it didn't accept the server's response, and therefore, there isn't data on the wire for Wireshark to capture.

As Marcelo commented, one of the most likely reasons that the client stopped was that it didn't accept a 512-bit key. However, in your situation, I would enable System.Net tracing to create a log of the network communication, including the TLS handshake process. I believe this will help faster than reviewing WireShark, which is unlikely to give the output you need.

Link to comment
Share on other sites

Thank you Steven. I was hoping Wireshark would tell me why it didn't accept/rejected the connection between the NS and the Windows Server but no dice. Something like 'insufficient key size' would have been nice but the only errors that were reported were from the script and Event Viewer which were the same and vague. I'll have to check out the tracing you suggested.
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...