Add timeout for TLS handshakes

[fuzzypixelz]

After establishing a TCP connections, the TLS link waits for the TLS handshake to complete in rustls. If the TLS handshake never takes place, then the TLS link waits forever and no one else can establish a Zenoh session. It is thus possible to block a router with a TLS on tls/127.0.0.1:7447 listener from servicing any incoming connections with the following:

fn main() {
    let _stream = TcpStream::connect("127.0.0.1:7447")?;
    thread::park();
}

[gabrik]

should this be configurable?

[gabrik]

I'm thinking if we should also spawn a task on accept, or have a task pool where we sent the accepted socket before waiting for the the TLS handshake to complete.

[fuzzypixelz]

I'm thinking if we should also spawn a task on accept, or have a task pool where we sent the accepted socket before waiting for the the TLS handshake to complete.

Yes, this is effectively what the tls-listener crate does.

We should be careful as tls-listener has had CVE-2024-28854 where it was vulnerable to a slow-loris DoS attack.

[gabrik]

I think we need to add a key in order to make the timeout configurable, see: https://github.com/eclipse-zenoh/zenoh/blob/tls-handshake-timeout/io/zenoh-links/zenoh-link-tls/src/lib.rs#L88

[fuzzypixelz]

I think we need to add a key in order to make the timeout configurable, see: https://github.com/eclipse-zenoh/zenoh/blob/tls-handshake-timeout/io/zenoh-links/zenoh-link-tls/src/lib.rs#L88

Those keys are for runtime configuration, but TLS_HANDSHAKE_TIMEOUT_MS is a compile-time constant. Maybe we should make this runtime-configurable.

[gabrik]

Those keys are for runtime configuration, but TLS_HANDSHAKE_TIMEOUT_MS is a compile-time constant. Maybe we should make this runtime-configurable.

I think it must be runtime-configurable as the timeout depends the deployment