Re: tls1.3 support for 'ssl_version' and DTLS

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
[email protected]
https://lists.snort.org/mailman/listinfo/snort-devel

Please visit http://blog.snort.org for the latest news about Snort!