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

Re: PRISM and HTTP/2.0

From: Reto Bachmann-Gmür <reto@gmuer.ch>
Date: Tue, 16 Jul 2013 18:28:43 +0200
Message-ID: <CALvhUEVxnJcvfc13PsEZW_8S4ZsLiZb1+h_f-M2W96jv_b0EBQ@mail.gmail.com>
To: Amos Jeffries <squid3@treenet.co.nz>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
On Tue, Jul 16, 2013 at 2:20 PM, Amos Jeffries <squid3@treenet.co.nz> wrote:
> On 16/07/2013 4:19 a.m., Reto Bachmann-Gmür wrote:
>
>> On Sun, Jul 14, 2013 at 12:41 AM, J Ross Nicoll wrote:
>>>
>>> Bogus certificates and server-side backdoors seem inevitable, at least in
>>> the current political climate. I don't think any realistic changes at the
>>> transport layer will affect that (unrealistic changes would include "move
>>> to
>>> a web of trust").
>>
>> Not sure if it would be within the possibilities of this WG to define
>> an optional public key hash in HTTP URIs. If a link contains such a
>> hash of the public key of the target this would protect against
>> attacks from a root-certificate holding man in the middle.
>
>
> I can't think how.

Abusing the userinfo subcomponent a  URI could look like this

https://WanYixZKajPyjw2llf@example.org/foo

If the public key presented by the server does not match the digest
WanYixZKajPyjw2llf the client would present a warning.

> The MITM can as easily change that public key to its own
> one and use the original itself as the client could use it in the first
> place.

No. The MITM might be able to provide a duly signed certificate for
example.org but it would much harder to create one which matches the
digest present in the referring URIs.


Reto
Received on Tuesday, 16 July 2013 16:29:07 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:14 UTC