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

[John Kemp]

Johannes Ernst wrote:
> 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.

I guess it may be either an RP, an OP or even perhaps a user's decision
as to whether two identifiers identify (to that entity) the same identity.

Isn't the point of an /identifier/ is that it is unique within a
namespace? In the namespace of URLs, http://op.com/john.kemp is
/technically/ a different identifier than https://op.com/john.kemp, and
I cannot make any assumption of "identity equivalence" even if they most
likely do identify the same identity....

For the purposes of identification (as separate from those of security)
, then, isn't http vs. https (technically) irrelevant?

And back to Josh's point:

>>> 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.

It would seem to me that these statements make a lot of sense as
"implementation guidelines" or "best practices".

- John

> 
> 
> 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
> 
> _______________________________________________
> general mailing list
> general at openid.net
> http://openid.net/mailman/listinfo/general