Interesting observation, Martin. You make a good point.<div><br></div><div>However, it is insecure because it is then susceptible to phishing. Imagine a scenario where I usually log in simply as "<a href="http://blog.nerdbank.net">blog.nerdbank.net</a>", which we'll assume redirects to <a href="https://blog.nerdbank.net">https://blog.nerdbank.net</a> at the OP.</div>
<div><ol><li>Attacker using DNS poisoning to fool the RP into resolving "<a href="http://blog.nerdbank.net">blog.nerdbank.net</a>" to the attacker's server.</li><li>I begin to log into the compromised RP.</li>
<li>I am redirected to the attacker's OP, which is designed to look like mine. I am asked for my login credentials, and I use a password (bad, I know, but go with me on this scenario).</li><li>I give my password and the site lies to me and says I've logged in. It redirects me to the RP, where my account... isn't there, since as you say Martin, it's a different account at the RP.</li>
<li>Now the attacker has my real OP's login credentials and can now log in as me using my real account at the compromised RP, even after the RP recovers from the DNS poisoning.</li></ol><div>So you see, using insecure HTTP at all during identifier discovery is a bad thing. Yes, it can be mitigated by using non-phishable credentials like Cardspace or X.509, but since most users don't use that yet, using HTTPS identifiers that do not rely on redirects from HTTP identifiers is the only secure way to go.</div>
<br><div class="gmail_quote">On Sun, Nov 2, 2008 at 9:57 PM, Martin Atkins <span dir="ltr"><<a href="mailto:mart@degeneration.co.uk">mart@degeneration.co.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="Ih2E3d">SitG Admin wrote:<br>
><br>
> Indeed. Yet how well have we done at communicating this to users? How<br>
> consistently do they enter their secure URI instead of omitting the<br>
> prefix entirely? Solutions have been suggested, if I'm not mistaken,<br>
> such as detecting incoming requests from RP's to the HTTP page and<br>
> redirecting them to the HTTPS version, or having OpenID headers stating<br>
> that only the HTTPS version should be used for OpenID - but what if the<br>
> RP contacts a hostile server because its initial request was not secure?<br>
><br>
<br>
</div>Having a http: URL redirect to an https: URL is secure even if the http:<br>
URL is compromised, because the redirect "canonicalizes" the claimed<br>
identity to the https: URL.<br>
<br>
While an attacker can in theory compromise the http: URL and make it<br>
redirect somewhere else or not redirect at all, since the user's<br>
accounts are tied to the https: URL they don't gain access to these<br>
accounts.<br>
<div><div></div><div class="Wj3C7c"><br>
_______________________________________________<br>
general mailing list<br>
<a href="mailto:general@openid.net">general@openid.net</a><br>
<a href="http://openid.net/mailman/listinfo/general" target="_blank">http://openid.net/mailman/listinfo/general</a><br>
</div></div></blockquote></div><br></div>