W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2014

Re: TLS Renegotiation and HTTP/2 (#363)

From: Yoav Nir <ynir.ietf@gmail.com>
Date: Tue, 1 Apr 2014 17:21:00 +0300
Cc: Martin Thomson <martin.thomson@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <7E52734F-C6AA-4336-B1E5-DF32237805AF@gmail.com>
To: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
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

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