that ess in 'https'

[David Strauss]

Martin Atkins wrote:
> David Strauss wrote:
>>
>>> But if HTTP and HTTPS URLs are equivilent, surely I can just spoof the
>>> HTTP version of your HTTPS URL and defeat the object entirely!
>>
>>
>> No. Not if the RP either checks for the https page first or remembers
>> that a particular OpenID supports https identity pages and refuses to
>> fall back to http after one successful https identity page download.
>> Some RPs may choose to only allow https mode identities. It shouldn't
>> ever be the user's concern which scheme is being used. It should be the
>> RP's. We just need some standards so RPs can consistently implement the
>> varying level of security without user concern.
>>
> 
> What's the argument against requiring OpenID relying parties to support
> SSL anyway? Most HTTP libraries will quite happily do SSL out of the
> box, and you can just neglect to validate the certificate if you don't
> care about security.

I think such a requirement would be good but raise the bar for RPs. Many
shared hosting providers don't have the right libraries installed for
SSL page fetches. That would make including OpenID in packages like
WordPress and phpBB difficult if not impossible.

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

> I think the main thing that's bothering me about this assumption that
> HTTPS and HTTP are the same is that it's making some arbitrary decision
> that we can trust these URLs as the same as long as the hostname and
> path are the same, regardless of scheme. If we're going to do that, can
> we also trust that (say) <http://mydomain.com/me/> and
> <http://mydomain.com/metoo/> are run by the same person? What about
> <http://mydomain.com/me/> and <http://mydomain.com/me/again/>?
> <http://me.mydomain.com/> and <http://you.mydomain.com/>?

It's not arbitrary. It's a whole different protocol layer below HTTP.
Should we distinguish OpenIDs by whether the identity page traveled over
IPv4 or IPv6?  It's the same basic thing.

> The assumption seems to be assuming that so long as the hostname matches
> the two URLs trust each other, which is probably true in a lot of cases.

It's certainly not true on my company's OpenID server. Using hostnames
alone would be a less flexible system and require expensive wildcard SSL
certificates to run securely.

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

- David