Re: Use of TLS_FALLBACK_SCSV
On 10/17/2014 01:24 AM, Salz, Rich wrote: 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. -- Florian Weimer / Red Hat Product Security __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Use of TLS_FALLBACK_SCSV
On 10/16/2014 10:42 PM, Nou Dadoun wrote: 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. (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. -- Florian Weimer / Red Hat Product Security __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Use of TLS_FALLBACK_SCSV
Salz, Rich rs...@akamai.com: 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
Re: Use of TLS_FALLBACK_SCSV
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 From: Bodo Moeller bmoel...@acm.org To: openssl-users@openssl.org openssl-users@openssl.org Sent: Friday, October 17, 2014 4:03 AM Subject: Re: Use of TLS_FALLBACK_SCSV Salz, Rich rs...@akamai.com: 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 Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Use of TLS_FALLBACK_SCSV
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
Re: Use of TLS_FALLBACK_SCSV
On Thu, Oct 16, 2014 at 4:42 PM, Nou Dadoun ndad...@teradici.com wrote: ... 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 Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
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. -- Principal Security Engineer, Akamai Technologies IM: rs...@jabber.memailto:rs...@jabber.me Twitter: RichSalz
RE: Use of TLS_FALLBACK_SCSV
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-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Salz, Rich Sent: October-16-14 4:24 PM To: openssl-users@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. -- Principal Security Engineer, Akamai Technologies IM: rs...@jabber.memailto:rs...@jabber.me Twitter: RichSalz
