Project

General

Profile

Actions
Copy link

Bug #6634

closed
EL PA

tls: Invalid ja3 due to double client hello

Bug #6634: tls: Invalid ja3 due to double client hello

Added by Eric Leblond over 2 years ago. Updated over 1 year ago.

Status:
Closed
Priority:
Normal
Assignee:
Philippe Antoine
Target version:
8.0.0-beta1
Affected Versions:
6.0.14, 7.0.1
Effort:
medium
Difficulty:
Label:

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.

Subtasks 1 (0 open — 1 closed)

Bug #7239: tls: Invalid ja3 due to double client hello (7.0.x backport)ClosedPhilippe AntoineActions

Related issues 3 (1 open — 2 closed)

Related to Suricata - Bug #7016: tls: hello retry request handling issuesNewOISF DevActions
Related to Suricata - Bug #7256: ja3: Error: ja3: Buffer should not be NULLClosedPhilippe AntoineActions
Copied to Suricata - Bug #7685: tls: Invalid ja4 due to double client helloRejectedOISF DevActions

EL Updated by Eric Leblond over 2 years ago Actions
Copy link
 #1

  • Affected Versions 7.0.1 added
  • Affected Versions deleted (7.0.0)

VJ Updated by Victor Julien over 2 years ago Actions
Copy link
 #3

Can you share a pcap / SV test for this?

GT Updated by Gianni Tedesco about 2 years ago Actions
Copy link
 #4

Can confirm we are seeing exactly this problem on approx 0.005% of TLS sessions

GT Updated by Gianni Tedesco about 2 years ago Actions
Copy link
 #5

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"

GT Updated by Gianni Tedesco about 2 years ago Actions
Copy link
 #6

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.

VJ Updated by Victor Julien almost 2 years ago Actions
Copy link
 #7

  • Related to Bug #7016: tls: hello retry request handling issues added

VJ Updated by Victor Julien almost 2 years ago Actions
Copy link
 #8

  • Subject changed from Invalid ja3 due to double client hello to tls: Invalid ja3 due to double client hello

PA Updated by Philippe Antoine over 1 year ago Actions
Copy link
 #9

Gianni Tedesco wrote in #note-5:

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"

I can see one path where it happens :
Do you have TLS_DECODER_EVENT_HANDSHAKE_INVALID_LENGTH in these cases @Giuseppe Longo ?

PA Updated by Philippe Antoine over 1 year ago Actions
Copy link
 #10

  • Status changed from In Progress to In Review
  • Assignee changed from Eric Leblond to Philippe Antoine
  • Target version changed from TBD to 8.0.0-beta1

PA Updated by Philippe Antoine over 1 year ago Actions
Copy link
 #11

  • Label Needs backport to 7.0 added

OT Updated by OISF Ticketbot over 1 year ago Actions
Copy link
 #12

  • Subtask #7239 added

OT Updated by OISF Ticketbot over 1 year ago Actions
Copy link
 #13

  • Label deleted (Needs backport to 7.0)

PA Updated by Philippe Antoine over 1 year ago Actions
Copy link
 #14

  • Status changed from In Review to Resolved

PA Updated by Philippe Antoine over 1 year ago Actions
Copy link
 #15

  • Status changed from Resolved to Closed

PA Updated by Philippe Antoine over 1 year ago Actions
Copy link
 #16

  • Related to Bug #7256: ja3: Error: ja3: Buffer should not be NULL added

PA Updated by Philippe Antoine 12 months ago Actions
Copy link
 #17

  • Copied to Bug #7685: tls: Invalid ja4 due to double client hello added
Actions
Copy link

Also available in: PDF Atom