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