- From: Reto Bachmann-Gmür <reto@gmuer.ch>
- Date: Tue, 16 Jul 2013 18:28:43 +0200
- 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