-
Notifications
You must be signed in to change notification settings - Fork 20
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RFC: implement TLS auto-detection #372
Open
bazsi
wants to merge
25
commits into
axoflow:main
Choose a base branch
from
bazsi:implement-tls-auto
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Changes from 23 commits
Commits
Show all changes
25 commits
Select commit
Hold shift + click to select a range
7fa17ee
light: allow the use of "auto" transport for syslog() source drivers
bazsi 17cacbe
logproto: rename prepare() methods to poll_prepare
bazsi 7acce3d
transport-stack: add poll_prepare() methods for LogTransport and LogT…
bazsi d31e254
transport-stack: add LogTransportStack level read/write/writev methods
bazsi 008fc75
transport-adapter: add free_method
bazsi 43ed813
transport/tls-context: simplify compression setup
bazsi fcddbce
transport-tls: convert to a LogTransportAdapter
bazsi b2d6bb4
transport-aux-data: add log_transport_aux_data_move()
bazsi 6d026b0
transport-stack: make it possible to add aux data from the LogTranspo…
bazsi 93df75b
logproto: call transport-stack level I/O methods
bazsi 9853f73
logproto/logproto-auto-server: remove RFC6587 references from log mes…
bazsi 8eaec3e
templates: add $SOURCEPORT macro
bazsi eea12d4
transport-haproxy: use the normal $SOURCEIP, $DESTIP, $DESTPORT macros
bazsi 26ac510
transport-haproxy: use the LogTransportStack->aux to save src/dst add…
bazsi 1d1d126
transport-haproxy: implement transport switch instead of changing bas…
bazsi 492e17e
transport-haproxy: add more information to the proxy detection failur…
bazsi 8acb805
afsocket: refactor TransportMapperInet transport setup logic
bazsi 6b1ee3b
afsocket: transport(auto) with tls() should immediately start using TLS
bazsi 1794e27
transport/transport-factory-haproxy: use factory for creating HAProxy…
bazsi c435cf1
light: generalize test_pp_network and test_pp_syslog test cases
bazsi 7b7ce57
light: fix up files included in the dist
bazsi e8322f7
news: added news file
bazsi bbe0595
logproto: add support for auto-detecting TLS handshakes
bazsi 770c78a
logproto-auto-server: also recognize TLS alerts and reject them expli…
bazsi 7c9a46a
logproto-auto-server: add detection of binary data
bazsi File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
TLS auto-detection sounds like a security issue for me. TLS provides encryption and authentication.
If we want to allow non-TLS and TLS traffic on the same port, we should notify the user with a big warning that neither encryption nor authentication is guaranteed. We could probably do this when
peer-verify(off)
is set, but even then we should warn the user that encryption is also optional so vulnerable to "downgrade attack".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.
I agree with that in general, however I think the syslog over TLS use-case is slightly different.
With those in mind:
Downgrade of the client: this is not possible, as the client has TLS enabled or it doesn't. If we had an active attacker, and this would be merged, the attacker could fool the server to accept plain text instead of TLS. But this does not change how the client is configured: the client would require TLS anyway with both encryption and authentication.
Downgrade of the server: this is indeed possible, client talking TLS while the server receives plain text. Going back to the first case, if the client has TLS configured and authenticates the server, the attacker would need to have a trusted X.509 certificate. In which case they don't even need to talk to the server.
And some more context:
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.
I agree that this is a useful feature, I would like to just add some security measures of how we enable such functionality. From the server's perspective, encrypted and non-encrypted, authenticated and non-authenticated data will flow from the same source and the user has very little influence on how to distinguish between the two (same source -> same log paths, same destinations, and we only have a few TLS-related macros to filter for authenticated and/or encrypted data).
My suggestion would be the following:
transport(auto)
should allow everything that does not have security implicationstransport(auto) + optional-tls(yes/no)
should enable TLS auto-detection (I'm open to rename the option to anything else). In the documentation of this option, we should mention how users can filter for TLS-encrypted/authenticated data using macros.What do you think?
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.
I agree completely. That's exactly what we discussed in the past couple of days. That's why the patch is in RFC yet.
So, yes, I agree we need a way to specify require-tls(yes). And I think we should also revisit information about a message being encrypted or not once we receive it