[OpenID] security weakness regarding authentication of the relying party

[Francisco Corella]

Paul,

> I’m not entirely sure how the Janrain code works, as I’ve
> not really looked at it.  I’m pretty sure, though, that the
> OP code I wrote would complain if the “return to” URL is not
> a sub-domain of the specified realm.  It even checks to
> ensure that the scheme matches (e.g., HTTPS or HTTP must be
> used in both places).  So, I would assume that the example
> you give below would fail on my server.  Not sure, of
> course… there’s always opportunity for a bug ;-)

I'm sure your code checks the return_to URL correctly, and
the Janrain code does too.  The example was not about the
return_to URL.  What I was trying to say is that, when an
application hosted at example.com uses the free Janrain
widget, the widget uses the realm example.rpx.com, causing
the OP to ask the user to trust example.rpx.com.  If the
user were knowledgeable about domain name syntax, he/she
would realize that this is not the domain of the application
that he/she is trying to use, and he/she would refuse to go
ahead and trust example.rpx.com.  So the point is: users are
not knowledgeable about domain name syntax, and the widget
relies on the fact that they are not.

> I do agree that HTTPS ought to be used everywhere.  There
> are two issues with meeting that requirement.  Some argue
> that these issues are weak arguments, but they are truly an
> impediment to getting wide adoption:
> 
> 1) TLS certificates are still more expensive than they ought
> to be.  We’re talking about something that can be cranked
> out entirely automatically and in a fraction of a second and
> some people believe this “work” is worth more than $100. The
> cheapest price I’ve seen is $13 per certificate, which is
> getting close to reasonable, but still too high.  The domain
> name cost less than the certificate!  This rip-off needs to
> end.
> 
> 2) Many, many web servers still do not support Server Name
> Indication (SNI).  So, many web sites cannot even provide
> proper support for TLS.  It was for this reason that I wrote
> my OP server code such that the only piece of software that
> absolutely, really should be placed behind HTTPS was the one
> that handles password checks and cookies for
> checkid_immediate.
> 
> 3) Many client libraries still do not support SNI, including
> those running OpenID RP code.  The stock browser on Android
> and other browsers do not support SNI.
> 
> Anyway, your statement is correct, but I think there are
> practical reasons why the standard did not mandate HTTPS.

The point I was trying to make is not so much that SSL is
not required by the spec, it's that it is not recommended for the RP,
whereas it is strongly recommended for the OP.  And there is
no discussion of the matter at all in the security
considerations.  Somebody who reads the spec may think that
SSL is just unnecessary for the RP.  An RP that has a
dedicated a server and an SSL certificate used for other
purposes, and that would have no difficulty receiving SSL
connections at the return_to endpoint, may not use SSL at
the endpoint just because nothing in the spec says that that
would be helpful.

Francisco


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20110118/4e432770/attachment.html>