Rationale for TLS restrictions?

Development
1

I’m working on an app for Chrome OS to connect to Syncthing from my Chromebook laptop, but I’ve run a small bump. Because the Chrome API does not provide control over the certs used for secure connections, I have to use the library Forge for the TLS implementation. The only problem is, Forge currently only supports TLS up to version 1.1, but for BEP the spec says:

The encryption and authentication layer SHALL use TLS 1.2 or a higher revision.

I’m wondering what the reasoning is behind this restriction. I can understand not wanting to support versions with known weaknesses, but of the published guidelines I could find, all recommended supporting TLS 1.1 for compatibility alongside TLS 1.2 and up. Examples include OWASP:

Rule - Only Support Strong Protocols

SSL/TLS is a collection of protocols. Weaknesses have been identified with earlier SSL protocols, including SSLv2 and SSLv3. The best practice for transport layer protection is to only provide support for the TLS protocols - TLS1.0, TLS 1.1 and TLS 1.2. … You should provide support for TLS 1.1 and TLS 1.2 to accommodate clients which support the protocols. … TLSv1.0 should only be used only after risk analysis and acceptance.

Also Mozilla:

Modern compatibility

For services that don’t need backward compatibility, the parameters below provide a higher level of security. … Versions: TLSv1.1, TLSv1.2

And NIST:

3.1 Protocol Version Support

TLS version 1.1 is required, at a minimum, in order to mitigate various attacks on version 1.0 of the TLS protocol. Support for TLS version 1.2 is strongly recommended. Servers that support government-only applications shall be configured to support TLS 1.1, and should be configured to support TLS 1.2.

Is the only reason the spec requires TLS 1.2 an overabundance of caution? (I realize @calmh is on vacation currently, and maybe he’s the only who can answer this…) I’m not a security expert by any means, but it seems to me that the user should have the option of using TLS 1.1 for compatibility, especially since the connection will negotiate to use TLS 1.2 anyway if both endpoints support it. Thoughts?

1 Like
2

Sadly, I don’t know the answer, but I feel that Go stdlib only implements 1.2

Edit: Actually I talking crap. It does support TLS 1.1

3

See https://github.com/syncthing/syncthing/issues/23

4

Thanks, that helps explain the background I was missing. I guess I’m still a bit surprised that more stringent requirements take precedence over wider compatibility, given that interoperability is part of the main project goals when it says:

It is the hope that alternative, compatible implementations of the protocol will come to exist.

If absolute security is the priority in this case, I definitely understand. But it does make it quite a bit harder to create an “alternative, compatible implementation” in my case though. :wink:

5

My “vote”, such as it is, would be for TLS 1.2 only. The SSL dominoes seem to be falling quite a bit at the moment, and I don’t think opening up syncthing to various potential downgrade attacks or other platforms’ poor TLS 1.1 implementations would be sensible. Forge will catch up, I’m sure.

1 Like