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

Multiple RST packets in HTTPS and then Connection Termination

0

Hi All,

I have been analyzing the wire shark logs of an HTTPS communication between two Applications. One applications works always, and the second one causes intermittent failures. I will post the logs of the one sample dialogue between the two and highlight the differences. But being new to Wire shark, I am not able to interpret what behavior change is being caused by the difference, and need your expert opinion on the same:

Working Application Logs

  1. 1142 109.255954 16.185.87.18 15.5.160.6 TCP 66 58382 > https [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1
  2. 1146 109.562500 15.5.160.6 16.185.87.18 TCP 66 https > 58382 [SYN, ACK] Seq=0 Ack=1 Win=8760 Len=0 MSS=1460 WS=1 SACK_PERM=1
  3. 1147 109.562548 16.185.87.18 15.5.160.6 TCP 54 58382 > https [ACK] Seq=1 Ack=1 Win=65536 Len=0
  4. 1148 109.566846 16.185.87.18 15.5.160.6 TLSv1 149 Client Hello
  5. 1152 109.873089 15.5.160.6 16.185.87.18 TCP 60 https > 58382 [ACK] Seq=1 Ack=96 Win=8665 Len=0
  6. 1153 109.874842 15.5.160.6 16.185.87.18 TLSv1 801 Server Hello, Certificate, Server Hello Done
  7. 1154 109.875756 16.185.87.18 15.5.160.6 TLSv1 252 Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message
  8. 1158 110.182242 15.5.160.6 16.185.87.18 TCP 60 https > 58382 [ACK] Seq=748 Ack=294 Win=8467 Len=0
  9. 1159 110.273444 15.5.160.6 16.185.87.18 TLSv1 113 Change Cipher Spec, Encrypted Handshake Message
  10. 1161 110.308246 16.185.87.18 15.5.160.6 TLSv1 171 Application Data
  11. 1164 110.614644 15.5.160.6 16.185.87.18 TCP 60 https > 58382 [ACK] Seq=807 Ack=411 Win=8350 Len=0
  12. 1167 110.663087 15.5.160.6 16.185.87.18 TLSv1 395 Application Data
  13. 1168 110.666238 15.5.160.6 16.185.87.18 TCP 1514 [TCP segment of a reassembled PDU]
  14. 1169 110.666281 16.185.87.18 15.5.160.6 TCP 54 58382 > https [ACK] Seq=411 Ack=2608 Win=65536 Len=0
  15. 1170 110.666301 15.5.160.6 16.185.87.18 TCP 1514 [TCP segment of a reassembled PDU]
  16. 1178 110.872278 16.185.87.18 15.5.160.6 TCP 54 58382 > https [ACK] Seq=411 Ack=4068 Win=65536 Len=0
  17. 1181 110.973815 15.5.160.6 16.185.87.18 TCP 1514 [TCP segment of a reassembled PDU]
  18. 1187 111.182323 16.185.87.18 15.5.160.6 TCP 54 58382 > https [ACK] Seq=411 Ack=5528 Win=65536 Len=0
  19. 1189 111.489027 15.5.160.6 16.185.87.18 TLSv1 799 Application Data
  20. 1190 111.489779 16.185.87.18 15.5.160.6 TCP 54 58382 > https [FIN, ACK] Seq=411 Ack=6273 Win=64768 Len=0
  21. 1201 111.796470 15.5.160.6 16.185.87.18 TCP 60 https > 58382 [ACK] Seq=6273 Ack=412 Win=8349 Len=0
  22. 1202 111.796879 15.5.160.6 16.185.87.18 TLSv1 91 Encrypted Alert
  23. 1203 111.796923 16.185.87.18 15.5.160.6 TCP 54 58382 > https [RST, ACK] Seq=412 Ack=6310 Win=0 Len=0
  24. 1204 111.796949 15.5.160.6 16.185.87.18 TCP 60 https > 58382 [FIN, PSH, ACK] Seq=6310 Ack=412 Win=8349 Len=0
  25. 1205 111.796967 16.185.87.18 15.5.160.6 TCP 54 58382 > https [RST] Seq=412 Win=0 Len=0

Then a new connection session begins:

  1. 1259 113.651110 16.185.87.18 15.5.160.6 TCP 66 58385 > https [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1
  2. 1269 113.957672 15.5.160.6 16.185.87.18 TCP 66 https > 58385 [SYN, ACK] Seq=0 Ack=1 Win=8760 Len=0 MSS=1460 WS=1 SACK_PERM=1
  3. ...

But in case of the application instance that has failures I am noticing some differences. Let me highlight the part.

Failing Application Logs

  1. 4267 58.755022 16.185.87.18 15.5.160.6 TCP 66 58340 > https [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1
  2. 4423 59.061045 15.5.160.6 16.185.87.18 TCP 66 https > 58340 [SYN, ACK] Seq=0 Ack=1 Win=8760 Len=0 MSS=1460 WS=1 SACK_PERM=1
  3. 4424 59.061089 16.185.87.18 15.5.160.6 TCP 54 58340 > https [ACK] Seq=1 Ack=1 Win=65536 Len=0
  4. 4425 59.066820 16.185.87.18 15.5.160.6 TLSv1 149 Client Hello
  5. 4430 59.375396 15.5.160.6 16.185.87.18 TCP 60 https > 58340 [ACK] Seq=1 Ack=96 Win=8665 Len=0
  6. 4431 59.377159 15.5.160.6 16.185.87.18 TLSv1 801 Server Hello, Certificate, Server Hello Done
  7. 4432 59.378007 16.185.87.18 15.5.160.6 TLSv1 252 Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message
  8. 4435 59.686364 15.5.160.6 16.185.87.18 TCP 60 https > 58340 [ACK] Seq=748 Ack=294 Win=8467 Len=0
  9. 4439 59.779045 15.5.160.6 16.185.87.18 TLSv1 113 Change Cipher Spec, Encrypted Handshake Message
  10. 4441 59.832138 16.185.87.18 15.5.160.6 TLSv1 203 Application Data
  11. 4445 60.138602 15.5.160.6 16.185.87.18 TCP 60 https > 58340 [ACK] Seq=807 Ack=443 Win=8318 Len=0
  12. 4446 60.189159 15.5.160.6 16.185.87.18 TLSv1 395 Application Data
  13. 4447 60.192510 15.5.160.6 16.185.87.18 TCP 1514 [TCP segment of a reassembled PDU]
  14. 4448 60.192609 16.185.87.18 15.5.160.6 TCP 54 58340 > https [ACK] Seq=443 Ack=2608 Win=65536 Len=0
  15. 4449 60.192621 15.5.160.6 16.185.87.18 TCP 1514 [TCP segment of a reassembled PDU]
  16. 4454 60.388331 16.185.87.18 15.5.160.6 TCP 54 58340 > https [ACK] Seq=443 Ack=4068 Win=65536 Len=0
  17. 4455 60.499965 15.5.160.6 16.185.87.18 TCP 1514 [TCP segment of a reassembled PDU]
  18. 4456 60.698432 16.185.87.18 15.5.160.6 TCP 54 58340 > https [ACK] Seq=443 Ack=5528 Win=65536 Len=0
  19. 4460 61.007118 15.5.160.6 16.185.87.18 TLSv1 799 Application Data
  20. 4461 61.011470 16.185.87.18 15.5.160.6 TCP 54 58340 > https [FIN, ACK] Seq=443 Ack=6273 Win=64768 Len=0
  21. 4462 61.013786 16.185.87.18 15.5.160.6 TCP 66 58342 > https [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1
  22. 4464 61.317911 15.5.160.6 16.185.87.18 TCP 60 https > 58340 [ACK] Seq=6273 Ack=444 Win=8317 Len=0
  23. 4465 61.318379 15.5.160.6 16.185.87.18 TLSv1 91 Encrypted Alert
  24. 4466 61.318407 16.185.87.18 15.5.160.6 TCP 54 58340 > https [RST, ACK] Seq=444 Ack=6310 Win=0 Len=0
  25. 4467 61.318655 15.5.160.6 16.185.87.18 TCP 60 https > 58340 [FIN, PSH, ACK] Seq=6310 Ack=444 Win=8317 Len=0
  26. 4468 61.318671 16.185.87.18 15.5.160.6 TCP 54 58340 > https [RST] Seq=444 Win=0 Len=0

Then the second call starts:

  1. 4469 61.321573 15.5.160.6 16.185.87.18 TCP 66 https > 58342 [SYN, ACK] Seq=0 Ack=1 Win=8760 Len=0 MSS=1460 WS=1 SACK_PERM=1
  2. 4470 61.321597 16.185.87.18 15.5.160.6 TCP 54 58342 > https [ACK] Seq=1 Ack=1 Win=65536 Len=0
  3. ...

After running like this for a while, then we start seeing issues like:

  1. 4710 65.535669 16.185.87.18 15.5.160.6 TCP 54 58343 > https [RST, ACK] Seq=337 Ack=5642 Win=0 Len=0
  2. 4711 65.535713 15.5.160.6 16.185.87.18 TCP 60 https > 58343 [FIN, PSH, ACK] Seq=5642 Ack=337 Win=8424 Len=0
  3. 4712 65.535725 16.185.87.18 15.5.160.6 TCP 54 58343 > https [RST] Seq=337 Win=0 Len=0
  4. 4715 65.701371 15.5.160.6 16.185.87.18 TCP 60 https > 58344 [RST] Seq=1 Win=0 Len=0
  5. 4720 65.843009 15.5.160.6 16.185.87.18 TCP 60 https > 58344 [RST] Seq=1 Win=0 Len=0
  6. 4721 65.843798 15.5.160.6 16.185.87.18 TCP 60 https > 58344 [RST] Seq=1 Win=0 Len=0

This tells me that, in case of the second application, before even the connection for first request over HTTPS has been closed, the initial handshaking for the second request as well has started. Please notice: Line number 21, in case of Failing Application Logs.

But, with my limited knowledge, thats what I am guessing, if somebody could confirm, that is the case, could explain things a bit, it would be really helpful.

Thanks and Regards,

Sanket

asked 22 Sep '12, 04:02

Sanket's gravatar image

Sanket
1●1●1●1
accept rate: 0%

It takes much more time for us if don't post the actual pcap file. But opening a second connection isn't a problem in and of itself. It could be opening up a new connection because of HTTP issues (redirects for example) or because SSL has a short keep-alive timer. The "Encrypted alert" is telling you the SSL is about to be torn down. You need to look inside the SSL by decoding it (requires getting the key) or by using client tools like HTTP Analyzer.

(22 Sep '12, 16:55) hansangb