W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2013

Re: New Version Notification for draft-nottingham-http2-encryption-00.txt

From: Eliot Lear <lear@cisco.com>
Date: Tue, 01 Oct 2013 08:19:33 +0200
Message-ID: <524A6975.9010209@cisco.com>
To: Mark Nottingham <mnot@mnot.net>
CC: "ietf-http-wg@w3.org WG" <ietf-http-wg@w3.org>

On 10/1/13 8:00 AM, Mark Nottingham wrote:
> On 01/10/2013, at 3:57 PM, Eliot Lear <lear@cisco.com> wrote:
>
>> That is not what I call a strong indication.  Want to test its
>> effectiveness with users?
> I'm not disagreeing with you. Then again, it's already possible to perform this attack; the only difference is that the hostname will change (or not, depending on how IRIs are handled, and how creative the attacker is). 

This is more.  Here the hostname itself DOESN'T have to change.
Remember, you're dealing with a man in the middle, and so it terminates
one side and establishes a new (ironically authenticated non-relaxed
TLS) connection on the other side.  And the closer the man in the middle
is, the more attacks he can effect, so long as the browser follows the
primitive.
>
> Stronger mitigation is indeed necessary, although I disagree with your characterisation of only having three possible ways forward. 

Oh I imagine there are many ways forward.  Smarter people will surely
come up with something more than what I've suggested.  Heck off the top
of my head I can think of other ways forward, including the use of SSH,
but that doesn't seem to make efficient use of existing code, although
some of the concepts are relevant...

>
>
>>> It merely says "http protocol over TLS/SSL." That's what's happening here.
>>>
>>> More to the point, this draft is proposing a pretty fundamental change to how URI schemes map to protocols and ports, and so some adjustment of scheme and port semantics ought to be expected. 
>> Not to the detriment of TLS.
> Of course. We'll need to define that, though.

And just to be clear, RFC 2818 specifies the use of port 443, and that
clients MUST validate certs, and servers may have that very expectation.

Of course I'm not a fan of relaxed cert checking, but if you're going to
do it, consider some safer alternatives.  For instance, you could just
as easily go with Start-TLS: relaxed as a header and get the same
behavior on the same connection (this also reduces TCP overhead, as a
side effect).  That too is subject to an MITM attack, but at least it
leaves you no worse off than you are today.

Eliot
Received on Tuesday, 1 October 2013 06:20:07 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:18 UTC