Re: WebID-ISSUE-64 (redirects): Redirects [WebID Spec]

On 25 Nov 2011, at 14:12, Peter Williams wrote:

> Someone posting from a BBC account noted that it was absolutely critical that there should be redirects - as a simple matter of link management.
>  
> First, BEFORE ANYONE ACCEPTS THIS ISSUE, SOMEONE NEEDS TO ASSERT THAT THERE REALLY IS A PROBLEM with redirects. If so, characterize it. My gut tells me that there are (reasoning as did the openid folks, faced with the very same issues).

There is a problem in that behaviour is unspecified. Both <link> and 303-redirects are common (and essential, as you say for link management) pattern.

*However*

What doesn't change is the WebID URI.

E.g..

subjectAltName => URI:http://example.com/test#id

Request, indicating “Accept: application/rdf+xml” http://example.com/test

Server returns “303 See other” / “Location: http://data.example.org/webid/example.rdf#id”

*If* you follow the redirect (and I believe you should, FWIW), then the resource you're directed to still has to provide a graph about the original WebID URI — that is, http://example.com/test#id, and that graph still has to include a cert:rsaPublicKey or cert:dsaPublicKey matching that in the presented certificate.

Now, regarding HTTP vs HTTPS, switching ciphersuites, hosts, and so forth, to my mind this is relatively straightforward: you apply the same minimum requirements rules each time you're directed elsewhere (which, AFAICS, will be at most once in any case), and you treat the chain as being as strong as the weakest link — so if initial request is HTTPS but you're directed to an HTTP URL, then you treat it as though it were an HTTP URL in the first place.

The underscoring issue here is that *this is a graph of untrusted assertions* — in effect, an unassured attribute exchange mechanism. With that in mind, I can't help but think the answers to “do you follow redirects; do you follow redirects beyond the original host or domain; do you accept http: URIs?” will be — putting MITM attacks to one side for a moment — “who cares?” — BECAUSE they're unassured attributes, it’s difficult to envisage a scenario where an application would perform security-critcial decision making on the basis of this. The only attribute which IS important is whether they control the WebID URI — which they must do if they're going to put in place a redirect or <link> elsewhere to a resource which does definitely contain the public key in the graph.

What you might do in a consuming application is prompt for confirmation before using the information from the graph if it came from a source where there’s a risk of MITM (or even redirects — or even full stop: “confirm that the details below are correct” covers a multitude of sins, including the user deliberately publishing incomplete or misleading information in their WebID graph and wishing to override it on a particular site).

Now, an attacker could compromise the server hosting your WebID and issue themselves a cert which points back at it… but they could do that whether or not there are redirects, <link>s or http vs https.

So, I’m struggling to see an issue here beyond underspecification: I don’t believe there's a (security or otherwise) problem in redirects per se.

M.

-- 
Mo McRoberts - Technical Lead - The Space,
0141 422 6036 (Internal: 01-26036) - PGP key CEBCF03E,
Project Office: Room 7083, BBC Television Centre, London W12 7RJ

Received on Sunday, 27 November 2011 00:37:10 UTC