- From: Jason Greene <jason.greene@redhat.com>
- Date: Thu, 13 Nov 2014 12:12:10 -0600
- To: Eric Rescorla <ekr@rtfm.com>
- Cc: Greg Wilkins <gregw@intalio.com>, Ryan Hamilton <rch@google.com>, Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
> 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. It’s easily preventable: 1. Send the same or stronger suites on retry (e.g. h2-only) 2. Take care to ensure retry only occurs after INADEQUATE_SECURITY is received -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat
Received on Thursday, 13 November 2014 18:12:50 UTC