Am 24.10.2014 20:47, schrieb David Li:
On Fri, Oct 24, 2014 at 11:18 AM, Richard Könning
<[email protected]
<mailto:[email protected]>> wrote:
At 24.10.2014 19:03, David Li wrote:
I am still a little unclear by what exactly TLS_FALLBACK_SCSV option
would do.
What if the server only supports SSLv3 + TLSv1 and client only
connects
with SSLv3? Without the patch, both would agree to SSLv3. So
this is a
problem.
Well I thought it's the CBC cipher mode used by SSLv3 that has the
problem. So we should avoid SSLv3 all together.
Exactly. But when you have a client which speaks only SSLv3 as in your
example below you have to decide: Don't use the client or enhance it so
it speaks at least TLSv1 or use SSLv3 despite the problems with SSLv3.
Maybe this is is my confusion. Will the SSLv3 alone cause the attack? Or
will a "downgrade process" from TLS 1.0 or later to the SSLv3 expose the
vulnerability?
SSLv3 alone is vulnerable. When you decide that this vulnerability is so
large that you don't want to use SSLv3 in any case than life is easy:
deactivate the usage of SSLv3 in all clients and servers and you have
not to think about fall back to SSLv3.
But when your opinion is, that an SSLv3 connection is better than no
connection than you may have to fall back to SSLv3 some times. The
TLS_FALLBACK_SCSV helps you to ensure that the fall back is done only
when SSLv3 is really the highest SSL/TLS protocol shared by client and
server.
Best regards,
Richard
Where is the problem? When the client only supports SSLv3 and
therefore right away starts with SSLv3, then you get an SSLv3
connection as wanted. When you don't want any SSLv3 connections,
remove the SSLv3 support in the server and enhance the client so it
speaks also TLSv1 or better.
What happens with the patch only on the server? And what happens
with
the both server and client patched?
First question: nothing, because the client can't say to the server
that the second handshake with SSLv3 is a fallback of a previous
handshake announcing the availability of TLSv1 or better.
Second question: When the client starts due to a MITM attack a
second handshake announcing SSLv3 and setting TLS_FALLBACK_SCSV
option than the server knows that the client supports something
better than SSLv3 and quits the handshake.
Best regards,
Richard
On Fri, Oct 24, 2014 at 9:30 AM, Jakob Bohm
<[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>__>
wrote:
On 24/10/2014 18:19, Aditya Kumar wrote:
Thanks Jakob for correcting my understanding. In short,
can I
conclude the following about FALLBACK flag.
1. Whenever client is sending the FALLBACK flag in its
request, an
updated Server will interpret it that this client
supports a
higher version but since that higher version protocol
request was
refused, its trying to connect using a lower version
protocol.
2. The FALLBACK flag should only be set to communicate
to those
extremely rare old SSLv3 servers which completely fail
to accept a
request for (SSLv3 or TLSv1+, the best client have). In
that case,
first client should attempt to connect with
SSLAUTONEGOTIATE and
if it fails, then connect with SSLV3 FALLBACK enabled.
Much simpler: The FALLBACK flag should be set only to
communicate that
the client has activated its manual fall back code (if
any). If the
client doesn't contain manual fallback code, it doesn't
need to do
anything.
3. Points 2 holds true even for the cases where clients
connecting
using TLS 1.2 fail and then client need to connect
using TLS 1.1,
TLS1.0 or SSLV3.0. Then client should attempt the next
connections
using FALLBACK flag set.
Yes, SSLv3 is just an example, which happens to be
important right now
because of poodle.
Hope this will clear all the confusions.
-Aditya
On Fri, Oct 24, 2014 at 5:35 PM, Jakob Bohm
<[email protected] <mailto:[email protected]>
<mailto:[email protected]
<mailto:[email protected]>>__>wrote:
On 24/10/2014 13:33, Aditya Kumar wrote:
Hi All,
Thanks for your detailed responses, specially
Florian
Weimer and Matt Caswell. For the benefit of
everyone and
me, I am summarizing the thoughts which I have
understood
through all your replies. Please correct me
wherever I am
wrong.
To summarize:
1. Best way to prevent POODLE attack is
to disable
SSLV3 on both client and server side.
2. If for some reason, you cannot disable
SSLv3 on server
side even if Server support TLS 1.0 or
higher(e.g server
having SSLV23 set), Server definitely need to
be patched
to prevent fallback. Once server is patched, it
will
prevent updated clients from fallback attack.
3. After server is patched with OpenSSL
FALLBACK flag
fix, Server’s behavior will not change for the
clients
which do not send FALLBACK flag in their
clienthello
request. Server will continue to work with
older client as
usual. Only if an updated client sends FALLBACK
flag into
its clienthello request, server will be able to
prevent
fallback.
4. If for some reason, client has to keep
SSLV3 enable
even if it supports TLS 1.0 or higher version,
client need
to patch itself and set FALLBACK flag so that
it does not
come under fallback attack.
WRONG, See below
5. Clients should never set protocol as SSLV23
to support
both SSL3.0 and TLS Servers. Clients should always
explicitly first try to connect using its highest
supported version(TLS1.0 or higher) and if the
server
rejects the connection, then clients should
explicitly try
to connect using next supported lower version
protocol.
WRONG, If client simply calls the SSL23_ (aka
SSLAUTONEGOTIATE_) with
options to allow both SSLv3 and higher TLSvX.XX, it
is already
secure
and will never need to send the fallback flag.
6. While connecting to server using higher
protocol like
TLS1 or higher, client should set FALLBACK flag
so that
server do not allow automatically downgrade to
a lower
version protocol.
WRONG, Client should always try its full range of
enabled SSL/TLS
versions in one attempt, in which case the
protocols themselves
(even without the latest patch) will automatically
detect and
prevent a fallback MiTM attack.
However if client needs to work around some
(extremely rare) old
SSLv3 servers which completely fail to accept a
request for (SSLv3
r TLSv1+, the best you have), that client may use a
workaround of:
Step 6.1: Attempt to connect with
SSLAUTONEGOTIATE_(SSLv3 up to
TLSv1.2). Do not set/send FALLBACK flag.
Step 6.2: If Step 6.1 fails (either because of old
broken
server or
because of new fallback MiTM attack), try again
with SSLV3ONLY_(),
and set the FALLBACK flag to tell the server that
the maximum
version specified in this call is not the true
maximum version of
the client (in case it is not an old server, but a
MiTM attack
trying to trick this fallback code).
Step 6.3: Step 6.2 could be extended to do retries
with TLSv1.1,
then TLSv1.0, then SSLv3 etc. all of which would
need the FALLBACK
flag because the client would actually have wanted
TLSv1.2 if it
could get it.
**
Few questions which still remains in my mind are:
As part of my question’s reply, Florian replied
that
following:
*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.*
Why client application will break if FALLBACK
flag is set
and the server is upgrade to TLS 1.3 or higher
version?
Isn’t that the server should take care of this
flag when
it is updated with higher version protocol?
Note: If client calls with SSLAUTONEGOTIATE_(SSLvX
up to TLSv1.1)
and sets the FALLBACK flag, then a server which
understands
TLSv1.2 will read this as "I know this call says I
only understand
up to TLSv1.1, but that is only because I think you
refused my
attempt to use TLSv1.2 or higher", and therefore
the server will
REJECT the connection as if a MiTM attack in progress.
Note 2: If a client calls with
SSLAUTONEGOTIATE_(SSLvX up to
TLSv1.2) and sets the FALLBACK flag, then a server
which
understands
TLSv1.3 will read this as "I know this call says I
only understand
up to TLSv1.2, but that is only because I think you
refused my
attempt to use TLSv1.3 or higher", and therefore
the server will
REJECT the connection as if a MiTM attack is in
progress.
Please let me know your opinion on this.
Once again thanks everyone for your response.
-Aditya
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 <tel:%2B45%2031%2013%2016%2010>
<tel:%2B45%2031%2013%2016%__2010>
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 [email protected]
<mailto:[email protected]>
Automated List Manager [email protected]
<mailto:[email protected]>
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [email protected]
Automated List Manager [email protected]
