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

Fri Jan 2 13:16:20 UTC 2009

On 01/02/2009 11:08 AM, Martin Paljak:
> 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.
>    

Martin, failures and disclosing them serves the purpose to improve and 
prevent them. I'm responsible for disclosing one of the listed above, 
which however doesn't mean that public certification is a total failure. 
It speaks rather for the dedication and also the ability of the industry 
to control and improve itself.

The failure of a CA to perform validation correctly indeed compromises 
the ability to trust and rely on digital certification, that's the 
reason why it's being dealt with accordingly at different forums. Those 
validations are meant to prevent in case #1 happens.

Also the MD5 issue has been widely known and is hardly news anymore. For 
example the EV guidelines explicitly disallowed MD5 already for some 
time. The same would happen if OpenID would rely on such algorithm. This 
will happen many times over again as computing power improves and more 
research is done.

> 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"...
>    

It would be good if more software was capable to detect EV. The EV 
guidelines are the first time that CAs have a clear standard to follow 
and are audited accordingly. Even though I would have preferred a 
different approach than EV, it's not a bad thing as such. But even 
without EV, we (the security specialists, browser vendors and CAs) will 
do our due diligence to provide adequate and reasonable certification. 
Ranting and FUD will not help anything and there is no viable 
alternative right now widely adopted either.

> 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.
>    

Yes, the later is certainly not a professional approach and should be 
avoided.

> 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)
>    

But who will do that?

Regards
Signer: 	Eddy Nigg, StartCom Ltd. <http://www.startcom.org>
Jabber: 	startcom at startcom.org <xmpp:startcom at startcom.org>
Blog: 	Join the Revolution! <http://blog.startcom.org>
Phone: 	+1.213.341.0390

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20090102/a69c9848/attachment-0002.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6724 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20090102/a69c9848/attachment-0002.bin>