[security] HTTP and HTTPS URL issue (was RE: security)

[Drummond Reed]

Martin, I see your point -- by compromising a user's HTTP URL, an attacker
can only redirect to another URL that would establish the attacker's OpenID
identifier, not the user's.

Which brings us back to the original point, which is that if the attacker
can compromise the user's HTTP URL, they can instead substitute the location
of the XRDS document, and thus authenticate to the user's HTTP URL, thereby
gaining access to resources that the user has secured under that identifier.

Would you agree that to prevent against THAT attack, a user must be using an
HTTPS URL?

If so, if the default canonicalization proscribed by the spec for
"example.com" is "http://example.com", then doesn't that mean all users who
want to assure the safety of their OpenID URL MUST ALWAYS type
"https://example.com"?

That's certainly not fatal, but from a UX standpoint, it sucks.

[It's worth noting, wearing my XRI hat, that none of this applies to XRIs
because the public XRI resolution network (xri.net) or any private community
XRI resolution network can be entirely secured with HTTPS. For example, all
RPs can automatically use HTTPS for all requests to xri.net. So I can type
=drummond at any OpenID RP and it can and should always use HTTPS for the
entire resolution chain.]

=Drummond 

-----Original Message-----
From: Martin Atkins [mailto:mart at degeneration.co.uk] 
Sent: Friday, October 27, 2006 10:37 AM
To: Drummond Reed
Cc: security at openid.net; general at openid.net
Subject: Re: [security] HTTP and HTTPS URL issue (was RE: security)

Drummond Reed wrote:
> 
> I agree with Pete. As elegant as it appears, there's a fatal flaw in this
> approach. If an attacker can gain control of an HTTP URL, they can CHANGE
> the HTTPS URL to which it points...
> 
> ...thereby completely stealing the identity.
> 

They can steal the HTTP URL, but they cannot steal the HTTPS URL. OpenID 
canonicalization rules state that if the user enters http://something/ 
and it redirects, that the *target* URL is what you use as the claimed 
identifier.

For example, in the non-compromised case:
  * User enters example.com
  * RP canonicalizes to http://example.com/ and tries to do discovery
  * Server responds with a redirect to http://somewhereelse.com/
  * RP does discovery to somewhereelse.com instead
  * After discovering the right server, RP does authentication and uses 
http://somewhereelse.com/ as the user's identifier.

If http://example.com/ is compromised and the false XRDS document points 
at a different IdP through which the attacker can successfully authenticate:
  * Attacker enters example.com
  * RP canonicalizes to http://example.com/ and tries to do discovery.
  * Server responds with the false authoritative IdP endpoint URL.
  * RP does authentication and uses http://example.com/ as the user's 
identifier.

Notice that the resulting URL is different in the latter case. The 
attacker must compromise somewhereelse.com in order to "steal" that 
identifier. It sucks that example.com has been compromised, but that 
isn't the identifier that all RPs know the legitimate user as anyway. 
The worst that can happen as far as mistaken identity goes is if the 
compromise is persistent, the legitimate user may well accidentally sign 
in with the compromised identity expecting the redirect to happen, which 
isn't as bad as a loss of the user's primary identifier.

Now if we imagine instead that http://example.com/ redirects to 
https://example.com/, you can see that the arrangement outlined in the 
spec does not open the HTTPS URL to attack despite the insecurity of the 
HTTP URL.