Hacker News Reader

Comment by wav-part | Hacker News Reader

> So yes, why would a client ever enable downgrade attacks - intentionally, no less - is a very, very good question.

No I meant a good client/server would never use sslv3.

> Completely future-proofing things is a losing game

I am not assumming any such thing. The moment 1.2 is known to be broken, every client/server should mark it insecure and never establish/accept 1.2 connection.

Assuming good client and good server are poodled, then no tls connection will be established.

> Defer connecting to your bank until you're no longer on your current, terrible MITMing wifi connection.

Which a good client already does without any anti-poodle fix.

I think this might be the misunderstanding: A good client/server never establish/accept insecure versions. If they get poddled, then no tls connection.

View on HN

> No I meant a good client/server would never use sslv3.

They did. They don't now, but they did.

Eventually, a good client/server will never use TLS 1.2.

My point is that it's the same situation - just at different points in time, with different protocols.

> The moment 1.2 is known to be broken, every client/server should mark it insecure and never establish/accept 1.2 connection.

That's basically what happened with SSLv3. The moment SSLv3 was known to be broken, every client/server marked it insecure and never established/accepted a SSLv3 connection again. This took the form of hotfixes, CVEs, "crisis", etc. - after all, that's just when browser devs found out it was broken. Frequently, criminals and security agencies will find out before them.

To avoid repeating the exact same history of hotfixes, CVEs, and "crisis", you can patch out 1.2 proactively - before it's "known" to be vulnerable.

But either way - proactive or reactive - we end up in a future with TLS 1.3+ and no TLS 1.2 downgrade support eventually. Does releasing 1.3 early with downgrade support help accomplish that future? The TLS and browser devs seem to think that's a distraction, and that plain old TLS 1.2 will do just fine until they can make TLS 1.3 just work, without the downgrade support.

Sure, it delays the release of "TLS 1.3" a bit, but so what? It's not delaying the release of "secure against any future TLS 1.2 exploits" - the part that actually matters from a security standpoint.

And if I'm reading the "Making TLS 1.3 work" section of the article correctly, they're already nearly ready to roll out TLS 1.3 without downgrades: A 0.2% higher success rates with "Experimental changes" (TLS 1.3 without downgrade support?) than TLS 1.2 on Chrome somehow (possibly just within the sampling error rate) and a 0.05% drop in success rate in Firefox (again possibly within the sampling error rate.)

> I think this might be the misunderstanding: A good client/server never establish/accept insecure versions. If they get poddled, then no tls connection.

We agree there - but a better client/server drops support for "secure" versions before they become known to be "insecure".

Looks like we are making case for different things.

You are arguing that everyone should update to latest version asap. Because, as you say, older version is more vulnerable. I dont think thats true, case-in-point: macos root bug. What if criminals and security agencies has broken 1.3 but not 1.2 ? Dont fix it unless its broken. Fix it when its broken or predicted to be broken.

But thats different to what I was arguing for: Some poor 1.2 implmentations aborting connection when connecting to 1.3 client, is not a problem as the article says. For complete arguments, see my previous comments here.

> But either way ... the downgrade support.

What downgrade support ? Are you saying 1.3 browsers will only connect to 1.3 ? Because there is no way every/most 1.2 servers will just transition to 1.3 together. Before 1.3 becoming 99.9%, some will be using 1.3 and some 1.2. It just cannot be avoided.

The argument is not that we should update asap. The argument is that we should not reconnect using 1.2 when 1.3 fails. There is still the normal version negotiation mechanism in TLS that would allow clients that are willing to use 1.2 when the server does not support 1.3

The issue lies with servers that do not adhere to the standard regarding version negotiation. Your proposed solution (the 'insecure fallback') is about making a client deal with this in a way that is insecure when TLS 1.2 is insecure. Our proposed solution is to change version negotiation so the faulty servers continue to work.

As you noted, 1.2 is still secure. So at this moment, we don't need 1.3 (save for the advantages like 1RTT handshakes). Thus there is no security benefit to adapting 1.3 earlier.

Now, if 1.2 ever becomes insecure, insecure fallback means MitM can force 1.2 and then attack, even if both server and client are willing and capable of using 1.3. It is true that when 1.2 is insecure, neither clients nor servers should be willing to use it. However, slow updating or 'compatibility' might see servers and clients still support it. It is those servers and clients that are vulnerable under insecure fallback. Under normal version negotiation the only weak systems are those that only support 1.2 (presuming higher versions are secure).

Thus, if 1.2 were broken, insecure fallback leaves more legacy systems vulnerable than normal version negotiation does.

In my personal opinion, non-compliant servers are broken, and we should not try to support them. But I understand how reality makes that infeasible.

By normal version negotiation if you mean rfc7507/TLS_FALLBACK_SCSV then even that wont work for legacy systems last updated before April 2015 (publish date of the rfc).

But nonetheless spec authors picked compatibility over security. I would not. Let the legacy insecure tls servers be blocked by the browsers, I say.

I get your position now. Thanks for taking the time to explain it.

> But nonetheless spec authors picked compatibility over security. I would not.

Most of the compatibility compromises don't seem to sacrifice security - except perhaps for increased attack surface, and a more complicated spec (but I'm not sure that leads to a more complicated implementation, so much as it's more thoroughly covering any downgrade dance?)

If there are more security sacrifices to achieve compatibility, I agree with you - that's bad.

Reply on news.ycombinator.com