In my particular case, there seem to be multiple abbreviated handshakes performed after the initial session creating full handshake, and these use multiple additional ports. Decryption is failing, and I am seeing "mac failed" errors in the ssl debug log. I'm wondering if this is caused by the abbreviated handshakes? I can't really post the pcap as there's some sensitive info. in there. asked 11 Jun '13, 03:14  AdamZSI |
One Answer:
If the initial full SSL handshake is also in the tracefile and the sessions are indexed by a SSL SessionID, you should be able to decrypt the resumed sessions (with abbreviated handshakes) too. AFAIK, Wireshark does not (yet) support decryption of sessions that used a TLS session ticket to resume the session. answered 11 Jun '13, 04:07  SYN-bit ♦♦ |
Thank you, that's as I understood but good to get confirmation. I'll accept that as the answer, but as a quick follow up, what are the likely/possible reasons for "mac failed" errors? It seems like SOME http is decrypted successfully, but others not (I have a lot of "Continuation or non-HTTP traffic" and a lot of "Ignored or Unknown Record"). Any pointers?
Do you have retransmissions or out-of-order packets in the sessions where decryption fails?
Yes there are a fair number of [TCP Retransmission] and [TCP previous segment not captured] and [TCP Out of order]. Some from client, some from server. I think they're all after the abbreviated handshakes. Also getting some [TCP Dup Ack], don't know if that matters