Fix TLS connection closure (source side)#2811
Conversation
|
Build SUCCESS |
|
@kira-syslogng retest this please |
|
Build FAILURE |
|
@kira-syslogng retest this please |
|
@kira-syslogng do perftest |
|
Build SUCCESS |
|
Kira-performance-test: Build SUCCESS |
|
Could you please resolve the conflict? If the source side is working, although the PR itself is incomplete, I think it would be nice to merge at least that part. The issue was raised for the source side. We can still open a new issue for the destination though. |
|
Build FAILURE |
|
Kira-performance-test: Build FAILURE |
|
@furiel Good idea. I'll remove the WIP flag after running some internal tests. |
|
@kira-syslogng do perftest |
|
Build SUCCESS |
|
Kira-performance-test: Build SUCCESS |
|
Build SUCCESS |
|
Build SUCCESS |
|
Build SUCCESS |
|
Build SUCCESS |
lbudai
left a comment
There was a problem hiding this comment.
Nice fix.
I have only one comment - if you won't have the time to resolve it, I'm okay with merge this as-is.
lib/transport/transport-tls.c
Outdated
There was a problem hiding this comment.
I'd factor out this part of the function (as this part does not modify the return value, it would be more readable).
There was a problem hiding this comment.
Extracted, thanks.
The method name might not be the best.
|
Build FAILURE |
Signed-off-by: László Várady <laszlo.varady@protonmail.com>
LogTransportTLS is a LogTransportSocket specialization, for example, it should also call shutdown() before destroying the transport. Signed-off-by: László Várady <laszlo.varady@protonmail.com>
cond = 0 means LogTransport users (LogProtos) can set the direction freely, therefore it should be reset in case of a successful read. Signed-off-by: László Várady <laszlo.varady@protonmail.com>
OpenSSL (>= 1.0.2) does not differentiate between zero and negative return values anymore (see docs). SSL_ERROR_ZERO_RETURN should be checked to detect a connection close. Signed-off-by: László Várady <laszlo.varady@protonmail.com>
RFC 5425: Once the transport receiver gets a close_notify from the transport sender, it MUST reply with a close_notify unless it becomes aware that the connection has already been closed by the transport sender. SSL_shutdown() is responsible for sending close_notify shutdown alerts. This fixes the source side. Destinations (senders) have to be fixed as well. Signed-off-by: László Várady <laszlo.varady@protonmail.com>
Signed-off-by: László Várady <laszlo.varady@protonmail.com>
Signed-off-by: László Várady <laszlo.varady@protonmail.com>
|
Build SUCCESS |
|
@MrAnno : thanks. |
This entry is from the previous release. Signed-off-by: László Várady <laszlo.varady@protonmail.com>
This pull request fixes the TLS connection closure on the source (receiver) side by sending back close_notify alerts.
RFC5425:
TODO:
Implementing this on the destination side is more complicated, we might need to introduce
log_proto_client_shutdown() -> log_transport_shutdown()becauseSSL_shutdown()requires non-blocking write operations, so fd watches should be registered during shutdown. Currently, we destroy/shutdown transports after stopping watches and deinitingLogWriter. Another tricky part islog_writer_reopen_deferred().Fixes #2703