that ess in 'https'
mart at degeneration.co.uk
Wed Jun 28 18:19:33 UTC 2006
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.
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.
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.
>>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.
More information about the yadis