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

[Eddy Nigg (StartCom Ltd.)]

J Panzer wrote:
> Martin Atkins wrote:
>   
>> Johannes Ernst wrote:
>>
>>     
>>> I'm one of the guys who actually maintains an ACL (Access Control List) 
>>> based on OpenID identities. The process works like this:
>>> - Customer: hey, I'd like access to your website
>>> - Me: sure, send me your OpenID
>>> - Customer: foo.bar.com
>>> - Me: adding http://foo.bar.com/ to the ACL
>>> - Customer: hey, I tried but it doesn't work
>>> - Me (diagnosing): that's because you entered 'https://foo.bar.com/' 
>>> and not 'http://foo.bar.com/".
>>>
>>> This happens in a surprisingly large number of cases.
>>>
>>>       
>> I believe the recommended pattern is to have the http: form redirect to 
>> the https: form, thus allowing foo.bar.com to be entered:
>>
>>   * Consumer normalizes to http://foo.bar.com/
>>   * Consumer gets redirected to https://foo.bar.com/
>>     
>
> If an attacker can compromise the http version, and redirects to 
> https://foo.bar.com.evil.org in this step, there should be an error 
> displayed, right?  Shouldn't this be documented explicitly?
If an attacker compromised the http version than he most likely 
compromised also the https version (redirects can be done via http 
header of the same system). However I'm not sure of there is any client 
side capability implemented in this case, expect the client to 
follow...However the issue of your question isn't that of http versus 
https, but that of redirecting clients. How should the client behave 
(follow?)

-- 
Regards 
 
Signer:  	Eddy Nigg, StartCom Ltd. <http://www.startcom.org>
Jabber:  	startcom at startcom.org <xmpp:startcom at startcom.org>
Blog:  	Join the Revolution! <http://blog.startcom.org>
Phone:  	+1.213.341.0390
 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20070928/a4cd8c6f/attachment-0002.htm>