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

[Josh Hoyt]

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