Suggestions for #3160

[olix0r]

commit f78aa64
Author: Oliver Gould [email protected]
Date: Thu Oct 10 14:18:31 2024 +0000

tls: Avoid InsertParam parameter.

We don't actually use InsertParam all that much--only in the TLS server (which
is obviously why it was included here). This change removes the InsertParam in
favor of using a tuple, generally reducing boilerplate.

It turns out that the TLS stack already has a map_target to handle turning the
tuple-target into a Tls type, so it shouldn't be needed.

commit 67c0e84
Author: Oliver Gould [email protected]
Date: Thu Oct 10 14:49:32 2024 +0000

tls: Remove ExtractParam from detect_sni

Similarly, we don't actually care about extracting a timeout from the target.
Using an ExtractParam causes needless boilerplate.

This change updates the stack module to simply take a timeout parameter at
construction time.

commit f6202d6
Author: Oliver Gould [email protected]
Date: Thu Oct 10 15:03:42 2024 +0000

tls: Make the detect_tls module private

We now only need to export the NewDetectSni type. The module reexport is not
necessary.

commit ae88d2e (HEAD -> ver/zd/tls-stack, origin/ver/zd/tls-stack)
Author: Oliver Gould [email protected]
Date: Thu Oct 10 15:20:17 2024 +0000

tls: Reorganize NewDetectRequiredSni under the server module

Because the DetectTls and DetectSni types are so similar -- and implemented in
the context of a server inspecting a provided connection (and not a client
establishing a TLS connection), this change reorganizes the module:

* The DetectSni types are renamed to DetectRequiredSni to better reflect their
  purpose and difference from the DetectTls type.
* The detect_sni module is renamed and moved to server::required_sni. This
  module is private and the relevant types are reexported from the server

[zaharidichev]

What are the special affordances in the other case? From my understand, in the DetectTLS, we determine whether we terminate based on whether the SNI matches the local identitty. Is that what you are refering to here?