On Thu, Nov 13, 2014 at 8:12 AM, Jason Greene <jason.greene@redhat.com> wrote: > > > On Nov 13, 2014, at 10:34 AM, Eric Rescorla <ekr@rtfm.com> wrote: > > > > > > > > On Wed, Nov 12, 2014 at 7:27 PM, Jason Greene <jason.greene@redhat.com> > wrote: > > > >> On Nov 12, 2014, at 4:40 PM, Eric Rescorla <ekr@rtfm.com> wrote: > >> > >>> On Tue, Nov 11, 2014 at 8:58 PM, Greg Wilkins <gregw@intalio.com> > wrote: > >>> > >>> I think it is a downgrade attack vector, but what I think this WG is > trying to say is that it is an acceptable one. If either peer wants to > avoid it, they simple need to not offer the bad ciphers. > >>> > >> Can you please explain how this downgrade attack works? > > > > In order to deal with servers which, perhaps mistakenly, accept non-h2 > compliant ciphers, a client has to choose between failing the connection > entirely (when H1 would have worked fine), or opening a new connection. If > that new connection offers a weaker selection of ciphers (perhaps some kind > of fallback to an old code path) it becomes a potential target. > > > > Can you explain how the attacker exploits that? > > A contrived example is that client that didn’t previously support > fallback, adds code for fallback due to this aspect of the spec. The code > for fallback assumes any connection establishment failure should result in > a retry. The attacker can then do something like in POODLE, and just MITM > abort the connection. > OK, but the problem is that code. You should only be falling back on INADEQUATE_SECURITY, not negotiation failure, precisely because the former is authenticated and the latter is not. -Ekr
Received on Thursday, 13 November 2014 19:00:42 UTC