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 >
