Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

TLS not detected #1946

Closed
vel21ripn opened this issue Apr 17, 2023 · 15 comments · Fixed by #1948
Closed

TLS not detected #1946

vel21ripn opened this issue Apr 17, 2023 · 15 comments · Fixed by #1948
Labels
question

Comments

@vel21ripn
Copy link
Contributor

An issue with TLS detection has been found due to extra null bytes in the packet.
This is an "ACK only" packet that cannot contain data.

1 16:14:50.730262 IP (tos 0x0, ttl 125, id 20715, offset 0, flags [DF], proto TCP (6), length 52)
    111.111.111.111.58155 > 52.18.127.189.443: Flags [S], cksum 0x7576 (correct), seq 8029850, win 64240,
    options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
2 16:14:50.780521 IP (tos 0x0, ttl 233, id 0, offset 0, flags [DF], proto TCP (6), length 52)
    52.18.127.189.443 > 111.111.111.111.58155: Flags [S.], cksum 0x9623 (correct), seq 2341660060, ack 8029851, win 26883,
    options [mss 1460,nop,nop,sackOK,nop,wscale 8], length 0
3 16:14:50.781367 IP (tos 0x0, ttl 125, id 20716, offset 0, flags [DF], proto TCP (6), length 42)
    111.111.111.111.58155 > 52.18.127.189.443: Flags [.], cksum 0x3df7 (correct), seq 8029851:8029853, ack 2341660061, win 513, length 2
4 16:14:50.781920 IP (tos 0x0, ttl 125, id 20717, offset 0, flags [DF], proto TCP (6), length 557)
    111.111.111.111.58155 > 52.18.127.189.443: Flags [P.], cksum 0x85ff (correct), seq 8029851:8030368, ack 2341660061, win 513, length 517
5 16:14:50.832249 IP (tos 0x0, ttl 233, id 23901, offset 0, flags [DF], proto TCP (6), length 46)
    52.18.127.189.443 > 111.111.111.111.58155: Flags [.], cksum 0x3d81 (correct), seq 2341660061:2341660067, ack 8030368, win 110, length 6
6 16:14:50.832377 IP (tos 0x0, ttl 233, id 23902, offset 0, flags [DF], proto TCP (6), length 153)
    52.18.127.189.443 > 111.111.111.111.58155: Flags [P.], cksum 0x4f99 (correct), seq 2341660061:2341660174, ack 8030368, win 110, length 113

The traffic dump is available on google.drive https://drive.google.com/file/d/1oGhkGCqo__M2dTtGly8XW5-4vI6G2HOg/view?usp=sharing

The packets 3 and 4 is overlapped by seq_number!

The packets 5 and 6 is overlapped by seq_number!

If these empty bytes are ignored, then NDPI considers that the fourth packet is "tcp retransmission" :( and the 517 byte packet does not get into the TLS handler.

If these extra bytes are ignored, then TLS is successfully detected.

    1       TCP 111.111.111.111:58155 <-> 52.18.127.189:443 [proto: 91/TLS][IP: 265/AmazonAWS][Encrypted][Confidence: DPI][DPI packets: 13][cat: Web/5][28 pkts/6789 bytes <-> 35 pkts/8995 bytes][Goodput ratio: 78/79][130.64 sec][Hostname/SNI: bitrix.info][(Advertised) ALPNs: h2;http/1.1][(Negotiated) ALPN: h2][TLS Supported Versions: GREASE;TLSv1.3;TLSv1.2][bytes ratio: -0.140 (Mixed)][IAT c2s/s2c min/avg/max/stddev: 0/0 5498/4834 45102/45058 12717/11564][Pkt Len c2s/s2c min/avg/max/stddev: 56/60 242/257 1547/2974 352/535][TLSv1.2][JA3C: ab205d804ecf934209c2a1bb94f817e0][JA3S: bfc90d56141386ee83b56cda231cccfc][Chrome][Cipher: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256][Plen Bins: 46,22,6,6,0,0,0,0,0,0,1,0,6,0,1,1,3,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,0,0,0,0,0,0,0,0,0,0,0,1,1,1]

I can't offer a PR yet.
@vel21ripn
Copy link
Contributor Author

@IvanNardi
You were able to download the file?
I gave you access to the file.

@IvanNardi
Copy link
Collaborator

@IvanNardi You were able to download the file? I gave you access to the file.

Yes, I downloaded it.
Could you make it public for everyone, or ,better, attach it here (after having compress it in a zip file)?

@vel21ripn
Copy link
Contributor Author

@IvanNardi I maked this file public for everyone.

I see that there is quite a lot of such traffic. For 5 minutes about 2300 connections.

@vel21ripn
Copy link
Contributor Author

I made a PR, but it may not be a very accurate option.
Please see #1947

@IvanNardi
Copy link
Collaborator

This kind of traffic doesn't look random to me, but some kind of evasion technique...
Anyway, there are two different issues here:

  1. the second packets packet of the "pairs" (4 and 6) are marked as retransmission, but they are not. That 's not a surprise since the generic code in nDPI handling TCP retransmissions and similar issues is quite basic
  2. even without 1) there are the issue of how to handle overlapping-but-different bytes and that is a policy question, since there is not a right way: in this specific case is quite obvious to an human that we must ignore the first packet and keep the second one, but we can probably create an example the other way around. snort has a dedicated configuration parameter to decide exactly how to handle overlapping-but-different bytes and it handle 13 different cases!

Evading firewall/dpi engines/censorship systems with overlapping segments has been a well know technique for decades... unfortunately nDPI lacks any generic logic to handle it.
We could start implementing it (an hard and long task) or look for a quick hack for this specific case: at very least, any additional logic should be configurable and should be disable by default.

Tomorrow I'll take a proper look at you patch

@vel21ripn
Copy link
Contributor Author

It is highly unlikely that this is an evasion technique.
We see that such packets are transmitted in both directions.
I found 2 links to possible reasons for adding short packets.

https://bugs.centos.org/view.php?id=14435
https://ask.wireshark.org/question/11194/tcp-ack-shows-only-54-bytes-in-wireshark/

@IvanNardi
Copy link
Collaborator

Did you find the same pattern in traffic other than TLS? If it is a "generic" issue we should find it with all kinds of TCP traffic (plain HTTP or SSH, for example)

@IvanNardi
Copy link
Collaborator

@vel21ripn , could you share some other flows, please? (even TLS)

@vel21ripn
Copy link
Contributor Author

I will collect a sufficient set of such traffic.
I've only collected "tcp and port 443" traffic so far.
While I'm trying to figure out the reason for the lack of details (ja3s,ja3c) for a large number of connections defined as tls.
I found a program for splitting a .pcap file by tcp connections (pkt2flow), which greatly simplifies the analysis process.

@IvanNardi
Copy link
Collaborator

I will collect a sufficient set of such traffic.

Perfect. In the meantime, could you take a look at #1948? It is still a draft, but it should work

@vel21ripn
Copy link
Contributor Author

I wouldn't rush this PR without a sufficient set of traffic and traffic samples to test.

@vel21ripn
Copy link
Contributor Author

Statistics showed that padding does not depend on the application protocol.
The most common is the padding of 2 and 6 zero bytes.
The complexity of parsing a sequence in a tcp stream is increased due to SACK

@IvanNardi
Copy link
Collaborator

Ok, are you able to collect and share some of these flows?

@vel21ripn
Copy link
Contributor Author

I am now looking for different samples. This is very slow as it requires a lot of manual work.
There are very difficult partial retransmissions.

@vel21ripn
Copy link
Contributor Author

I posted typical traffic examples and a utility for analyzing tcp-sequence in my repository in the "pagging" branch.
Look in the utils/tcp_check_seq directory.

IvanNardi added a commit to IvanNardi/nDPI that referenced this issue Apr 20, 2023
@IvanNardi
Add an heuristic to detect/ignore some anomalous TCP ACK packets
53bd068 
In some networks, there are some anomalous TCP flows where the smallest
ACK packets have some kind of zero padding.
It looks like the IP and TCP headers in those frames wrongly consider the
0x00 Ethernet padding bytes as part of the TCP payload.
While this kind of packets is perfectly valid per-se, in some conditions
they might be treated by the TCP reassembler logic as (partial) overlaps,
deceiving the classification engine.
Add an heuristic to detect these packets and to ignore them, allowing
correct detection/classification.

This heuristic is configurable. Default value:
* in the library, it is disabled
* in `ndpiReader` and in the fuzzers, it is enabled (to ease testing)

Credit to @vel21ripn for the initial patch.

Close ntop#1946
@IvanNardi IvanNardi mentioned this issue Apr 20, 2023
Merged
IvanNardi added a commit to IvanNardi/nDPI that referenced this issue Apr 21, 2023
@IvanNardi
Add an heuristic to detect/ignore some anomalous TCP ACK packets
abfe157 
In some networks, there are some anomalous TCP flows where the smallest
ACK packets have some kind of zero padding.
It looks like the IP and TCP headers in those frames wrongly consider the
0x00 Ethernet padding bytes as part of the TCP payload.
While this kind of packets is perfectly valid per-se, in some conditions
they might be treated by the TCP reassembler logic as (partial) overlaps,
deceiving the classification engine.
Add an heuristic to detect these packets and to ignore them, allowing
correct detection/classification.

This heuristic is configurable. Default value:
* in the library, it is disabled
* in `ndpiReader` and in the fuzzers, it is enabled (to ease testing)

Credit to @vel21ripn for the initial patch.

Close ntop#1946
IvanNardi added a commit to IvanNardi/nDPI that referenced this issue Apr 21, 2023
@IvanNardi
Add an heuristic to detect/ignore some anomalous TCP ACK packets
5e51b16 
In some networks, there are some anomalous TCP flows where the smallest
ACK packets have some kind of zero padding.
It looks like the IP and TCP headers in those frames wrongly consider the
0x00 Ethernet padding bytes as part of the TCP payload.
While this kind of packets is perfectly valid per-se, in some conditions
they might be treated by the TCP reassembler logic as (partial) overlaps,
deceiving the classification engine.
Add an heuristic to detect these packets and to ignore them, allowing
correct detection/classification.

This heuristic is configurable. Default value:
* in the library, it is disabled
* in `ndpiReader` and in the fuzzers, it is enabled (to ease testing)

Credit to @vel21ripn for the initial patch.

Close ntop#1946
IvanNardi added a commit that referenced this issue Apr 25, 2023
@IvanNardi
Add an heuristic to detect/ignore some anomalous TCP ACK packets (#1948)
8934f7b 
In some networks, there are some anomalous TCP flows where the smallest
ACK packets have some kind of zero padding.
It looks like the IP and TCP headers in those frames wrongly consider the
0x00 Ethernet padding bytes as part of the TCP payload.
While this kind of packets is perfectly valid per-se, in some conditions
they might be treated by the TCP reassembler logic as (partial) overlaps,
deceiving the classification engine.
Add an heuristic to detect these packets and to ignore them, allowing
correct detection/classification.

This heuristic is configurable. Default value:
* in the library, it is disabled
* in `ndpiReader` and in the fuzzers, it is enabled (to ease testing)

Credit to @vel21ripn for the initial patch.

Close #1946
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
question
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Add an heuristic to detect/ignore some anomalous TCP ACK packets IvanNardi/nDPI
2 participants
@vel21ripn @IvanNardi