5 ms·

It's not a way to fall back, it's a way to detect fallback and prevent downgrade attacks. https://tools.ietf.org/html/draft-ietf-tls-downgrade-scsv-05 https://

It's not a way to fall back, it's a way to detect fallback and prevent downgrade attacks. https://tools.ietf.org/html/draft-ietf-tls-downgrade-scsv-05 https://tools.ietf.org/html/draft-ietf-tls-downgrade-scsv-05 A client sends a ClientHello trying to connect with TLS 1.2, MITM does not let that through, the client sends a ClientHello for TLS 1.0 with a signal that means "this is a fallback", the MITM lets that through, the server sees this and does not allow a connection, foiling the attempted downgrade attack. I know that, that's why I asked: "Why is SCSV a sucky feature?".

smhenderson 12y ago
OK, my bad, I just checked the RFC[1] and reading it agrees absolutely with what you are saying. I am probably misunderstanding the thread I linked to in my OP but reading through it (I remembered seeing this a while ago when I read your question) I got the impression that the LibreSSL guys looked at it from the opposite angle. From my link: TLS_FALLBACK_SCSV is only useful in the case where a client willingly chooses to do a downgrade and attempts to establish a second connection at a lower protocol after the previous one unexpectedly failed. In short, the client should not do this - client-side fallback is dangerous ("a landmine" to quote agl). TLS_FALLBACK_SCSV only works if both ends support it and it is largely a case of adding a workaround to support/enforce insecure behaviour. Unless you control both ends, you cannot be sure TLS_FALLBACK_SCSV is available and if you do control both ends you can either force TLS 1.2 and/or avoid client-side downgrade. And the final reply: Server-side TLS_FALLBACK_SCSV support has reluctantly been added to LibreSSL. I guess in the end the reluctance is more about it being new and untested and not so much a bad security practice. [1] https://tools.ietf.org/html/draft-ietf-tls-downgrade-scsv-00 https://tools.ietf.org/html/draft-ietf-tls-downgrade-scsv-00

smhenderson 12y ago

OK, my bad, I just checked the RFC[1] and reading it agrees absolutely with what you are saying. I am probably misunderstanding the thread I linked to in my OP but reading through it (I remembered seeing this a while ago when I read your question) I got the impression that the LibreSSL guys looked at it from the opposite angle. From my link: TLS_FALLBACK_SCSV is only useful in the case where a client willingly chooses to do a downgrade and attempts to establish a second connection at a lower protocol after the previous one unexpectedly failed. In short, the client should not do this - client-side fallback is dangerous ("a landmine" to quote agl). TLS_FALLBACK_SCSV only works if both ends support it and it is largely a case of adding a workaround to support/enforce insecure behaviour. Unless you control both ends, you cannot be sure TLS_FALLBACK_SCSV is available and if you do control both ends you can either force TLS 1.2 and/or avoid client-side downgrade. And the final reply: Server-side TLS_FALLBACK_SCSV support has reluctantly been added to LibreSSL. I guess in the end the reluctance is more about it being new and untested and not so much a bad security practice. [1] https://tools.ietf.org/html/draft-ietf-tls-downgrade-scsv-00 https://tools.ietf.org/html/draft-ietf-tls-downgrade-scsv-00