Solved

Help reading a Network Packet Capture related to TLS / port 443

Posted on 2015-02-03
3
200 Views
Last Modified: 2016-03-24
First, please understand that I'm not an expert (at all) in networking or reading packet captures.


I'm troubleshooting an issue between a Web server and PayPal IPN.  The issue appears to have started around the time PayPal stopped supporting SSL 3.0.

The web server is IIS6 so it ONLY supports TLS 1.0.  All versions of SSL are disabled.


What I'm comparing are two wireshark traces of PayPal connecting to a "special URL" on the web server (to perform the IPN postback after the paypal transaction processes)

- One trace is of the PayPal simulator connecting to this special URL on the web server (PayPal's simulator reports this as successful)

- The other is a live paypal transaction (the step where PayPal IPN connects to the special URL to post back the transaction).  PayPal reports it fails to connect to this URL in some way (I haven't been able to get more details, their canned notification says things like check firewall, etc. but this clearly isn't that anything is blocking PayPal)


In looking at the traces, there are some differences I'm not quite clear on.  On the 'simulator' trace (the one PayPal reports as successful), the connection appears to be attempted only using TLS 1.0.

On the trace of a live PayPal transaction, the packet details are showing both TLS 1.2 and TLS 1.0  (the IIS6 server doesn't support TLS 1.2 but it does support TLS 1.0)


My first question is:   On the live transaction, is it that PayPal attempted TLS 1.2 first, and then since TLS 1.2 is not available it then attempted TLS 1.0?   (based on the order in the "Secure Sockets Layer" section, is this correct way of reading this (TLS 1.2 then TLS 1.0).  My understanding of SSL/TLS in general is that it would try the higher first and if not supported try older versions but I'm not sure if that's what the packet shows.

Or is it stating which TLS versions it supports and the next step is the web application or server to select a version? (and if so, is it the web SERVER or the web APPLICATION that makes that choice?)


Any idea what to make of these two traces, I would have expected a simulator to work the same as the live version but it seems to be clearly connecting in a different way and I'm not quite understanding it.

Any guidance would be much appreciated.

Mostly trying to determine if the issue is with the web application, the web server (IIS6), the server (Windows Server 2003)



Thanks



LIVE TRANSACTION:

TLS-safe.jpg

SIMULATOR:

TLS-sim-safe.jpg
0
Comment
Question by:Vas
  • 2
3 Comments
 
LVL 5

Accepted Solution

by:
Sean Jackson earned 500 total points
ID: 40587433
For the handshake to work, both the server and the client must have matching cipher algorithms in the array of usable ciphers.  As the handshake starts, the client hits the server and says "I want to initiate communication with you". The server says (if the client hit port 80), "We're going to take this over to port 443 because we're going to encrypt this traffic". The client sends over a list of ciphers it likes to use. The server starts at the top and tries to match. If it can't communicate, they do what is called a 'Downward Dance' and they choose weaker ciphers and try again, over and over, until they find a match. Then begin communicating the details of the encryption to be used, setting up secret keys and agreed secrets, until the handshake is complete and the session is begun. If the connection is interrupted, often the whole negotiation must be started over.
0
 
LVL 1

Author Comment

by:Vas
ID: 40587469
Thanks, so by looking at the traces (and I can send screenshots of the other sections of the frame) does it look like maybe it's an issue with the cipher suites?   PayPal supports 80 ciphers based on part of the packet capture and the two ciphers that the TLS 1.0 server supports are listed in PayPal's list so I thought we were OK there.

Or does this look like some other issue?

Basically after that 'Client Hello' frame on the live transaction the next frame is a FIN/ACK.   Wouldn't a renegotiation be another frame if that was the case of it needing to try a different cipher?


Thanks
0
 
LVL 5

Expert Comment

by:Sean Jackson
ID: 40587492
The next frame being a FIN/ACK is odd. You want a SYN/ACK.  

That sounds like a closed port (FIN) and then the next step in the handshake (ACK).
0

Featured Post

Simplifying Server Workload Migrations

This use case outlines the migration challenges that organizations face and how the Acronis AnyData Engine supports physical-to-physical (P2P), physical-to-virtual (P2V), virtual to physical (V2P), and cross-virtual (V2V) migration scenarios to address these challenges.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Suggested Solutions

If you thought ransomware was bad, think again! Doxware has the potential to be even more damaging.
Healthcare providers, insurance companies and other covered entities trust eFax Corporate to transmit their most sensitive documents. eFax Corporate can help your organization implement a HIPAA compliant cloud faxing solution.
With Secure Portal Encryption, the recipient is sent a link to their email address directing them to the email laundry delivery page. From there, the recipient will be required to enter a user name and password to enter the page. Once the recipient …
With Secure Portal Encryption, the recipient is sent a link to their email address directing them to the email laundry delivery page. From there, the recipient will be required to enter a user name and password to enter the page. Once the recipient …

713 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question