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

[Martin Paljak]

On 02.01.2009, at 15:16, Eddy Nigg (StartCom Ltd.) wrote:

> 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.
Of course disclosure is good. But as you have interests in one CA I  
have to take your opinion as probably biased ;)


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

"Nothing to see here, move along, EV fixes everything". Yes -  
technically, within the boundaries set by the established CA business,  
everything is OK and will be even better with EV. But I try to  
question the existing, current approach of CA-s doing business under  
the name "trust business". CA-s should deal with certification and  
users should be dealing with trust issues and decisions. PKI as we  
know it now is not an implementation I like as a (loud minority) user.


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

There is. There is the possibly different mindset how people create  
software and services and educate others. Ranting is one tool for not  
letting it settle down as is. I'm sure that at some point if time  
slavery was the only viable option for some to get things done, yet we  
don't see that (in the same form at least) very much these days in the  
developed world.

>> 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?
Good question. As "you can do anything with OpenID" I believe it is  
left open - you can do whatever if you want if you consider it useful.



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