-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Decouple stream.bypass dependency from TLS encrypted bypass #10464
Decouple stream.bypass dependency from TLS encrypted bypass #10464
Conversation
Decouple app.protocols.tls.encryption-handling and stream.bypass. There's no apparent reason why encrypted TLS bypass traffic should depend on stream bypass, as these are unrelated features.
Update documentation to reflect the new features and changes.
NOTE: This PR may contain new authors. |
@@ -5472,17 +5472,13 @@ int StreamTcpPacket (ThreadVars *tv, Packet *p, StreamTcpThread *stt, | |||
} | |||
|
|||
if (ssn->flags & STREAMTCP_FLAG_BYPASS) { | |||
/* we can call bypass callback, if enabled */ | |||
if (StreamTcpBypassEnabled()) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
bonus : you can make this function static as it is only used in src/stream-tcp.c
Finally, if ``encryption-handling`` is set to ``full``, Suricata will process the | ||
flow as normal, without inspection limitations or bypass. | ||
Finally, if ``encryption-handling`` is set to ``full``, Suricata will process | ||
the flow as normal, without inspection limitations or bypass. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
unneeded change
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the work.
CI : ✅
Code : good but there is the SSH case
Commits segmentation : ok, also ok to squash
Commit messages : ok, but there is the SSH case as well
Git ID set : looks fine for me
CLA : I do not have access
Doc update : thanks for it. Maybe there should be a note in doc/userguide/upgrade.rst as well
Redmine ticket : ok
Rustfmt : not needed
Tests : 🟠 could you add a SV test for this ?
Dependencies added: none
So, the major question is the behavior change for SSH which now gets automatically bypassed, even if this is not mentioned in doc or commit messages... What do you think about it ?
If there's a change in behavior, then agreeing that we want a doc update. |
@msdean will you work further on this ? |
Possibly at some point, but the request of adding an SV test is a bit much for me, as I don't really have the time at the moment to setup a dev environment and onboard to the codebase. I was hoping to get away with a small PR with just this change 😅. |
Thanks for your answer, maybe we will pick it up.
Do you have an opinion about this ? |
I think it should either be documented or perhaps reworked in a way that doesn't affect SSH. |
Followed up on this in #11801 |
Make sure these boxes are signed before submitting your Pull Request -- thank you.
Link to redmine ticket:
https://redmine.openinfosecfoundation.org/issues/6788
Link to forum discussion: https://forum.suricata.io/t/encrypted-tls-bypass-dependency-on-stream-bypass/3528
Link to previous PR: #9127
Describe changes:
There's no apparent reason why encrypted TLS bypass traffic should
depend on stream bypass, as these are unrleated features.
Provide values to any of the below to override the defaults.
To use a pull request use a branch name like
pr/N
whereN
is thepull request number.
Alternatively,
SV_BRANCH
may also be a link to anOISF/suricata-verify pull-request.