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
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@openssl.org
Automated List Manager majord...@openssl.org
