<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Martin - <br>
<br>
Thank you for the advise. Once we have migrated a significant
number of our user population, we are quite determined to redirect. <br>
<br>
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. <br>
<br>
Best, <br>
<br>
Gerald<br>
<br>
<br>
<br>
Martin Atkins wrote:
<blockquote cite="mid:48A0A19E.6090100@degeneration.co.uk" type="cite">
<pre wrap="">Gerald Beuchelt wrote:
</pre>
<blockquote type="cite">
<pre wrap="">In a nutshell, we would like to require all users to use <a class="moz-txt-link-freetext" href="https://">https://</a>
prefixed OpenID identifier, so that RPs normalize and discover over
HTTPS, instead of HTTP. The obvious issue is that -- to my knowledge --
<a class="moz-txt-link-freetext" href="https://openid.sun.com/user">https://openid.sun.com/user</a> != <a class="moz-txt-link-freetext" href="http://openid.sun.com/user">http://openid.sun.com/user</a>. At this point
I see an opportunity for the OpenID community to address some of the
recent vulnerabilities: if RPs started to recognize both <a class="moz-txt-link-freetext" href="https://">https://</a> and
<a class="moz-txt-link-freetext" href="http://">http://</a> prefixed identifiers as the same entity, or at least allowed
easy linking, users could migrate with a lot more ease.
</pre>
</blockquote>
<pre wrap=""><!---->
It's worth noting that allowing <a class="moz-txt-link-freetext" href="http://example.com/">http://example.com/</a> to redirect to
<a class="moz-txt-link-freetext" href="https://example.com/">https://example.com/</a> as per the spec does not create a vulnerability for
<a class="moz-txt-link-freetext" href="https://example.com/">https://example.com/</a>. Due to the non-equivalence of the two, an attacker
that compromises <a class="moz-txt-link-freetext" href="http://example.com/">http://example.com/</a> has not also compromised
<a class="moz-txt-link-freetext" href="https://example.com/">https://example.com/</a>. 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 list
<a class="moz-txt-link-abbreviated" href="mailto:general@openid.net">general@openid.net</a>
<a class="moz-txt-link-freetext" href="http://openid.net/mailman/listinfo/general">http://openid.net/mailman/listinfo/general</a>
</pre>
</blockquote>
<br>
</body>
</html>