Snort mailing list archives
Re: tls1.3 support for 'ssl_version' and DTLS
From: Joshua Kinard via Snort-devel <snort-devel () lists snort org>
Date: Mon, 30 Apr 2018 16:52:15 -0400
IMHO, given 2.9.x is written in C, I think just splitting the flag int up into separate variables is the simpler approach. At least based on what I looked at. I'll have to stew on it. I've got other patches I've sat on that probably need priority on cleaning up to be sent in (flags Nonce bit, xor_decode/xor_data, SCTP decoding, ether_type, etc). As far as DTLS goes, I guess that's why those few rules I ran across were disabled, as they didn't work as intended. Just wanted to check to make sure I wasn't missing another undocumented feature. Thanks! On 4/30/2018 7:38 AM, Russ via Snort-devel wrote:
Joshua, Snort 3.0 will at least be adding support for detection of tls1.3. If this is something you want to pursue, another approach is to replace the separate bit flags with a 3-bit int that maps to an enum to indicate version. That would free up 2 bits. There is no specific plan for DTLS at the moment but we can check with Talos on the priority of that. Thanks for digging in. Russ On 4/30/18 3:54 AM, Joshua Kinard via Snort-devel wrote:Curious, with the recent release of TLS 1.3, are there plans to update the "ssl_version" keyword to support a "tls1.3" parameter to detect it? I looked at trying this myself, but the kicker is that all of the SSL record flags use a single 32-bit bitfield that has all of its bits used up in src/dynamic-preprocessors/ssl_common/ssl.h. To add a new record flag for a "tls1.3" parameter would require either extending the bitfield to 64-bits and changing a lot of places to handle the larger data type, or break up the bitfield into multiple 32-bit variables. The latter option probably is the most sensible for the long-term, but neither is a trivial change. Also, going through some older rulesets, I noticed that the ssl_version keyword was used in a few cases for DTLS over UDP. The Snort manual nor README.ssl make mention of DTLS support. The rules in question are since disabled (e.g., SID 32382), but does the SSL Preprocessor handle DTLS? If it does, has any thought been given to support detecting the HelloVerifyRequest phase for DTLS 1.2 and lower, or the new HelloRetryRequest for DTLS 1.3, both within the "ssl_state" keyword? Both are used for passing a challenge cookie given that DTLS is used over connectionless protocols (for UDP and DCCP)._______________________________________________ Snort-devel mailing list Snort-devel () lists snort org https://lists.snort.org/mailman/listinfo/snort-devel Please visit http://blog.snort.org for the latest news about Snort!
-- Joshua Kinard Gentoo/MIPS kumba () gentoo org rsa6144/5C63F4E3F5C6C943 2015-04-27 177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943 "The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between." --Emperor Turhan, Centauri Republic _______________________________________________ Snort-devel mailing list Snort-devel () lists snort org https://lists.snort.org/mailman/listinfo/snort-devel Please visit http://blog.snort.org for the latest news about Snort!
Current thread:
- tls1.3 support for 'ssl_version' and DTLS Joshua Kinard via Snort-devel (Apr 30)
- Re: tls1.3 support for 'ssl_version' and DTLS Russ via Snort-devel (Apr 30)
- Re: tls1.3 support for 'ssl_version' and DTLS Joshua Kinard via Snort-devel (Apr 30)
- Re: tls1.3 support for 'ssl_version' and DTLS Russ via Snort-devel (Apr 30)