RFC: implement TLS auto-detection #372
Conversation
bazsi
force-pushed
the
implement-tls-auto
branch
from
05738ce to
ad7b0a4
Compare
bazsi
changed the title
bazsi
force-pushed
the
implement-tls-auto
branch
3 times, most recently
from
19a319d to
a2bc880
Compare
bazsi
changed the title
bazsi
force-pushed
the
implement-tls-auto
branch
from
a2bc880 to
3fe63bb
Compare
Signed-off-by: Balazs Scheidler <balazs.scheidler@axoflow.com>
Signed-off-by: Balazs Scheidler <balazs.scheidler@axoflow.com>
…ransportStack Signed-off-by: Balazs Scheidler <balazs.scheidler@axoflow.com>
Signed-off-by: Balazs Scheidler <balazs.scheidler@axoflow.com>
Signed-off-by: Balazs Scheidler <balazs.scheidler@axoflow.com>
bazsi
force-pushed
the
implement-tls-auto
branch
2 times, most recently
from
75602d6 to
7f4e008
Compare
Previously TLS compression was enabled using an overly complicated mechanism crossing a number of layers (TransportMapperInet -> TransportFactoryTLS -> TLSSession -> SSL). This can be a lot simpler, which this patch implements. NOTE: compression will not work in most cases due to OpenSSL security levels and this patch adds a warning about it. Signed-off-by: Balazs Scheidler <balazs.scheidler@axoflow.com>
Instead of going to the fd directly, wrap the lower-level LogTransport instance into a BIO and use that. This implements proper stacking for LogTransportTLS. This adds the use of OpenSSL BIOs to wrap the lower level LogTransport instance. Signed-off-by: Balazs Scheidler <balazs.scheidler@axoflow.com>
Signed-off-by: Balazs Scheidler <balazs.scheidler@axoflow.com>
…rtStack level Signed-off-by: Balazs Scheidler <balazs.scheidler@axoflow.com>
Signed-off-by: Balazs Scheidler <balazs.scheidler@axoflow.com>
…sages The "auto" protocol can be applied to both syslog() and network(), so it's not strictly RFC6587 related and it does not add too much information anyway. Signed-off-by: Balazs Scheidler <balazs.scheidler@axoflow.com>
Signed-off-by: Balazs Scheidler <balazs.scheidler@axoflow.com>
Instead of using proxy protocol specific name value pairs, set the addresses in the message's saddr/daddr members. This should be a lot faster and a lot easier to use. Signed-off-by: Balazs Scheidler <balazs.scheidler@axoflow.com>
…resses Signed-off-by: Balazs Scheidler <balazs.scheidler@axoflow.com>
…e_index Signed-off-by: Balazs Scheidler <balazs.scheidler@axoflow.com>
…e message Signed-off-by: Balazs Scheidler <balazs.scheidler@axoflow.com>
This reworks the various boolean members in TransportMapperInet that control which logproto/transport we apply to a specific connection. With these renames, it's much easier to follow what happens and why. NOTE: there's a followup bugfix that fixes the same bug as axoflow#482. Signed-off-by: Balazs Scheidler <balazs.scheidler@axoflow.com>
"auto" has originally been planned to auto-detect TLS as well as framing format, but at this point it does not do TLS auto-detection. But this means that transport(auto) with tls() options set will start reading data without SSL, e.g. the encrypted stuff will make it into the messages received. This patch fixes that for both the syslog() and the network() driver. The only change is that delegate_tls_start_to_logproto is FALSE for the "auto" case. This will be changed once the TLS auto detection feature is also in. Signed-off-by: Balazs Scheidler <balazs.scheidler@axoflow.com>
… transports Signed-off-by: Balazs Scheidler <balazs.scheidler@axoflow.com>
Instead of just exercising the proxyprotocol try all valid transports, including the "auto" variants. Signed-off-by: Balazs Scheidler <balazs.scheidler@axoflow.com>
Signed-off-by: Balazs Scheidler <balazs.scheidler@axoflow.com>
Signed-off-by: Balazs Scheidler <balazs.scheidler@axoflow.com>
Signed-off-by: Balazs Scheidler <balazs.scheidler@axoflow.com>
…citly If we are to receive an SSL connection attempt with impossible client-side settings, we might end up with an SSL alert instead of a ClienHello. Handle that case with an explicit action, instead of pulling in binary data from the socket. Signed-off-by: Balazs Scheidler <balazs.scheidler@axoflow.com>
Signed-off-by: Balazs Scheidler <balazs.scheidler@axoflow.com>
bazsi
force-pushed
the
implement-tls-auto
branch
from
7f4e008 to
7c9a46a
Compare
| case LPAS_SUCCESS: | ||
| self->tls_detected = TRUE; | ||
| /* this is a TLS handshake! let's switch to TLS */ | ||
| if (log_transport_stack_switch(&self->super.transport_stack, LOG_TRANSPORT_TLS)) |
There was a problem hiding this comment.
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.
I agree with that in general, however I think the syslog over TLS use-case is slightly different.
- everything is unauthenticated and plain text by default (unfortunately)
- the sensitive data is always on the client side and syslog itself is uni-directional, the server does not respond to anything
- there's no negotiation, the syslog client ultimately determines whether the syslog traffic is using TLS or not.
- the auto detection only applies to the server, not on the client
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:
- with a patch like this, it actually becomes a lot easier to deploy TLS on the clients, no need to reconfigure firewalls, load balancers or change ports on the client. You "just" configure tls() on the server on port 514 with PKI issued certificate and then you can incrementally enable the use of TLS on any of the clients, without any further configuration. Which means that you could end up with TLS encryption of log data, which is a big win.
There was a problem hiding this comment.
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.
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
bazsi
changed the title
Add TLS/haproxy auto-detection in case we have transport(auto)
With this we auto-detect: