- From: Yoav Nir <ynir.ietf@gmail.com>
- Date: Tue, 1 Apr 2014 17:21:00 +0300
- To: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
- Cc: Martin Thomson <martin.thomson@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
The same is true of basic authentication. The user should not send a certificate to the wrong site. If I had a certificate for the corporate SSL VPN, I would not pick that certificate for connecting to some random site. But you’ve convinced me - we should add the channel bindings to the signed data. On Apr 1, 2014, at 3:39 PM, Ilari Liusvaara <ilari.liusvaara@elisanet.fi> wrote: > On Tue, Apr 01, 2014 at 03:26:17PM +0300, Yoav Nir wrote: >> Yoav >> >> On Apr 1, 2014, at 3:21 PM, Ilari Liusvaara <ilari.liusvaara@elisanet.fi> wrote: >>> >>> That looks to be vulernable to forwarding and MITM attacks... >>> >> Sure, but not more so than regular server-authenticated HTTPS. >> >> We can get all fancy and tie it to extractors or channel bindings. The question is whether we want just mutual authentication or whether we want to foil MitM attacks and proxies while we’re at it. >> >> Foiling MitM has the downside (or upside) of making this not work from behind next generation firewalls. > > Suppose that user visits a maliscous site. What is to prevent > that site from contacting target site and forwarding > authentication exchange across (with who knows what other > headers and payload)? > > > -Ilari
Received on Tuesday, 1 April 2014 14:21:33 UTC