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

RE: Web Keys and HTTP Signatures

From: Manger, James H <James.H.Manger@team.telstra.com>
Date: Thu, 18 Apr 2013 09:56:01 +1000
To: "David I. Lehn" <dil@lehn.org>, Carsten Bormann <cabo@tzi.org>
CC: Manu Sporny <msporny@digitalbazaar.com>, Web Payments CG <public-webpayments@w3.org>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Message-ID: <255B9BB34FB7D647A506DC292726F6E1150C90E93E@WSMSG3153V.srv.dir.telstra.com>
Bad guy swaps the values of two headers (hence changing the semantics of the HTTP request). Bad guy also swaps the order in which the two headers are listed in the 'headers' attribute (hence the signing string is the same). Consequence: same signature is valid for two different requests.

A bad guy cannot change the signing string but, as Carsten notes, they can change which line of the signing string is treated as the date, as the content-type, as whatever by adjusting the unprotected 'headers' attribute.

P.S. This scheme doesn't match the allowed syntax for the Authorization header. After "Signature" you can have a single base64 blob OR comma-separated name=value pairs -- you cannot mix the two. Stick sig="..." around the signature.

James Manger

> -----Original Message-----
> From: dilehn@gmail.com [mailto:dilehn@gmail.com] On Behalf Of David I.
> Lehn
> Sent: Thursday, 18 April 2013 9:13 AM
> To: Carsten Bormann
> Cc: Manu Sporny; Web Payments CG; ietf-http-wg@w3.org
> Subject: Re: Web Keys and HTTP Signatures
> On Wed, Apr 17, 2013 at 6:03 PM, Carsten Bormann <cabo@tzi.org> wrote:
> > On Apr 17, 2013, at 23:32, Manu Sporny <msporny@digitalbazaar.com>
> wrote:
> >
> >> https://github.com/joyent/node-http-

> signature/blob/master/http_signin
> >> g.md
> >
> > I looked at this for about 5 seconds, but are you telling us the
> attacker gets to choose what the lines in the signed string are
> supposed to mean?
> >
> I'm not sure I understand your question? The request signature
> specifies the headers that are signed. The server can reject a request
> based on a header requirement policy. Our current implementation
> requires the headers to at least include request-line, host, and date.
> What specific attack did you have in mind?
> -dave

Received on Wednesday, 17 April 2013 23:56:33 UTC

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