Project

General

Profile

Actions

Bug #4917

open

tls: leading GAP in toserver direction leads to various issues

Added by Victor Julien about 3 years ago. Updated over 1 year ago.

Status:
New
Priority:
Normal
Assignee:
Target version:
Affected Versions:
Effort:
Difficulty:
Label:

Description

Attached is a pcap from https://github.com/OISF/suricata-verify/tree/master/tests/tls-ja3s, but with the first data segment to the server (the client hello) removed.

This leads to various issues:
  • flow logging app_proto as "failed", even if app_proto_tc is "tls".
  • no TLS logging or inspection
  • no GAP detected
  • app-layer event applayer_wrong_direction_first_data triggering

The parser does not support GAPs or first data into the toclient direction. Since the leading GAP isn't detected (in time), the first data sent to the parser is in the toclient direction. This is then rejected and leads to the event and failure state for the flow.


Files


Related issues 3 (3 open0 closed)

Related to Suricata - Task #3560: ssl/tls: support GAP recoveryNewOISF DevActions
Related to Suricata - Task #3553: Tracking: enable GAP recovery for all TCP app-layer protocolsNewOISF DevActions
Related to Suricata - Bug #7238: applayer: protocol flows are miscounted in case of errorAssignedShivani BhardwajActions
Actions #1

Updated by Victor Julien about 3 years ago

  • Related to Task #3560: ssl/tls: support GAP recovery added
Actions #2

Updated by Victor Julien about 3 years ago

  • Related to Task #3553: Tracking: enable GAP recovery for all TCP app-layer protocols added
Actions #3

Updated by Philippe Antoine over 1 year ago

  • Target version set to 8.0.0-beta1
Actions #4

Updated by Philippe Antoine over 1 year ago

  • Assignee set to OISF Dev
Actions #5

Updated by Victor Julien 24 days ago

  • Related to Bug #7238: applayer: protocol flows are miscounted in case of error added
Actions

Also available in: Atom PDF