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. What happens with the patch only on the server? And what happens with the both server and client patched? On Fri, Oct 24, 2014 at 9:30 AM, Jakob Bohm <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> > 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 > This public discussion message is non-binding and may contain errors. > WiseMo - Remote Service Management for PCs, Phones and Embedded > >
