Re: Web Keys and HTTP Signatures

[Amos Jeffries <[e-mail]>]

On 19/04/2013 1:42 a.m., Manu Sporny wrote:
> On 04/17/2013 08:00 PM, Martin Thomson wrote:
>> 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.
> Carsten, James, Martin - good catch, thanks. We had assumed that the
> implementation included the headers names as well as the values in the
> data being digitally signed. As Dave Lehn pointed out, this is a work in
> progress, but we wanted to get something out as sooner than later.
>
> The attack is only possible if a message is passed over a non-secure
> channel, right? That is, the spec is clear about passing all messages
> over HTTPS. Granted, that's not an excuse for the approach taken and it
> should be fixed, but the attack is only possible if messages are sent
> over an insecure channel, correct?

We had this argument out in the Bearer auth discussions. HTTPS is just 
one layer of security, it can (and routinely is) broken into by 
transparent proxies.

Your auth scheme needs to be as self-contained as possible and take 
advantage of every little bit of security that it can do without relying 
on external layers such as the SSL/TLS layer. It is better to be 
doubly-strong when HTTPS works than to depend on it alone break at the 
first sign of trouble.

IMO signed message schemes like this stand a far better chance of being 
rolled out if they work on plain-HTTP. There are a number of web 
applications and service which require security without the sledgehammer 
and limitations of TLS.

Amos