Hacker News Reader

Comment by savara | Hacker News Reader

The page claims: "[...] insecure protocol versions and choices of algorithms are not supported, by design",

followed by:

"TLS 1.0, TLS 1.1 and TLS 1.2 are supported", "3DES/CBC encryption algorithms are supported", and "SHA-1 [is supported]"

Sad-face.

View on HN

While those algorithms all have weaknesses they are not yet completely broken and are still in wide (if declining) use. TLS 1.0 is most affected by BEAST but all modern clients have mitigations that have proven to be effective against it. The biggest issue with 3DES is its use of 64-bit blocks making it vulnerable to the SWEET32 attack, however that requires a huge amount of traffic under the same key (100s of gigabytes). SHA1 has been shown to be weak but as far as I know there are no practical attacks against it yet.

These algorithms should obviously only be used in fallback to stronger ones but they are not broken to the point where they should never be used as SSL3, RC4, and MD5 have been.

There is not supporting insecure protocols and then there is living in fantasy land away from everyone else.

You can't drop all of these things and end up with something generally useful.

Sure, I agree -- but that's not what the page claims. It says "insecure protocol versions and choices of algorithms are not supported, by design" -- the protocols and modes that I listed are known to have various insecurities, and it still supports them. I agree that to be useful it's necessary to support old, less secure or even insecure modes, but this is at odds with the above stated goal.

My point is about the imprecise description.

You're right technically but don't you think that's a little bit pedantic?

If your goal is to truly improve the state of the art in the ecosystem, dropping anything that is even remotely insecure is appealing I get that and I do believe the people behind BearSSL would love to do that. However to truly improve anything you need two things: Popularity and improve security.

There is a conflict there because popularity requires, at least some, compatibility to what already exists. You need to balance out security and compatibility. I think there is room for discussion about where precisely that balance is. You could further tilt it towards security by helping users of the library get a sense of what they need to support. Ultimately though you can't just blindly drop everything that's somehow not perfectly secure. Doing so would not improve security at all.

It's a small sacrifice to have one library be a little bit less secure than it could be, if that helps to make everything more secure it all.

This. I recently worked on updating an embedded TLS implementation from TLS 1.0 to TLS 1.2. I was told that it didn't need to implement TLS 1.0 or TLS 1.1, but once deployed we found a lot of non-HTTPS servers still using TLS 1.0. In particular, Microsoft's Hotmail/MSN SMTP servers and multiple RADIUS servers on WPA/WPA2 Enterprise networks. It now allows for client connections to TLS 1.0 servers, but will only serve TLS 1.2 itself.

Why not? TLS 1.3 is dropping those algorithms.

See how much of the Internet you can talk to if you only support TLS 1.3.

Cloud flare isn't the internet?

You kind of have to support SHA-1 still. Even with the browsers moving to deprecate it, many of the root certificates valid for another 10-20 years are still using it. (since the root certs ship with the browser, the security risk is lessened.)

If this is to be a general library that validates the entire certificate chain, then you'll need SHA-1.

Now if the library tries to advertise SHA1 in ServerHello by default, then that is indeed unfortunate.

Reply on news.ycombinator.com