Skip to main content

Timeline for Firewalls and ACKs

Current License: CC BY-SA 3.0

12 events
when toggle format what by license comment
Feb 16, 2018 at 4:25 history edited Ron Maupin
edited tags
Mar 12, 2015 at 21:14 vote accept Rafe
Mar 12, 2015 at 21:14 vote accept Rafe
Mar 12, 2015 at 21:14
Mar 12, 2015 at 21:14 vote accept Rafe
Mar 12, 2015 at 21:14
Mar 9, 2015 at 21:51 history edited Rafe CC BY-SA 3.0
added 824 characters in body
Mar 9, 2015 at 7:22 answer added Eddie timeline score: 2
Mar 9, 2015 at 5:29 comment added Eddie @karyhead brings up great points. A bit more info: Typically the first two messages in the SSL Handshake are a Client Hello and a Server Hello. These two messages typically don't contain much data, so its very rare that you would need to packets to send the same set of data. After the Win7 box sends two packets, the RemoteSupport backs "ACKs" 156 and 173, which means the initial two packets were only 172 bytes. Most Client Hellos are around 200~ -- this was definitely not a Client Hello so large that it must have been sent in two packets. Your capture is not a regular TLS handshake.
Mar 9, 2015 at 5:05 answer added James Shewey timeline score: 0
Mar 7, 2015 at 0:10 comment added karyhead Some observations. TCP handshake completes successfully. The next thing that should happen is an SSL handshake. The client sends its Hello, which I will assume are pkts 4 and 5. The server's TCP ACKs this data and then should send its Hello. Instead it closes the connection with a FIN. Considering that there's no real delay (deltas are sub-millisecond), I doubt packets are getting dropped and the connection is closed due to timeout. Either the client isn't sending a proper SSL Hello or the server doesn't like the Hello. Either way the server closes the connection.
Mar 6, 2015 at 22:40 answer added dareuja timeline score: 1
Mar 6, 2015 at 19:58 review First posts
Mar 6, 2015 at 23:14
Mar 6, 2015 at 19:56 history asked Rafe CC BY-SA 3.0