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 15:26:17 +0300
Cc: Martin Thomson <martin.thomson@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <19F95EF4-5130-4002-98B1-6B6970E2026E@gmail.com>
To: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
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.

Yoav

On Apr 1, 2014, at 3:21 PM, Ilari Liusvaara <ilari.liusvaara@elisanet.fi> wrote:

> On Tue, Apr 01, 2014 at 02:02:09PM +0300, Yoav Nir wrote:
>> 
>> Server sends:
>> HTTP/1.1 401 Unauthorized
>> WWW-Authenticate: Certs
>>        realm = “example.com”
>>        challenge="EKgoC3wwy8KuJROo/gmG1we43c5av9OwOlWaYVPStsw=“
>> 
>> Client sends:
>> Authorization: Certs
>>        realm=“example.com”
>>        hash=“SHA-256”
>>        cert=“MIIGzTCC...gpECY="
>>                challenge="EKgoC3wwy8KuJROo/gmG1we43c5av9OwOlWaYVPStsw=“
>>        signature=“FIMe3WLvlgX3BgJKYN0DXj4UGuauq5fwXgZErnFgVR0=“
>> 
>> All you really need with client certificate authentication is to show the certificate and sign something of the server’s choosing. You can make it fancier by having the server list supported hashes and trusted CAs, but that’s not strictly necessary.
> 
> That looks to be vulernable to forwarding and MITM attacks...
> 
> 
> -Ilari 
Received on Tuesday, 1 April 2014 12:26:50 UTC

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