4 ms·

> Hows downgrading to _secure 1.2_ insecure ? I could go back a few years and ask you the same question: "Hows downgrading to secure SSLv3 insecure ?" You co

> Hows downgrading to _secure 1.2_ insecure ? I could go back a few years and ask you the same question: "Hows downgrading to secure SSLv3 insecure ?" You could say "it wasn't", and then you could suddenly be facing a bunch of CVEs and a cute acronym. What makes 1.2 so special that truly, this time, there won't ever be any problems found with it? Especially when enough potential problems were found to motivate TLS 1.3? > Regarding sslv3, why would client ever use it, downgrade/POODLE or not ? At the time, downgrade attacks specifically forced SSLv3. So yes, why would a client ever enable downgrade attacks - intentionally, no less - is a very, very good question. Of course, we're only talking about downgrading to 1.2 these days - but we've already had the history to show us why downgrades are a bad idea, so why repeat that history? > So what ? 1.2 is not weak. Connection is still secure. For now. So was SSLv3, until it wasn't. At the bare minimum, it's a larger attack surface of extremely security sensitive code - which is worrying in it's own right - and an intentionally written security vulnerability which, while "not weak" today, may become weak or even exploitable in the future. Completely future-proofing things is a losing game, of course, but seeing as insecure downgrade moots the point of 1.3 - strengthening security - it seems reasonable to try and figure out how to do things right "now" - or failing that, "before it becomes a crisis." > Also MITM still gets to decide whether to have tls or not. Then "Why even have tls ?". If MITM is blocking a protocol (or higher version, which is equivalent), then there is nothing to be done. Does your browser automatically downgrade HTTPS to HTTP if the former fails? I hope not! Connections failing when MITMed by unknown third parties is a feature when you're logging in to your bank. This single feature is basically the entire point of TLS, HTTPS, and the entire CA infrastructure. That's "why even have TLS". There is something to be done: Defer connecting to your bank until you're no longer on your current, terrible MITMing wifi connection. Maybe pick one of the other 20 hotspots on your connection list. As currently implemented, this requires some minor, manual intervention, on the part of the user. TLS 1.3 with insecure downgrade accomplishes this no more effectively than 1.2. It's a waste of bits. It's why insecure downgrade to SSLv3 is gone - it was mooting the entire point of TLS.

wav-part 9y ago
> 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.
- MaulingMonkey 9y ago
  > 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".

wav-part 9y ago

> 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.

MaulingMonkey 9y ago
> 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".