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.
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.
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.
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?
Please let me know your opinion on this.
Once again thanks everyone for your response.
-Aditya
On Wed, Oct 22, 2014 at 6:11 PM, Jakob Bohm <jb-open...@wisemo.com> wrote:
> On 21/10/2014 16:05, Florian Weimer wrote:
>
>> * Jakob Bohm:
>>
>> 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.
>
>>
>> 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@openssl.org
> Automated List Manager majord...@openssl.org
>
