[OpenID] The HTTPS in the OpenID (Re: Bug in OpenID RP implementations)

Fri Jan 2 09:08:39 UTC 2009

First a Happy New 2009 to all of you!

Second a rant about "HTTPS in OpenID"...

On 02.01.2009, at 3:49, Martin Atkins wrote:
> Eric Norman wrote:
>> On Jan 1, 2009, at 6:40 PM, Martin Atkins wrote:
>>
>>> OpenID really needs a way to migrate from one identifier to another
>>> without breaking the connection to existing accounts.
>>
>> If RPs do indeed include the "http(s)://" as part of their
>> account identifiers, then yep, there's a migration problem.
>>
>> In any case, I suggest that y'all rethink the notion that
>> URLs that only differ by that "s" can represent different
>> entities.  I note that the above statement about what
>> OpenID needs makes an implicit assumption that such URLs
>> would represent the same entity.
>>
>
> Two URLs that differ only in that the scheme is https vs. http  
> *must* be
> considered to be different, otherwise any security benefits offered by
> using https are rendered ineffective. (You could just compromise the
> non-SSL version, ignoring the SSL version.)

I've never quite understood the security or inherent "trust" of the  
current PKI/HTTPS scheme. I know that most of the talk here is about  
average users and actual risks have been small in 2008 and are  
hopefully going to be small in 2009 as well, but the comforting signal  
of "no-no, everything is just fine, nothing to see here, no reason to  
worry, just pay more for EV certs and everything is magically going to  
be just fine" from the CA industry and some folks, remind me the  
(sorry for the comparison ... ) credit industry, which long tried to  
and suggested to fix the now "apparently fundamental problems in the  
financial system" with just more loan money. We all know what  
eventually happened...

A look back at 2008 suggests a following flow:

1. DNS poisoning or being on a rogue wifi network will move all  
traffic (either http or https) for example.com to badguy.com  
("Kaminsky DNS attack" http://it.slashdot.org/article.pl?sid=08/07/08/195225)
2. connecting software (browser/openid library) is OK with whatever is  
presented on the HTTP site (obvious reasons)
3. connecting software "security checks for PKI" are OK with whatever  
is presented on the HTTPS site because
  3a. Some dedicated badguy.com have forged a valid certificate for  
example.com ("MD5 certificate attack" http://it.slashdot.org/article.pl?sid=08%2F12%2F30%2F1655234)
  3b. Some "trusted" CA has issued a valid certificate for example.com  
("mozilla.com certificate from comodo attack" http://it.slashdot.org/article.pl?sid=08%2F12%2F23%2F0046258)
4. User is satisfied as there were no nagging popups where to press  
"OK" (!!!) to get into the site.

OpenID has long been accused in security problems. The answer from the  
community has been 1) No way! We build upon HTTPS-> we're definitely  
safe! 2) No way! Look, we have PAPE and you can have badass  
authentication!

We've had badass (NIST level 4 compatible) authentication since before  
PAPE even existed to carry the fact to the RP. Yet even now without  
manual checks at RP side for OP certificate(public key) fingerprints  
and related trust settings for the OP we (both OP and RP) would be as  
good as using rot13 plaintext passwords via HTTP.

In real life most end user software do not check for the status of a  
certificate (CRL/OCSP), there is no easy user control over the "trust  
list" ("trusted" CA-s in the system) and after all, most software does  
not care if if the site which used to present a valid EV certificate  
suddenly starts to present a "trusted" and valid certificate from  
"Russian Business Network CA, Signed by Comodo"...

I second here the questions often raised about CA-s by Peter Williams,  
but the community has managed to subtly ignore the topic. "If there is  
a problem (which we don't believe there is) then this is for the PKI/ 
TLS/HTTPS guys to fix", "Just pay to a big company for your certs",  
"Apparently we use whatever CA certificates Debian uses" are all signs  
of delegating the problem somewhere else.

For average joe and and average RP, the case remains the same -  
hopeless in the browser and other software. I liked the "This is not a  
trust system. Trust requires identity first." on the old openid.net  
page.
Yes, for average uses (the long tail of  the distribution for  
websites) OpenID does provide value as it reduces rot13 plaintext  
passwords and makes it a bit more complicated to post spam for  
example. But when it comes to addressing technical security/trust  
issues in OpenID, it suddenly is an open system where everything is  
possible or the problem does not concern OpenID directly. "Problem  
creep" pattern?

I'd like to copypaste from Bruce Schneier blog @ http://www.schneier.com/blog/archives/2008/12/forging_ssl_cer.html 
:

<copy>
But SSL doesn't provide much in the way of security, so breaking it  
doesn't harm security very much. Pretty much no one ever verifies SSL  
certificates, so there's not much attack value in being able to forge  
them.
...
If you're like me and every other user on the planet, you don't give a  
shit when an SSL certificate doesn't validate. Unfortunately, commons- 
httpclient was written by some pedantic fucknozzles who have never  
tried to fetch real-world webpages.
</copy>

In addition to "lets just do what everybody else is doing" OpenID  
could provide additional mechanisms. I once suggested having a  
separate configuration file and format for RP libraries to be able to  
configure white/blacklists and OP certificates/CA-s checksums and  
trust settings. This would raise the issue into OpenID space instead  
of relying on the host system for RP-s (dotnet using windows  
certstores, hosts without CA certificates installed, requirement to  
fiddle with curl options to make php library accept different  
certificates etc)

-- 
Martin Paljak
http://martin.paljak.pri.ee
+372.515.6495