Thanks Jakob and everyone for their prompt replies. My most of the doubts are cleared and I just want to confirm the protocol behavior in one particular scenario.
Suppose, the Server is patched with the FALLBACK flag and its protocol is set to TLSV1/SSLV23(with TLSV1 as the highest protocol) and then client tries to connect to Server in TLSV1 and sets FALLBACK flag before initiating communication with Server. Will the client be able to connect to Server? Will Server accept this connection? >From my understanding, when Server will see the request with FALLBACK flag and Server's highest protocol is TLSV1, it will not really consider the client's request as fallback and will allow the connection. This will work only because Server's highest protocol is TLSV1. But if in future, if the Server is upgraded to support TLS1.1 or TLS1.2, then the same connection from client will fail. Please let me know if this correct. Regards, Aditya On Sat, Oct 25, 2014 at 2:46 AM, David Li <dlipub...@gmail.com> wrote: > > > On Fri, Oct 24, 2014 at 1:28 PM, Richard Könning < > richard.koenn...@ts.fujitsu.com> wrote: > >> Am 24.10.2014 20:47, schrieb David Li: >> >>> >>> >>> On Fri, Oct 24, 2014 at 11:18 AM, Richard Könning >>> <richard.koenn...@ts.fujitsu.com >>> <mailto:richard.koenn...@ts.fujitsu.com>> 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. >> > > > > So is it true that in this case TLS_FALLBACK_SCSV still can't prevent the > attack since this is a totally legitimate honest fallback to SSLv3? In > other words, the MITM attacker doesn't have to message the handshake at > all. > > > > >> >> 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 >>> <jb-open...@wisemo.com <mailto:jb-open...@wisemo.com> >>> <mailto:jb-open...@wisemo.com <mailto:jb-open...@wisemo.com>>__> >>> >>> 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 >>> <jb-open...@wisemo.com <mailto:jb-open...@wisemo.com> >>> <mailto:jb-open...@wisemo.com >>> <mailto:jb-open...@wisemo.com>>__>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 openssl-users@openssl.org >>> <mailto:openssl-users@openssl.org> >>> Automated List Manager majord...@openssl.org >>> <mailto:majord...@openssl.org> >>> >>> >>> >> ______________________________________________________________________ >> OpenSSL Project http://www.openssl.org >> User Support Mailing List openssl-users@openssl.org >> Automated List Manager majord...@openssl.org >> > >
