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

[Martin Atkins]

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.