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

[Johannes Ernst]

Perhaps I'm not understanding what you are saying, but I don't think  
that "making HTTP and HTTPS identifiers equivalent eliminates any  
security benefit ... from .. TLS".

A Relying Party could still choose to only accept HTTPS identifiers.  
(thereby mandating the TLS security benefits).

But a Relying Party should be prevented from letting http://foo be  
somebody else than https://foo -- for security reasons, as John  
Panzer put it, or usability / tech support reasons, as I originally  
put it.


On Sep 18, 2007, at 15:40, Josh Hoyt wrote:

> On 9/14/07, Johannes Ernst <jernst+openid.net at netmesh.us> wrote:
>> I'd like to revisit this issue, as actual user behavior as I'm seeing
>> it tends to conflict with the assumptions we made when defining these
>> are two different identities. Specifically, I'd like the spec to say:
>>
>> "Identifiers distinguished only by the 'http' vs. 'https' in the
>> protocol part of the URL (e.g. 'https://foo.bar.com/' vs 'http://
>> foo.bar.com/") refer to the same identity. Conforming implementations
>> must ensure that attackers cannot use an identifier distinguished
>> only by the protocol to impersonate a victim."
>
> I'm strongly opposed to wording making HTTP and HTTPS identifiers
> equivalent. I understand that it can be confusing to users, but making
> those identifiers equivalent eliminates any security benefit that
> could be had from using TLS to protect the connection and verify the
> certificate of the server. Specifically, in order to impersonate a
> user, it would only be necessary to compromise a DNS server so that
> the application doing discovery returned a page with the attacker's
> choice of OpenID provider for that identifier.
>
> I think that your specific concern of impersonation is valid, but I
> think that the proposed solution just makes it so that the
> impersonation is perfect -- if you can obtain control of *one* of the
> identifiers, you effectively *are* the person in question. Not only
> can you perfectly impersonate the victim, you can also access any
> private content they may have.
>
> I am in favor of applications allowing a user to seamlessly upgrade a
> HTTP identifier to HTTPS or even for low-security applications to
> consider those identifiers equivalent, but it would be a serious
> security flaw if we specified that HTTPS is equivalent to HTTP. It
> would also be fine for an application to allow only one or the other
> protocol to work at a particular site.
>
> If anyone has suggestions on how to deal with this issue without
> degrading the security of the protocol, it would be great to address
> it.
>
> Josh
> _______________________________________________
> general mailing list
> general at openid.net
> http://openid.net/mailman/listinfo/general