recently I have been trying to completely bypass encrypted traffic. For that, I have found a TLS setting in the app-layer section of the suricata.yaml file to completely bypass the encrypted traffic (app-layer.protocols['tls'].encryption-handling).
I am not sure if I am doing something incorrectly but the setting does not seem to have an effect in my setup. Actually, with the setting set to full I receive 3 packets less compared to bypass value. I have tried it both on af-packet (with retransmission) and with offline reading of PCAP file, both leading to the same results.
Maybe I have an incorrect understanding of what the setting should do but I think with bypass set, Suricata should offload the encrypted flow as soon as the first TLS packet arrives (offloading with the first Client Hello message). This bypass should be equal to the bypass keyword used in rules.
I am attaching also the suricata.yaml file. I think the behavior can be tested with arbitrary TLS traffic.suricata.yaml (71.5 KB)
I’d also mention that in order to test the bypass functionality I am using the following rules:
alert ip any any -> any any (msg: "Packet!"; flow: to_server; sid: 999; rev:1;)
alert ip any any -> any any (msg: "Packet!"; flow: to_client; sid: 998; rev:1;)
With these rules, I expect to log any packet that got into Suricata detection module. With these rules, I got the above-mentioned results, meaning, an alert was generated for every packet of the PCAP file - even for TLS application data. When I had the same rules but additionally with the bypass rule keyword, then bypassing worked as it should - the number of alerts in fast.log were dramatically reduced.
I would like to also add that if I use these rules:
alert ip any any -> any any (msg: "Packet!"; flow: to_server; sid: 999; rev:1;)
alert ip any any -> any any (msg: "Packet!"; flow: to_client; sid: 998; rev:1;)
alert tls any any -> any any (msg: "TLS bypassed!"; flow: to_server; bypass; sid: 997; rev:1;)
alert tls any any -> any any (msg: "TLS bypassed!"; flow: to_client; bypass; sid: 996; rev:1;)
the amount of generated alerts also heavily decreases. The last two rules should only match TLS traffic and immediately bypass it after the first packet of TLS session. I think this is the closest (it still analyze one TLS packet) of what I imagine the setting app-layer.protocols['tls'].encryption-handling: bypass should do.
I am also attaching a PCAP I am using for the testing. shmu-tls.pcap (1010.7 KB)
I took my time and went through the code to solve the problem. I’ve learned that in order to bypass encrypted traffic you also need to set stream.bypass setting to true. So bypass setting needs to be enabled in both places of the configuration file.
I am going through similar issue, I changed stream.bypass setting true however I am still seeing TLS traffic . Can you please share your latest yml file for comparison.
for the record, I am attaching the config I have used. For the testing, I’ve used the 2 above-mentioned rules and ran Suricata in offline mode (reading PCAP directly).
Also, you mentioned you are seeing TLS traffic - the bypass will not filter all TLS traffic, it will only filter out the encrypted part (Application Data and probably Encrypted Alerts too), so TLS handshakes are still present. After the initial handshake is done, Suricata sets bypass on the given TLS flow. It might also happen that if the flow is inactive for some time, it is timed out. Then, if new encrypted data come, Suricata inspects the traffic too. The timeout settings can also be found in the config. But I guess seeing the TLS traffic after the flow has been timed out is not your case.