Discussion:
SSL_MODE_SEND_FALLBACK_SCSV option
Aditya Kumar
2014-10-20 10:50:47 UTC
Permalink
Hi All,

I have a question regarding SSL_MODE_SEND_FALLBACK_SCSV introduced in
OpenSSL 0.9.8zc as part of a preventive measure for SSL 3.0 POODLE
vulnerability.

I have client and server applications using OpenSSL for SSL/TLS
communication. My question is that what will happen if I update my client
applications with this OpenSSL patch( and also set
SSL_MODE_SEND_FALLBACK_SCSV) and the Server Applications are NOT updated
with the patch? The questions are:

1. Will this updated client set with TLS_FALLBACK will be able to work with
un-updated Server(server using older version of OpenSSL where this FALLBACK
mode is not set)?
2. Is it a good idea to hard code this option permanently in application or
should I give this as a configuration option to the user? I am asking this
as my client application may require to communicate with old Servers not
having this fix.

I understand that the vulnerability will remain if both the client and
server are not having the fix and they are using SSL V3. Still i want to
understand the risk before updating my application so that nothing breaks
with my application while fixing this vulnerability.

I appreciate your continuous support to OpenSSL community.

Regards,
Aditya
Florian Weimer
2014-10-20 11:46:29 UTC
Permalink
Post by Aditya Kumar
1. Will this updated client set with TLS_FALLBACK will be able to work
with un-updated Server(server using older version of OpenSSL where this
FALLBACK mode is not set)?
No, the behavior of existing OpenSSL applications will not change.
OpenSSL will signal TLS_FALLBACK_SCSV only if explicitly requested by
the application. Most applications will not want to do this.
Post by Aditya Kumar
2. Is it a good idea to hard code this option permanently in application
or should I give this as a configuration option to the user? I am asking
this as my client application may require to communicate with old
Servers not having this fix.
How do you select the protocol version? If you use SSLv23_method with
a constant set of options (which should include SSL_OP_NO_SSLv2 at
least), then there is no need to set SSL_MODE_SEND_FALLBACK_SCSV, ever.
OpenSSL will do the right thing automatically.

Unconditionally setting SSL_MODE_SEND_FALLBACK_SCSV (if by default or
after user configuration) is a time bomb—your client application will
break once the server implements TLS 1.3 (or any newer TLS version than
what is supported by the OpenSSL version you use). Extremely few
applications have to deal with SSL_MODE_SEND_FALLBACK_SCSV.
--
Florian Weimer / Red Hat Product Security
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users-MCmKBN63+***@public.gmane.org
Automated List Manager majordomo-MCmKBN63+***@public.gmane.org
Nou Dadoun
2014-10-20 17:08:12 UTC
Permalink
This is the first time I've seen this point of view expressed but it does make evident sense - after all, the whole idea of falling back is to find a mutually acceptable version. However it conflicts with some of the previous advice I've seen on the list which recommended that SSL_MODE_SEND_FALLBACK_SCSV *always* be set to prevent downgrade from v1.1 to v1.2 for example. Any consensus? ... N

-----Original Message-----
...
Unconditionally setting SSL_MODE_SEND_FALLBACK_SCSV (if by default or after user configuration) is a time bomb-your client application will break once the server implements TLS 1.3 (or any newer TLS version than what is supported by the OpenSSL version you use). Extremely few applications have to deal with SSL_MODE_SEND_FALLBACK_SCSV.
--
Florian Weimer / Red Hat Product Security
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users-MCmKBN63+***@public.gmane.org
Automated List Manager majordomo-MCmKBN63+***@public.gmane.org
______________________________________________________________________
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
2014-10-20 18:49:09 UTC
Permalink
When I said "always" I meant "always when you fall back"

I was being too terse and not clear enough.

Hope this helps.

--
Principal Security Engineer, Akamai Technologies
Post by Nou Dadoun
-----Original Message-----
Sent: Monday, October 20, 2014 7:08 PM
Subject: RE: SSL_MODE_SEND_FALLBACK_SCSV option
This is the first time I've seen this point of view expressed but it does make
evident sense - after all, the whole idea of falling back is to find a mutually
acceptable version. However it conflicts with some of the previous advice
I've seen on the list which recommended that
SSL_MODE_SEND_FALLBACK_SCSV *always* be set to prevent downgrade
from v1.1 to v1.2 for example. Any consensus? ... N
-----Original Message-----
...
Unconditionally setting SSL_MODE_SEND_FALLBACK_SCSV (if by default or
after user configuration) is a time bomb-your client application will break
once the server implements TLS 1.3 (or any newer TLS version than what is
supported by the OpenSSL version you use). Extremely few applications
have to deal with SSL_MODE_SEND_FALLBACK_SCSV.
--
Florian Weimer / Red Hat Product Security
__________________________________________________________
____________
OpenSSL Project http://www.openssl.org
__________________________________________________________
____________
OpenSSL Project http://www.openssl.org
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users-MCmKBN63+***@public.gmane.org
Automated List Manager majordomo-MCmKBN63+***@public.gmane.org
Nou Dadoun
2014-10-20 20:10:53 UTC
Permalink
Well I think I'm completely confused about this option now; "always when you fall back" seems to suggest that falling back is an application level operation (as opposed to openssl-implemented behaviour), is it? i.e. is the onus on the client application to retry with a lower version if it wants to? What then is the purpose of the option?



Maybe the following would clarify it - is there code in the new release of openssl to recognize and act on this new option (other than simply sending the option down the wire to be handled by application code)?

Is there a simple example of a scenario where it would be used?


Is there documentation anywhere that describes how "fall back" is performed?

Thanks ... N




-----Original Message-----
From: owner-openssl-users-MCmKBN63+***@public.gmane.org [mailto:owner-openssl-***@openssl.org] On Behalf Of Salz, Rich
Sent: October-20-14 11:49 AM
To: openssl-users-MCmKBN63+***@public.gmane.org
Subject: RE: SSL_MODE_SEND_FALLBACK_SCSV option

When I said "always" I meant "always when you fall back"

I was being too terse and not clear enough.

Hope this helps.

--
Principal Security Engineer, Akamai Technologies
Post by Nou Dadoun
-----Original Message-----
Sent: Monday, October 20, 2014 7:08 PM
Subject: RE: SSL_MODE_SEND_FALLBACK_SCSV option
This is the first time I've seen this point of view expressed but it
does make evident sense - after all, the whole idea of falling back is
to find a mutually acceptable version. However it conflicts with some
of the previous advice I've seen on the list which recommended that
SSL_MODE_SEND_FALLBACK_SCSV *always* be set to prevent downgrade from
v1.1 to v1.2 for example. Any consensus? ... N
-----Original Message-----
...
Unconditionally setting SSL_MODE_SEND_FALLBACK_SCSV (if by default or
after user configuration) is a time bomb-your client application will
break once the server implements TLS 1.3 (or any newer TLS version
than what is supported by the OpenSSL version you use). Extremely few
applications have to deal with SSL_MODE_SEND_FALLBACK_SCSV.
--
Florian Weimer / Red Hat Product Security
__________________________________________________________
____________
OpenSSL Project http://www.openssl.org
__________________________________________________________
____________
OpenSSL Project http://www.openssl.org
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users-MCmKBN63+***@public.gmane.org
Automated List Manager majordomo-MCmKBN63+***@public.gmane.org
______________________________________________________________________
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
2014-10-20 20:20:35 UTC
Permalink
Post by Nou Dadoun
Well I think I'm completely confused about this option now; "always when
you fall back" seems to suggest that falling back is an application level
operation (as opposed to openssl-implemented behaviour), is it? i.e. is the
onus on the client application to retry with a lower version if it wants to?
What then is the purpose of the option?
Yes it is completely a client application issued.

The purpose is for the client to tell the server "I tried TLS and that failed and now I'm using SSLv3" (or whatever versions it ends up using).
Post by Nou Dadoun
Is there a simple example of a scenario where it would be used?
SSL_new
SLS_connect
...connection failed
Ssl_new
Set fallback flag
Ssl_connect



______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users-MCmKBN63+***@public.gmane.org
Automated List Manager majordomo-MCmKBN63+***@public.gmane.org
Matt Caswell
2014-10-20 20:40:25 UTC
Permalink
This post might be inappropriate. Click to display it.
Nou Dadoun
2014-10-20 22:54:35 UTC
Permalink
This post might be inappropriate. Click to display it.
Florian Weimer
2014-10-21 05:50:58 UTC
Permalink
Post by Nou Dadoun
Well I think I'm completely confused about this option now; "always when you fall back" seems to suggest that falling back is an application level operation (as opposed to openssl-implemented behaviour), is it? i.e. is the onus on the client application to retry with a lower version if it wants to? What then is the purpose of the option?
Correct, fallback (in this sense) is performed by the application. In
contrast, OpenSSL automatically upgrades away from SSL 3.0 (unless
prevent from doing so), in a way that is secure against
man-in-the-middle attacks.

The purpose of the option is to make totally broken applications a bit
less secure (when they happen to certain servers). From my point of
view, there is only one really good reason to have this client-side
option—so that you can test the server-side support. That's why I
implemented it for OpenJDK as well. Application should *never* use it
because it does not really solve anything. If you have fallback code,
your application is still insecure.
--
Florian Weimer / Red Hat Product Security
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users-MCmKBN63+***@public.gmane.org
Automated List Manager majordomo-MCmKBN63+***@public.gmane.org
Jakob Bohm
2014-10-21 09:47:25 UTC
Permalink
Post by Florian Weimer
Post by Nou Dadoun
Well I think I'm completely confused about this option now; "always
when you fall back" seems to suggest that falling back is an
application level operation (as opposed to openssl-implemented
behaviour), is it? i.e. is the onus on the client application to
retry with a lower version if it wants to? What then is the purpose
of the option?
Correct, fallback (in this sense) is performed by the application. In
contrast, OpenSSL automatically upgrades away from SSL 3.0 (unless
prevent from doing so), in a way that is secure against
man-in-the-middle attacks.
The purpose of the option is to make totally broken applications a bit
less secure (when they happen to certain servers). From my point of
view, there is only one really good reason to have this client-side
option—so that you can test the server-side support. That's why I
implemented it for OpenJDK as well. Application should *never* use it
because it does not really solve anything. If you have fallback code,
your application is still insecure.
No the purpose is to make them more secure by preventing their
(rarely needed) fallback code from being abused by MITM attackers,
but the extra protection only works if the server contains the
corresponding patch. Basically, if a (patched) server sees that
the client set SSL_MODE_SEND_FALLBACK_SCSV while sending a "max
protocol version" lower than a protocol the server could have
supported, then the server will conclude that the application has
been mislead about that server, and reject the bad connection.

In the past, the server would think the client was old and the
client would think the server was old, resulting in a successful
attack.

This entire confusion is why I reported the
SSL_MODE_SEND_FALLBACK_SCSV documentation as being very incomplete.

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

______________________________________________________________________
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
2014-10-21 14:05:50 UTC
Permalink
Post by Jakob Bohm
Post by Florian Weimer
The purpose of the option is to make totally broken applications a
bit less secure (when they happen to certain servers). From my
I meant “a bit less insecure”, as Bodo pointed out.
Post by Jakob Bohm
Post by Florian Weimer
point of view, there is only one really good reason to have this
client-side option—so that you can test the server-side
support. That's why I implemented it for OpenJDK as well.
Application should *never* use it because it does not really solve
anything. If you have fallback code, your application is still
insecure.
No the purpose is to make them more secure by preventing their
(rarely needed) fallback code from being abused by MITM attackers,
but the extra protection only works if the server contains the
corresponding patch. Basically, if a (patched) server sees that
The key word here is “patched”, a broken-server-supporting application
gets only protection for well-maintained servers—after the Powers That
Be forced server operators to add a patch to better support such
broken-server-supporting applications. No one will be forced to fix
their insecure, version-intolerant servers, and it is unlikely that
those will ever implement TLS_FALLBACK_SCSV. It's a bit like telling
people to wear gas mask, instead of taking measures against air
polution.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users-MCmKBN63+***@public.gmane.org
Automated List Manager majordomo-MCmKBN63+***@public.gmane.org
Jakob Bohm
2014-10-22 12:41:42 UTC
Permalink
Post by Florian Weimer
Post by Jakob Bohm
Post by Florian Weimer
The purpose of the option is to make totally broken applications a
bit less secure (when they happen to certain servers). From my
I meant “a bit less insecure”, as Bodo pointed out.
OK, point already taken.
Post by Florian Weimer
Post by Jakob Bohm
Post by Florian Weimer
point of view, there is only one really good reason to have this
client-side option—so that you can test the server-side
support. That's why I implemented it for OpenJDK as well.
Application should *never* use it because it does not really solve
anything. If you have fallback code, your application is still
insecure.
No the purpose is to make them more secure by preventing their
(rarely needed) fallback code from being abused by MITM attackers,
but the extra protection only works if the server contains the
corresponding patch. Basically, if a (patched) server sees that
The key word here is “patched”, a broken-server-supporting application
gets only protection for well-maintained servers—after the Powers That
Be forced server operators to add a patch to better support such
broken-server-supporting applications. No one will be forced to fix
their insecure, version-intolerant servers, and it is unlikely that
those will ever implement TLS_FALLBACK_SCSV. It's a bit like telling
people to wear gas mask, instead of taking measures against air
polution.
I wouldn't be so harsh. I would say it is like telling people who
still carry cash howto tell the difference between a legitimate old
cash-only business and a fraudulentcheck-out clerk trying to cheat
them into paying cash that the (credit card accepting)modern shop
will never see.

With the combination of the server and client patches, the broken-
server-supporting code willno longer constitute a risk except when
actually talking to broken servers run by the(certificate verified)
legitimate owners of the requested domain name.

That is a huge reduction of the associated risk, soon the fallback
code will no longer endanger a visit to the (sort of) well run places
that people trust the most.

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users-MCmKBN63+***@public.gmane.org
Automated List Manager majordomo-MCmKBN63+***@public.gmane.org
Bodo Moeller
2014-10-21 12:11:28 UTC
Permalink
Florian Weimer <fweimer-H+wXaHxf7aLQT0dZR+***@public.gmane.org>:

The purpose of the option is to make totally broken applications a bit less
Post by Florian Weimer
secure (when they happen to certain servers).
I'd claim it's meant to make totally broken applications a bit *more*
secure :-)
Post by Florian Weimer
From my point of view, there is only one really good reason to have this
client-side option—so that you can test the server-side support. That's
why I implemented it for OpenJDK as well. Application should *never* use
it because it does not really solve anything. If you have fallback code,
your application is still insecure.
Right, ideally testing will be the only use of this option.

Bodo
Loading...