6 ms·

I dont get the crisis. If 3% disconnect with 1.3, then retry again with secure 1.2. Its only a performence penalty for those 3%. Its obviously less than lets-ta

I dont get the crisis. If 3% disconnect with 1.3, then retry again with secure 1.2. Its only a performence penalty for those 3%. Its obviously less than lets-talk-about-it penalty.

jve 9y ago
Except it is INSECURE: > However, insecure downgrades are called insecure for a reason. Client downgrades are triggered by a specific type of network failure, one that can be easily spoofed. From the client’s perspective, there’s no way to tell if this failure was caused by a faulty server or by an attacker who happens to be on the path of the connection network. This means that network attackers can inject fake network failures and trick a client into connecting to a server with SSLv3, even if both support a newer protocol. At this point, there were no severe publicly-known vulnerabilities in SSLv3, so this didn’t seem like a big problem. Then POODLE happened.
- wav-part 9y ago
  Ofcourse CL should never downgrade to non-secure versions. SSLv3 is discouraged so CL wont try this. But 1.2 still ok.
  - majewsky 9y ago
    That's what they said about SSL 3 some time ago.
    - wav-part 9y ago
      If a client and server both dont upgrade to secure version and still use old now-broken version, there is nothing to be done. This thread is just now getting repeatitive.
  - syncsynchalt 9y ago
    TLS 1.2 is insecure. Prove me wrong. So I guess we can't downgrade to it, and we should make 1.3 work without re-negotiation.
MaulingMonkey 9y ago
The article calls this "insecure downgrade" - which is not just the performance penalty you say it is, it's also a security penalty that's been previously (ab)used via POODLE. It's also code that's been removed and would need re-implementing, re-testing, etc. The only crisis the article mentions - in passing at that - is when they tried to roll out 1.3 initially and things broke outright at alarmingly high rates. Whoever wrote the article appears to be a fan of discussing things before they turn into crisises.
- wav-part 9y ago
  Hows downgrading to _secure 1.2_ insecure ? Regarding sslv3, why would client ever use it, downgrade/POODLE or not ? This is literally very simple, few lines of patch. Its basically tls server discovery. Its a crisis when a upgrade makes 3% webservers stop working.
  - rocqua 9y ago
    It means anyone with a MitM position gets to decide you don't have TLS 1.3 . At that point, why even have TLS 1.3? It's not protecting you anymore than TLS 1.2 is.
    - wav-part 9y ago
      > It means anyone with a MitM position gets to decide you don't have TLS 1.3. So what ? 1.2 is not weak. Connection is still secure. 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.
      - MaulingMonkey 9y ago
        > 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.
mkonecny 9y ago
This is exactly with what happened with Poodle and SSLv3 and it's in the article. Attackers were successfully downgrading to the vulnerable SSL when a TLS connection was attempted. In the future when TLS1.2 is considered insecure, we do not want this workaround in place.

I dont get the crisis. If 3% disconnect with 1.3, then retry again with secure 1.2. Its only a performence penalty for those 3%. Its obviously less than lets-talk-about-it penalty.

jve 9y ago

Except it is INSECURE: > However, insecure downgrades are called insecure for a reason. Client downgrades are triggered by a specific type of network failure, one that can be easily spoofed. From the client’s perspective, there’s no way to tell if this failure was caused by a faulty server or by an attacker who happens to be on the path of the connection network. This means that network attackers can inject fake network failures and trick a client into connecting to a server with SSLv3, even if both support a newer protocol. At this point, there were no severe publicly-known vulnerabilities in SSLv3, so this didn’t seem like a big problem. Then POODLE happened.

wav-part 9y ago
Ofcourse CL should never downgrade to non-secure versions. SSLv3 is discouraged so CL wont try this. But 1.2 still ok.
- majewsky 9y ago
  That's what they said about SSL 3 some time ago.
  - wav-part 9y ago
    If a client and server both dont upgrade to secure version and still use old now-broken version, there is nothing to be done. This thread is just now getting repeatitive.
- syncsynchalt 9y ago
  TLS 1.2 is insecure. Prove me wrong. So I guess we can't downgrade to it, and we should make 1.3 work without re-negotiation.

MaulingMonkey 9y ago

The article calls this "insecure downgrade" - which is not just the performance penalty you say it is, it's also a security penalty that's been previously (ab)used via POODLE. It's also code that's been removed and would need re-implementing, re-testing, etc. The only crisis the article mentions - in passing at that - is when they tried to roll out 1.3 initially and things broke outright at alarmingly high rates. Whoever wrote the article appears to be a fan of discussing things before they turn into crisises.

wav-part 9y ago
Hows downgrading to _secure 1.2_ insecure ? Regarding sslv3, why would client ever use it, downgrade/POODLE or not ? This is literally very simple, few lines of patch. Its basically tls server discovery. Its a crisis when a upgrade makes 3% webservers stop working.
- rocqua 9y ago
  It means anyone with a MitM position gets to decide you don't have TLS 1.3 . At that point, why even have TLS 1.3? It's not protecting you anymore than TLS 1.2 is.
  - wav-part 9y ago
    > It means anyone with a MitM position gets to decide you don't have TLS 1.3. So what ? 1.2 is not weak. Connection is still secure. 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.
    - MaulingMonkey 9y ago
      > 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.

mkonecny 9y ago

This is exactly with what happened with Poodle and SSLv3 and it's in the article. Attackers were successfully downgrading to the vulnerable SSL when a TLS connection was attempted. In the future when TLS1.2 is considered insecure, we do not want this workaround in place.