search

ge0rg / tls-hello-dump

TLS ClientHello/ServerHello Dumper - extracts TLS versions and ciphers from network interfaces / PCAPs
52 stars 12 forks source link

TLS Alerts not skipped #6

Open ecki opened 9 years ago

ecki commented 9 years ago

I had some ServerHello messages missing. Upon closer inspection it was due to Alert records (SNI host_unknown warning) before the actual ServerHello record. Since they are all in the same segment/package I think it would be a usefull addition to be able to skip alerts. This would also mean to change the default packet filter a bit.

ge0rg commented 9 years ago

The problem with the filter is, it is getting complex already. Could you provide a pcap of such an Alert record packet please? I'd like to look into it to determine what could be done.

However, I don't particularly like the idea of implementing a TLS record parser in BPF ;-) We might revert to passing all TLS packets to userland instead and do some more parsing/processing there.

ecki commented 9 years ago

You can test yourself, with the alias https://neskaya.eckenfels.com apache will generate an warning, with https://eckenfels.com you will get a sucessful handshake.

A sample trace is here http://bernd.eckenfels.net/view/alert.pcap .

The alert record is 15(alert) 0303(tls12) 0002(2bytes) 01(warn) 70(unrecognized name)

I am afraid the trace is somewhat before fragmentation (from the server), so the certificate record is corrupt, but the ServerHello is complete.

ge0rg commented 9 years ago

Okay, so this looks like we need a rule of the kind payload[0] == HANDSHAKE or payload[5+payload[3]*256+payload[4]] == HANDSHAKE or payload[<calculate third record position>] == HANDSHAKE or ....

As we need one level of indirection already to access the payload (tcp[tcp[12]/16*4]), we arrive at two levels for the BPF filter for the second TLS record, or we need to relax the filter to "port 443" (I see no sensible way to limit it to TLS traffic). Then we have to do a significant amount of application layer processing, and to restructure the reader code to silently discard packets that passed the BPF filter but are not Hellos (or not TLS at all, for STARTTLS protocols).

I am not saying this is impossible, just that it is not pretty. I could probably live with a BPF+parser extension to allow for the Hello to be the second TLS record, which should account for your alert use case.