Use of TLS_FALLBACK_SCSV

[Nou Dadoun]

A few short (simple) questions about the use of TLS_FALLBACK_SCSV since we’re currently upgrading to the latest openssl releases.

We don’t establish sessions with any other products than our own clients and servers.

We’ve already disabled the use of SSLv3 in both our client and server releases going forward, is there any advantage in also using TLS_FALLBACK_SCSV – i.e. will there be any benefit in connecting to our already deployed clients and servers?

(I actually don’t think that we’re vulnerable to POODLE since we don’t use anything like encrypted cookies or repeated messages that could be used to exploit padding changes to “peel off” decoded chunks. Is there any other mechanism to exploit this would make us vulnerable?)

Where in the session establishment is TLS_FALLBACK_SCSV used and how would we incorporate it?

I think a lot of folks will probably have these or similar questions, is there a FAQ somewhere to address this?


Thanks in advance 
 N

[Jeffrey Walton]

...
We’ve already disabled the use of SSLv3 in both our client and server
releases going forward, is there any advantage in also using
TLS_FALLBACK_SCSV – i.e. will there be any benefit in connecting to our
already deployed clients and servers?

I can only help with this question. See Salz's answer at
http://groups.google.com/d/msg/mailing.openssl.users/GTUVm-nFz2o/sxyB2bG3ZjwJ

Jeff
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users-MCmKBN63+***@public.gmane.org
Automated List Manager majordomo-MCmKBN63+***@public.gmane.org

[Salz, Rich]

It does not matter who you talk to. With a POODLE attack, your content can be decrypted. Cookies, etc., were just used as an example.

Disabling ssl3 is a good thing. But set the fallback because silently dropping from tls 1.2 to tls 1.1 is bad. It’s done during the handshake process as part of the cipher negotiation.

[Nou Dadoun]

But my understanding is that it requires the same content to be submitted repeatedly within a single session with manipulations to the padding to incrementally decrypt the content; we use ssl to protect our session establishment - think of a SIP call, SIP INVITE (offer) in one direction and SIP ACK (accept/refuse) in the other to establish session parameters and then the ssl connection is torn down and a different (non-ssl) encryption mechanism is used to protect the actual media stream. Any attempt to retransmit either INVITE or ACK will abort the session and in any case, no further sensitive material is sent subsequently to the ACK in the ssl session (there’s the equivalent of a BYE/BYE ACK).

We plan to disable sslv3 anyway because we want to avoid being at risk in the future (and you point out a good argument for disabling the fallback in general) but within our controlled scenario, I don’t think we’re vulnerable to a POODLE attack unless there’s something I’m missing 
 N

From: owner-openssl-***@openssl.org [mailto:owner-openssl-***@openssl.org] On Behalf Of Salz, Rich
Sent: October-16-14 4:24 PM
To: openssl-***@openssl.org
Subject: RE: Use of TLS_FALLBACK_SCSV

It does not matter who you talk to. With a POODLE attack, your content can be decrypted. Cookies, etc., were just used as an example.

Disabling ssl3 is a good thing. But set the fallback because silently dropping from tls 1.2 to tls 1.1 is bad. It’s done during the handshake process as part of the cipher negotiation.

[Florian Weimer]

Post by Salz, Rich
It does not matter who you talk to. With a POODLE attack, your content
can be decrypted. Cookies, etc., were just used as an example.

If OpenSSL talks to OpenSSL, and both ends have been set up with the
SSLv23_method, and SSL_CTX_set_options has not been used to disable all
TLS versions, then SSL 3.0 will never be negotiated, and attacks on SSL
3.0 are a non-issue. Even if you do not use TLS_FALLBACK_SCSV at all,
or OpenSSL versions which do not support it.

So it does matter who you talk to.

[Bodo Moeller]

Salz, Rich <rsalz-JqFfY2XvxFXQT0dZR+***@public.gmane.org>:

Disabling ssl3 is a good thing. But set the fallback because silently

Post by Salz, Rich
dropping from tls 1.2 to tls 1.1 is bad.

All this assumes that your client application *does* explicitly fall back
from TLS 1.2 to TLS 1.1, instead of just relying on automatic protocol
version negotiation. If you never do that (and I suspect you don't), your
client has no need for TLS_FALLBACK_SCSV. Do NOT set this, except for
fallback connections that downgrade the protocol version.

Bodo

[n***@public.gmane.org]

Thank you, Bodo.

This is a crucial point that was not clear to me when I was investigating the use of TLS_FALLBACK_SCSV the first time.

If my application uses SSLv23_method() when constructing the SSL context, and then explicitly disables SSLv2 and SSLv3 using SSL_CTX_set_options(), then OpenSSL will do "automatic protocols negotiation" and I don't need to also use TLS_FALLBACK_SCSV.

Did I get it this time?

Geoff

Post by Jeffrey Walton
________________________________
Sent: Friday, October 17, 2014 4:03 AM
Subject: Re: Use of TLS_FALLBACK_SCSV
Disabling ssl3 is a good thing. But set the fallback because silently dropping from tls 1.2 to tls 1.1 is bad.
All this assumes that your client application *does* explicitly fall back from TLS 1.2 to TLS 1.1, instead of just relying on automatic protocol version negotiation. If you never do that (and I suspect you don't), your client has no need for TLS_FALLBACK_SCSV. Do NOT set this, except for fallback connections that downgrade the protocol version.
Bodo

______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users-MCmKBN63+***@public.gmane.org
Automated List Manager majordomo-MCmKBN63+***@public.gmane.org

[Florian Weimer]

Post by Nou Dadoun
A few short (simple) questions about the use of TLS_FALLBACK_SCSV since
we’re currently upgrading to the latest openssl releases.
We don’t establish sessions with any other products than our own clients
and servers.
We’ve already disabled the use of SSLv3 in both our client and server
releases going forward, is there any advantage in also using
TLS_FALLBACK_SCSV – i.e. will there be any benefit in connecting to our
already deployed clients and servers?

No, there is no benefit from TLS_FALLBACK_SCSV in this context. It only
helps clients which bypass the TLS downgrade protection, clients which
explicitly disable newer protocol versions which contain the fixes for
vulnerabilities discovered in SSL 3.0.

Post by Nou Dadoun
(I actually don’t think that we’re vulnerable to POODLE since we don’t
use anything like encrypted cookies or repeated messages that could be
used to exploit padding changes to “peel off” decoded chunks. Is there
any other mechanism to exploit this would make us vulnerable?)

You are not vulnerable because SSL 3.0 has been fixed years ago, and
OpenSSL automatically applies the relevant protocol fixes (unless you
have told the library not to do this). For technical reasons, the
protocol version number had to be bumped (this is just the way you fix
broken protocols), and for non-technical reasons, we call these protocol
fixes TLS 1.0, 1.1, 1.2 instead of SSL 3.1, 3.2, 3.3.