This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

SSL negotiation errors

0

We are having issues when trying to connect via SSL using TLS 1.0 with PayPal. We have logs from good connections and bad (different IPs). When good, we are seeing TCP messages referencing synchromesh > https and https < synchromesh. When we fail, we see an-tcp > https and https < an-tcp, certificate requests, and then application data being sent across the line.

PayPal insists that all of their servers are configured exactly the same and the problem is on our end. We have 1 and only 1 server that connects successfully to 9 or their 10 servers in their DNS pool, so we think the issue is on the NEW server they just stood up.

How can we tell whether this is a certificate issue, a cypher issue, etc? We are not WireShark experts.

asked 24 May '16, 14:25

mimeyers's gravatar image

mimeyers
6112
accept rate: 0%

You'll have to delve into the TLS negotiations and compare the captures.

Can you share these captures in a publicly accessible spot, e.g. CloudShark?

(25 May '16, 02:57) Jaap ♦

Are there options we can set in Wireshark that will provide more information? As I said, we know little about the program.

I have uploaded the PCAP file for the failure to CloudShark with tags mmeyers, tls, failure.

(25 May '16, 05:28) mimeyers

The PCAP file from the same server that succeeded has also been uploaded with tags, mmeyers, tls, success

(25 May '16, 05:44) mimeyers

Wireshark allow you to set an SSL debug file through the SSL protocol dissector preferences. When loading the capture file this file will then be written with output from the SSL library, but is very technical, so you'll basically need the source code to understand what's in there.

(25 May '16, 07:38) Jaap ♦

Although posting the debug log here can help with diagnosis. Can you post an actual link to the captures on Cloudshark? I couldn't find a way to search for them.

(25 May '16, 08:05) grahamb ♦

Graham, the files are stored under my account, so not sure if you could access them. https://www.cloudshark.org/captures?_message=BAh7BjoLbm90aWNlSSIaV2VsY29tZSB0byBDbG91ZFNoYXJrBjoGRVQ%3D%0A

The files are 187K and 35K, so would be easily emailed if necessary.

(25 May '16, 09:27) mimeyers

@mimeyers,

Your "answers" have been converted to comments as that's how this site works. Please read the FAQ for more information.

In Cloudshark, click the (i) button next to each capture and on the resulting dialog select the sharing tab which will display the direct access URL. Edit your question and add those URL's.

(25 May '16, 09:49) grahamb ♦
showing 5 of 8 show 3 more comments

One Answer:

0

In the capture "Exported TLS failure", there a 4 connection attempts. The first is closed by the client when the PayPal server requests the client certificate. The second completes the TLS handshake but after some encrypted data is exchanged the PayPal server closes the connection. The third and fourth attempts are replicates of the first and second respectively.

Conclusion; your client is misbehaving in closing the connection after the server sends the client certificate request, and on the 2 instances where encrypted data is exchanged, the PayPal server has either finished the transaction or doesn't like the data from the client.

In the capture "Exported TLS success" there is the same behaviour, only more TLS connection attempts.

In all cases where encrypted data transferred, your client sent ~400 bytes and the server responded with ~1k bytes.

You'll probably need to look at your application logs as we're unable to look into the encrypted data.

answered 25 May '16, 10:40

grahamb's gravatar image

grahamb ♦
19.8k330206
accept rate: 22%

Is there a way to add our key to Wireshark to be able see the encrypted data? Both the failure and success were done from the same machine executing the exact same code. The only difference is the PayPal server. They have multiple (10) servers responding to requests to api.paypal.com. Our code has worked flawlessly for the past 5 years. Two weeks ago they added the 10th server to their group and the failures only occur when the new server answers our call. That is why we think it is either protocol or cipher related.

(25 May '16, 10:58) mimeyers

Generally you need the server's private key, which PayPal are unlikely to want to provide.

TLS using non-DH key exchanges, which your connection seems to be, can also be decrypted using the pre-master secret, but you have to arrange for your client to provide that.

See the Wiki page on SSL for more info.

You might also be able to use a web proxy such as Fiddler to perform a MITM and extract the encrypted data that way.

(26 May '16, 02:33) grahamb ♦

A further note is that the PayPal server isn't sending an SSL Alert to indicate it's closing the connection.

A useful guide to the anatomy of an SSL connection can be found here, although that doesn't show the Client Certificate tranfers that happen in your sessions as the PayPal server is using them to authenticate your client.

(27 May '16, 07:00) grahamb ♦