Re: Web Keys and HTTP Signatures

Martin Thomson <martin.thomson@gmail.com> Thu, 18 April 2013 00:01 UTC

Return-Path: <ietf-http-wg-request@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6975021E8086 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 17 Apr 2013 17:01:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.442
X-Spam-Level:
X-Spam-Status: No, score=-8.442 tagged_above=-999 required=5 tests=[AWL=1.557, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ci5jLcuaBzTk for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 17 Apr 2013 17:01:12 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 8DD0621E8043 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Wed, 17 Apr 2013 17:01:12 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1UScHS-0000to-PI for ietf-http-wg-dist@listhub.w3.org; Thu, 18 Apr 2013 00:00:50 +0000
Resent-Date: Thu, 18 Apr 2013 00:00:50 +0000
Resent-Message-Id: <E1UScHS-0000to-PI@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <martin.thomson@gmail.com>) id 1UScHP-0000t1-LJ; Thu, 18 Apr 2013 00:00:47 +0000
Received: from mail-we0-f178.google.com ([74.125.82.178]) by lisa.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <martin.thomson@gmail.com>) id 1UScHO-0000w5-F7; Thu, 18 Apr 2013 00:00:47 +0000
Received: by mail-we0-f178.google.com with SMTP id z53so1633243wey.37 for <multiple recipients>; Wed, 17 Apr 2013 17:00:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=3WjzFzAfznN2VgLBIgQsbRnkx6lStZ4Njo2ORwGwaTU=; b=aJBnab4RzTGK9dZ2xJ0n9WtrbRFG57WpezahswjBOVE+eP4ddaDyUiENadysJv6RaW Ad4XWLHGKy3nvtzK3RGbsurEW6+9hG54SB1vPzVHsIRvSaZhp9R1V93WOrumZNr/hbwT 4V4mrIr1iutas5wY7JL0ntv5rqByTafLaznZCZaVtnHLds1t6krM+TuiatDcQSVVy0zB nYfclD14FhSC6xiInTSbpMKyREWRqn9Bwc9uCbDDlHplRo5bPHQFRf2OFEPz0LydpArR JIDlYjxmUayHbaf9HOO9bC1zgcHqPWrJjZCfMzJCssRSiLbTNdGf22wR5ARBsdqXWIQH U3WQ==
MIME-Version: 1.0
X-Received: by 10.194.109.227 with SMTP id hv3mr14667848wjb.32.1366243220166; Wed, 17 Apr 2013 17:00:20 -0700 (PDT)
Received: by 10.194.28.195 with HTTP; Wed, 17 Apr 2013 17:00:20 -0700 (PDT)
In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1150C90E93E@WSMSG3153V.srv.dir.telstra.com>
References: <516F14E1.5040503@digitalbazaar.com> <9DF0F237-62DC-4E82-A545-B09C6083849B@tzi.org> <CADcbRRN2XWa9QwuaXAoxjMdkcguvQiiGq934RXU=-1ntzGpWNQ@mail.gmail.com> <255B9BB34FB7D647A506DC292726F6E1150C90E93E@WSMSG3153V.srv.dir.telstra.com>
Date: Wed, 17 Apr 2013 17:00:20 -0700
Message-ID: <CABkgnnXoY3iOH7M=A5hCo+eTnDiPODvgmdnDay0AKUo4PsuoMg@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: "Manger, James H" <James.H.Manger@team.telstra.com>
Cc: "David I. Lehn" <dil@lehn.org>, Carsten Bormann <cabo@tzi.org>, Manu Sporny <msporny@digitalbazaar.com>, Web Payments CG <public-webpayments@w3.org>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Received-SPF: pass client-ip=74.125.82.178; envelope-from=martin.thomson@gmail.com; helo=mail-we0-f178.google.com
X-W3C-Hub-Spam-Status: No, score=-3.3
X-W3C-Hub-Spam-Report: AWL=-2.541, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001
X-W3C-Scan-Sig: lisa.w3.org 1UScHO-0000w5-F7 3729030717fcd1bf73e1b1910af0a0d2
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Web Keys and HTTP Signatures
Archived-At: <http://www.w3.org/mid/CABkgnnXoY3iOH7M=A5hCo+eTnDiPODvgmdnDay0AKUo4PsuoMg@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/17318
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

Yeah, that's a pretty bad.  Switching two date-formatted headers might
be a simple thing to gain advantage on.  (Last-Modified and Date,
might work to poison a cache with old content if the cache isn't
rigorous about checking Date).  It seems like a simple fix would be to
include the list of headers under the signature as the first item.

On 17 April 2013 16:56, Manger, James H <James.H.Manger@team.telstra.com> wrote:
> 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
>