[OpenID] RPs accepting https:// identifiers

[Andrew Arnott]

Gerald,

As you are migrating your Sun users, please consider:
How to make your OpenID Provider case
insensitive<http://blog.nerdbank.net/2008/07/how-to-make-your-openid-provider-case.html>
And I would add to the highly recommend best practice of redirecting to
HTTPS, to also highly recommend that all directed identities result in an
HTTPS claimed identifier as opposed to the HTTP "equivalent" one.

On Mon, Aug 11, 2008 at 2:15 PM, Gerald Beuchelt <beuchelt at sun.com> wrote:

>  Martin -
>
>     Thank you for the advise. Once we have migrated a significant number of
> our user population, we are quite determined to redirect.
>
>     However, this does not solve the initial RP-side normalization to HTTP
> based identifiers. In my opinion, it is a necessary step, but not
> sufficient. But I would agree that performing a redirect on the HTTP port to
> HTTPS should be a highly recommended best practice.
>
> Best,
>
> Gerald
>
>
>
>
> Martin Atkins wrote:
>
> Gerald Beuchelt wrote:
>
>
>  In a nutshell, we would like to require all users to use https://
> prefixed OpenID identifier, so that RPs normalize and discover over
> HTTPS, instead of HTTP. The obvious issue is that -- to my knowledge -- https://openid.sun.com/user != http://openid.sun.com/user. At this point
> I see an opportunity for the OpenID community to address some of the
> recent vulnerabilities: if RPs started to recognize both https:// and http:// prefixed identifiers as the same entity, or at least allowed
> easy linking, users could migrate with a lot more ease.
>
>
>  It's worth noting that allowing http://example.com/ to redirect to https://example.com/ as per the spec does not create a vulnerability for https://example.com/. Due to the non-equivalence of the two, an attacker
> that compromises http://example.com/ has not also compromised https://example.com/. Were RPs to consider the http: and https: URLs
> equivalent, this would actually defeat the security provided by SSL
> since an attacker could attack the http: URL and compromise the https:
> URL for free.
>
> Therefore I would advise that if you are going to allow only https:
> identifiers that you consider the "final URL" after discovery, rather
> than the initial URL the user enters. This would allow the OP to
> redirect the non-SSL version to the SSL version of the identifier, which
> is something that most SSL-supporting OPs do already and I think is
> considered to be a best practice.
>
>
> _______________________________________________
> general mailing listgeneral at openid.nethttp://openid.net/mailman/listinfo/general
>
>
>
> _______________________________________________
> general mailing list
> general at openid.net
> http://openid.net/mailman/listinfo/general
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20080811/64efbed0/attachment-0002.htm>