Re: Use of TLS_FALLBACK_SCSV

2014-10-17 Thread Florian Weimer

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

2014-10-17 Thread Florian Weimer

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

2014-10-17 Thread Bodo Moeller
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

2014-10-17 Thread no_spam_98
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


Re: Use of TLS_FALLBACK_SCSV

2014-10-16 Thread Jeffrey Walton
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

2014-10-16 Thread 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.

--
Principal Security Engineer, Akamai Technologies
IM: rs...@jabber.memailto:rs...@jabber.me Twitter: RichSalz


RE: Use of TLS_FALLBACK_SCSV

2014-10-16 Thread 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-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