[OpenID] Reconsidering http://openid different from https://openid

[John Panzer]

So those are two different things, an HTTP redirect and OpenID 
delegation.  At least I'm assuming we're talking about two different 
things.  Here's the difference:

Redirect:

Client does GET http://someblog.blogspot.com
Client gets back a 301 with Location: https://someblog.blogspot.com

Delegation:

Client does GET http://someblog.blogspot.com
Client gets back a 200 with content containing <link 
rel="openid.delegate" href="https://blah.some.server.org">

Clients should follow 301's and should update their internal references 
to be the new URL (OpenID identifier).  Clients should use delegation to 
figure out how to authenticate a user, but the actual identifier 
shouldn't be affected.



Pat Patterson wrote:
> There's been something nagging at me through this discussion: the RP  
> seems to be following the trail all the way to the user's IdP. I  
> thought the user could do some delegation, so there is indirection  
> between the provided URL and the actual URL at the IdP, the benefit  
> being that I remain in control of (say) http://someblog.blogspot.com/  
> and I can move my actual IdP account from someidp.com to abetteridp.com.
> 
> What happens to all this if the RP is supposed to follow the rabbit  
> trail to the bottom and store someidp.com. When I get a better del  from 
> abetteridp.com, I'm stuck, am I not?
> 
> Cheers,
> 
> Pat
> 
> On Sep 29, 2007, at 1:38 AM, Lukas Rosenstock wrote:
> 
>> Am 29.09.2007, 03:44 Uhr, schrieb John Panzer  
>> <jpanzeracm at johnpanzer.com>:
>>
>>> Then I'm confused. If you do a redirect over http, a MITM attacker  can
>>> modify the response and show the user what appears to be their OP and
>>> collect their password, right?  That is, if the point of  redirecting to
>>> https is to prevent MITM attacks, but the initial redirect itself is
>>> vulnerable to MITM, what have you gained?
>>
>>
>> User logs in for the first time, enters http://myid/, gets  redirected to
>> https://myid/ (this identity is "SSL-validated" and can not be  taken 
>> over)
>> and is signed up as https://myid/. All an attacker in control of
>> http://myid/ can do is redirect to https://myid.fakeserver/ which is
>> obviously != https://myid/. So a new account for https:// 
>> myid.fakeserver/
>> would be created on the RP, the original account is still safe.
>> Have you taken a look at OpenID implementations, afaik there are  some 
>> who
>> do NOT do the redirect (or actually do it, but still take the  entered 
>> URL
>> as identifier - those would be vulnerable).
>>
>> -- 
>> Lukas Rosenstock
>> Identity 2.0 Europe :: http://identity20.eu/
>> _______________________________________________
>> general mailing list
>> general at openid.net
>> http://openid.net/mailman/listinfo/general
> 
> 
> - - - - -
> Pat Patterson
> Federation Architect, Sun Microsystems, Inc.
> pat.patterson at sun.com - http://blogs.sun.com/superpat
> - - - - -
> Join OpenSSO today! http://opensso.dev.java.net/
> - - - - -
> 
> 
> 
> 
>