Bug #6634
open
tls: Invalid ja3 due to double client hello
Added by Eric Leblond 5 months ago.
Updated 7 days ago.
Description
Stamus Networks team has discovered some weird TLS connections happening in real networks. These connections are not respecting the TLS RFCs as the client sends 2 hello messages (one in TLS 1.2 and the other one in TLS v1.3) but the server does not care and answer any way.
The result is surprising as the ja_string ends up to compose of 9 commas separated elements and as a result the ja3 hash is not computed on one or the other of the hello message.
Related issues
1 (1 open — 0 closed)
- Affected Versions 7.0.1 added
- Affected Versions deleted (
7.0.0)
Can you share a pcap / SV test for this?
Can confirm we are seeing exactly this problem on approx 0.005% of TLS sessions
I am also seeing a case where only two fields are being output, this also seems invalid: "771,4865-4866-4867-49195-49199-49196-49200-52393-52392-49171-49172-156-157-47-53"
And another discrepancy, which I am not sure about and investigating a bit more is that, sometimes the EVE JSON reports "TLS 1.3", but both ja3-strings are saying 771 (TLS 1.2). Not sure why this is.
- Related to Bug #7016: tls: hello retry request handling issues added
- Subject changed from Invalid ja3 due to double client hello to tls: Invalid ja3 due to double client hello
Also available in: Atom
PDF