search

processone / eturnal

STUN / TURN standalone server
https://eturnal.net
Apache License 2.0
245 stars 22 forks source link

TLS ciphers and protocols settings #6

Closed 532910 closed 2 years ago

532910 commented 4 years ago

Please add settings to control allowed TLS ciphers and protocols.

weiss commented 4 years ago

Do you have an actual use case for controlling TLS parameters manually? I'm asking because these days, TLS is not commonly used for securing TURN communication, but rather just to circumvent restrictive firewalls. The data is transmitted via UDP to the TURN peer anyway, and it's usually end-to-end encrypted. As one of my goals with eturnal is to keep it (and the documentation) as simple as possible, I'd prefer not to add configuration options just for the sake of it.

However, I'd be more open to this if we ever add support for persistent credentials, as one use case of TLS could then be to hide the TURN credentials (esp. the username) from an attacker.

That said, I'm open to be convinced of other use cases.

532910 commented 4 years ago

TLSv1 and TLSv1.1 are deprecated nowadays:

testssl turnserver:5349:

...
 TLS 1      offered (deprecated)
 TLS 1.1    offered (deprecated)
...
 Obsolete CBC ciphers (AES, ARIA etc.)         offered
...
weiss commented 4 years ago

Making a test tool happy makes sense of you have an actual reason for performing that test, and my question was whether you do 🙂

532910 commented 4 years ago

I think of testssl as a scope tool to look service configuration and reveal flaws rather than a test tool.

While security can have a lot of grades (shown with Mozilla Observatory or Qualys test) the result is binary: it is reliable or not. TLSv1 and TLSv1.1 are not reliable. rfc7525 says it SHOULD NOT be used.

To keep it simple is a good goal, but TLS versions below 1.2 must be killed.

weiss commented 3 years ago

it is reliable or not.

A given mechanism is never "secure" or "insecure" per se. Security mechanisms typically protect against some subset of possible attack vectors, which need to be defined in order to reason on whether a given mechanism seems adequate for a given use case.

TLSv1 and TLSv1.1 are not reliable.

Is UDP communication "reliable", in your view? Because as I mentioned above, relayed streams are always transmitted via UDP between TURN server and peer, without any transport encryption whatsoever.

rfc7525 says it SHOULD NOT be used.

I agree with RFC 7525's recommendations for cases where TLS is actually used for improving security (as opposed to circumventing firewalls), and I agree with the RFC's scope being "applicable to the majority of use cases".