5 ms·

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 o

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.
    - 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".
  - rocqua 9y ago
    HSTS was created specifically to prevent the MITM from downgrading HTTPS to HTTP. As for MITM blocking a protocol, that is a noticeable situation, and one that does not give the attacker any control over the cryptography used on sensitive data. A downgrade attack is very different from blocking a protocol. The user doesn't notice, and the attacker gains some control over the cryptography used. In the end, what sense does it make to have a TLS version an attacker can opt out of? All you get is defence against passive MitM. Until we aren't safe against those passive MitM with TLS 1.2 it makes no sense to rush TLS 1.3. Especially because that rush would really hurt when it turns our TLS 1.2 is insecure, at which point the rushed solution becomes vulnerable to all active MitM attacks. Now consider, what level of access to infrastructure only allows for passive MitM?
    - wav-part 9y ago
      > The user doesn't notice, and the attacker gains some control over the cryptography used. In my case user will because the tls client wont accept insecure version request. Connection broken. Client will notify the user of server still using a insecure version. I think this might be the misunderstanding: A good client/server never establish/accept insecure versions. Yes MITM gets to pick but if he picks insecure version, there is no connection. POODLE was never attack on the protocol but poor implementations.
      - syncsynchalt 9y ago
        One misunderstanding is that you are accepting as fact that TLS 1.2 is secure, when it's entirely plausible that one or more state actors already know that not to be the case. There's no magic light that goes on when the NSA breaks TLS 1.2 so that we know to stop trusting it.

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.
  - 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".
- rocqua 9y ago
  HSTS was created specifically to prevent the MITM from downgrading HTTPS to HTTP. As for MITM blocking a protocol, that is a noticeable situation, and one that does not give the attacker any control over the cryptography used on sensitive data. A downgrade attack is very different from blocking a protocol. The user doesn't notice, and the attacker gains some control over the cryptography used. In the end, what sense does it make to have a TLS version an attacker can opt out of? All you get is defence against passive MitM. Until we aren't safe against those passive MitM with TLS 1.2 it makes no sense to rush TLS 1.3. Especially because that rush would really hurt when it turns our TLS 1.2 is insecure, at which point the rushed solution becomes vulnerable to all active MitM attacks. Now consider, what level of access to infrastructure only allows for passive MitM?
  - wav-part 9y ago
    > The user doesn't notice, and the attacker gains some control over the cryptography used. In my case user will because the tls client wont accept insecure version request. Connection broken. Client will notify the user of server still using a insecure version. I think this might be the misunderstanding: A good client/server never establish/accept insecure versions. Yes MITM gets to pick but if he picks insecure version, there is no connection. POODLE was never attack on the protocol but poor implementations.
    - syncsynchalt 9y ago
      One misunderstanding is that you are accepting as fact that TLS 1.2 is secure, when it's entirely plausible that one or more state actors already know that not to be the case. There's no magic light that goes on when the NSA breaks TLS 1.2 so that we know to stop trusting it.