Depth of offset for TLS traffic

Hi

I’m trying to understand just how deep in to a TCP flow we can inspect.

I have a TLS 1.2 pcap, The server hello + certifciate + server key exchnage + server hello done is split across 3 IP packets (frames 6,7 and 9).

I can write a rule that uses the offset for the total TCP stream and inspects data in the first two packets (frames 6 & 7) that contain the Certificate payload and then inspect parts of this.

But i can’t inspect anywhere past the second packet containing the certifciate, although the certifciate goes into the 3rd packet (frame 9).

TLS_Flow_1.2.pcapng (11.5 KB)

If I create the following rules;

alert tcp 13.37.193.63 443 → 192.168.1.23 53752 (msg: “Match last byte of packet 7 using offset 2895:”;content:“|af|”;depth:1;offset:2895;sid: 999;)

alert tcp 13.37.193.63 443 → 192.168.1.23 53752 (msg: “Match first byte of packet 9 using offset 2896:”;content:“|ae|”;depth:1;offset:2896;sid: 998;)

alert tcp 13.37.193.63 443 → 192.168.1.23 53752 (msg: “Match first byte of packet 9 using offset 0:”;content:“|ae|”;depth:1;offset:0;sid: 997;)

The first rule fires, the second rule doesn’t fire and the 3rd rule fires.

I know that |ae| is at offset 2896, but it seems that I can’t inspect on this.

I’m using Suricata 7.0.2.

I’ve also tried enabling;

tls:
enabled: yes
detection-ports:
dp: 443
encryption-handling: full

and

stream:
memcap: 64mb
#memcap-policy: ignore
checksum-validation: yes # reject incorrect csums
#midstream: false
#midstream-policy: ignore
inline: auto # auto will use inline mode in IPS mode, yes or no set it statically
reassembly:
memcap: 256mb
#memcap-policy: ignore
depth: 1mb # reassemble 1mb into a stream
toserver-chunk-size: 5000
toclient-chunk-size: 5000

/

$ suricata -c suricata_1.yaml -S test_sigs2.txt -r TLS_Flow_1.2.pcapng -v
Notice: suricata: This is Suricata version 7.0.2 RELEASE running in USER mode
Info: cpu: CPUs/cores online: 8
Info: suricata: Setting engine mode to IDS mode by default
Warning: app-layer-htp: Flash decompression is deprecated and will be removed in Suricata 8; see ticket #6179
Info: logopenfile: fast output device (regular) initialized: fast.log
Info: log-pcap: Using log dir .
Info: log-pcap: Selected pcap-log compression method: none
Info: log-pcap: Selected pcap-log conditional logging: tag
Info: log-pcap: using normal logging
Info: logopenfile: stats output device (regular) initialized: stats.log
Warning: classification-config: could not open: “/etc/suricata/classification.config”: No such file or directory
Error: classification-config: please check the “classification-file” option in your suricata.yaml file
Error: reference-config: Error opening file: “/etc/suricata/reference.config”: No such file or directory
Error: reference-config: please check the “reference-config-file” option in your suricata.yaml file
Info: detect: 1 rule files processed. 4 rules successfully loaded, 0 rules failed
Warning: threshold-config: Error opening file: “/usr/local/etc/suricata//threshold.config”: No such file or directory
Info: detect: 4 signatures processed. 0 are IP-only rules, 4 are inspecting packet payload, 0 inspect application layer, 0 are decoder event only
Info: log-pcap: Initializing PCAP ring buffer for ./log.pcap.
Notice: log-pcap: Ring buffer initialized with 0 files.
Info: pcap: Starting file run for TLS_Flow_1.2.pcapng
Info: pcap: pcap file TLS_Flow_1.2.pcapng end of file reached (pcap err code 0)
Notice: threads: Threads created → RX: 1 W: 8 FM: 1 FR: 1 Engine started.
Notice: suricata: Signal Received. Stopping engine.
Info: suricata: time elapsed 0.044s
Notice: pcap: read 1 file, 25 packets, 10590 bytes
Info: counters: Alerts: 2

I can confirm that the 2nd rule doesn’t trigger. Can you show, maybe with wireshark shot, why it should be that specific offset? I saw your af but not sure if the ae is correct.

Hi Andreas

Thanks for the reply. Sorry I should have said I’ve worked out what was wrong … :slight_smile:

I disabled TLS inspection and it works;

krb5:
enabled: yes
snmp:
enabled: yes
ike:
enabled: yes
tls:
enabled: no

if you need any clariification on the payload that i was matcing i’ll try to answer.

cheers

and ‘ae’ is the first byte of the 3rs TCP segment containing the certificate;