that ess in 'https'

[David Strauss]

Martin Atkins wrote:
> David Strauss wrote:
>>
>>> I think my favourite solution right now is to require relying parties to
>>> support SSL and then use the existing "canonicalization through
>>> redirection" feature of OpenID to solve this problem. The problem that
>>> doesn't address is where an identity provider starts off on cleartext
>>> and migrates to SSL, which admittedly I don't have a good answer to.
>>
>> I don't like the redirection system because it still makes an insecure
>> hop. It would be more secure to try the https scheme first. I don't see
>> why people are resistant to this. The only restriction is that you can't
>> have different identities distinguished only by scheme.
>>
> 
> It only requires that insecure "hop" if the user enters an HTTP URL into
> the relying party in the first place. If they enter an HTTPS URL, that
> won't be included. If someone manages to spoof the HTTP bit, all they've
> achieved is to create themselves a new identity since the two aren't
> considered equivilent under this proposal.
> 
> Perhaps a compromise between these two would be for *schemeless* partial
> URLs (If I enter frank.livejournal.com rather than
> http://frank.livejournal.com) to be defined as trying HTTPS first and
> then HTTP, and whatever one succeeds is the canonical identity. They are
> not considered equivilent as far as "are these two identities the
> same?", but users don't have to concern themselves with entering the
> right scheme. If I log in as "frank.livejournal.com" and the HTTPS
> connection works, the relying party remembers me as
> https://frank.livejournal.com/. If I come back later and log in as
> "http://frank.livejournal.com/" (typing the scheme explicitly) as second
> identity is created. Likewise, if I come back later and log in with a
> schemeless URL but my HTTPS server is gone, a second identity is created.

I like this basic proposal, but read on. Remember that almost every
OpenID user enters schemeless versions of their URL, so this system
would likely be the norm rather than the exception.

I'd still like to prohibit hosting different IDs at URLs that vary only
by scheme, if only to allow easy migration from http IDs to secure ones.

Scenario: Bob signs onto OpenIDFlowers, an RP. Because he enters
bob.mropenid.com, the site tries https first. Unfortunately,
MrOpenID.com doesn't support https identity pages yet, so Bob is signed
on as http://bob.mropenid.com/. He sets up preferences, etc. The next
week, MrOpenID.com starts supporting https identity pages. So, later
that next week, Bob signs onto OpenIDFlowers with bob.mropenid.com.
Because his OpenID server supports https identity pages now, he's signed
on as https://bob.mropenid.com/. He's confused about where all his
preferences went.

Now, if OpenIDFlowers could be certain that http://bob.mropenid.com/ and
https://bob.mropenid.com/ represent the same person, OpenIDFlowers could
port the http identity data to the https one. Because Bob signed on once
using an https identity, OpenIDFlowers would be wise to deny signing on
with his http equivalent now.

This system would allow:
1. Continued support for http identities and totally non-SSL servers
2. Progressive upgrades to SSL as OpenID servers add that capability.
3. Identity spoofing protection after the first https signon.

This system would not allow an OpenID server to easily stop supporting
https identity pages after initial support.

> This has the nice side-effect that we don't burden relying parties with
> the task of parsing/normalizing a URL. They can just shove the URL into
> their database and do string matching on it for future lookups; the
> identity is the same as long as it is character-for-character identical.
> This is how the relying party implementations I'm aware of currently
> treat identity URLs. I don't think it's too taxing to expect a user to
> enter their URL in the same form each time.

What I'm proposing would best be implemented on the database side by
storing schemeless URLs and a boolean field for whether that ID is
locked to https.

> On the other hand, setting up an SSL connection has a lot more overhead
> than setting up a plain TCP connection, and sites may object to having
> hundreds of relying parties requesting non-existant paths from their SSL
> sites even though they don't provide identities over SSL. LiveJournal,
> for example, would have to serve a useless a request on its payment
> server every time a LiveJournal user logs in somewhere.

I'd leave this up to the RP. If a site doesn't need https-level
security, then it's free to default to http:// URL normalization. Every
OpenID server should probably support http identity pages.

>>> However, technically the difference between <http://mydomain.com/> and
>>> <https://mydomain.com/> is the same as the difference between
>>> <http://something.mydomain.com> and <http://somethingelse.mydomain.com/>
>>> as far as the HTTP protocol is concerned, so if we allow one why do we
>>> not allow both?
>>
>> It's not the same. It's a different protocol level. SSL is a layer that
>> optionally runs beneath HTTP. It's the fact that we specify the protocol
>> in the URL that the HTTP request goes over that's weird (for an
>> addressing scheme).
>>
> 
> If you take the SSL layer out then what you're left with is an HTTP
> server running on a different port, and HTTP considers
> http://whatever.com:80/ and http://whatever.com:81/ to be two distinct
> URLs. You correctly state that SSL is just the transport on which we
> layer HTTP, but the two are distinct even if "https:" just means "use
> port 443" instead. It's a shame no-one implemented RFC2817, since then
> the two would be the same as far as HTTP is concerned.
> 
> On the other hand, the difference between IPv4 and IPv6 (which you
> mentioned in a portion of your message that I snipped) does not cause
> any ripples at the HTTP level, since it is defined that implementations
> should try to resolve an AAAA record and then fall back on an A record
> if one isn't found, meaning that the URLs are considered equivilent at
> the HTTP level.

Everything you've said is true, but always remember that URLs transcend
several protocol layers in what they specify. I don't think it's wrong
to cut off consideration at some level. Though it would be
controversial, I'd like the OpenID namespace to only include domain and
path (exclude scheme and port number).