This is the second time in about three years that a IdP has had to revoke a certificate that was valid for there claimed_id, because it was compromised.
It points out some of the limitations of relying on TLS security. We should at least get people to take certificate revocation seriously to reduce the risk. For that we need to get the attention of library authors. I was taking the browser vendors claims of immediately blacklisting the certificates in new releases of Chrome, FF, and IE to prevent all sorts of other Phishing attacks as being something that could mitigate against man-in-the-middle involving the browser. Though you will probably point out the significant number of people who don't upgrade there browser for every security vulnerability or just prefer IE6 for some reason. I will attempt to bot be overly pessimistic and say that given that most of the non Google IdP default to non SSL, Google is now no worse off then them. I feel better already:) I am not particularly afraid of the ISP's themselves, but rather the security of there networks. This particular group of attackers was relatively competent. If I were them I would probably hack a router that my target RP connected to and redirect the traffic for https://www.google.com to a server of my choosing. Now it is highly likely that they will be more interested in attacking unpatched browsers and impersonating the login servers for these domains: Domain: mail.google.com [NOT seen live on the internet] Serial: 047ECBE9FCA55F7BD09EAE36E10CAE1E Domain: www.google.com [NOT seen live on the internet] Serial: 00F5C86AF36162F13A64F54F6DC9587C06 Domain: login.yahoo.com [Seen live on the internet] Serial: 00D7558FDAF5F1105BB213282B707729A3 Domain: login.yahoo.com [NOT seen live on the internet] Serial: 392A434F0E07DF1F8AA305DE34E0C229 Domain: login.yahoo.com [NOT seen live on the internet] Serial: 3E75CED46B693021218830AE86A82A71 Domain: login.skype.com [NOT seen live on the internet] Serial: 00E9028B9578E415DC1A710A2B88154447 Domain: addons.mozilla.org [NOT seen live on the internet] Serial: 009239D5348F40D1695A745470E1F23F43 Domain: login.live.com [NOT seen live on the internet] Serial: 00B0B7133ED096F9B56FAE91C874BD3AC0 Domain: global trustee [NOT seen live on the internet] Serial: 00D8F35F4EB7872B2DAB0692E315382FB0 I will also point out that this is not the only incident of issuing certificates to the wrong people that Comodo has been involved in. So the one thing we can do from a openID point of view is atleast take revocation seriously because I am willing to bet this will not be the last time something like this happens. John B. On 2011-03-25, at 6:29 AM, Ben Laurie wrote: > On 24 March 2011 17:19, John Bradley <[email protected]> wrote: >> The obvious vulnerability would be an attacker that knew some number of >> openId at a given RP, by spoofing DNS and SSL they could cain access to >> those accounts by setting up a Rogue IdP with the fraudulent SSL cert. >> This requires a DNS or routing venerability at the RP to be successful. > > Or a man-in-the-middle. > >> Not an easy attack. > > Rather depends who you are :-) Pretty easy for ISPs, for example. > >> However no attack is good. >> For the FICAM openID profile we required OCSP or CRL checking for RP to >> mitigate this risk. >> John B. >> On 2011-03-24, at 1:08 PM, Mike Hanson wrote: >> >> Thanks for the clarification, Phillip. >> m >> On Mar 24, 2011, at 10:06 AM, Phillip Hallam-Baker wrote: >> >> No login servers were affected. >> Several domains on which the servers are deployed were affected but not the >> login servers. >> >> >> On Thu, Mar 24, 2011 at 12:48 PM, Mike Hanson <[email protected]> wrote: >>> >>> Comodo has posted a detail incident report here: >>> http://www.comodo.com/Comodo-Fraud-Incident-2011-03-23.html >>> >>> Several login servers were affected. >>> >>> -MH >>> >>> >>> On Mar 24, 2011, at 7:09 AM, John Bradley wrote: >>> >>>> >>>> >>>> >>>> http://threatpost.com/en_us/blogs/phony-ssl-certificates-issued-google-yahoo-skype-others-032311?utm_source=Threatpost&utm_medium=Tabs&utm_campaign=Today%27s+Most+Popular >>>> >>>> The browser venders blocking those certificates is nice, however there >>>> are attacks on RP that could be done with those certificates that are still >>>> open. >>>> >>>> In testing something like 0% of RP check OCSP or CRL, the libs don't >>>> force openSSL to so those checks (I think DNOA will do them in FICAM mode) >>>> >>>> So perhaps encouraging people to perform those checks would be a good >>>> idea. >>>> >>>> We can only hope that none of the 9 certificates cover openID OP, >>>> otherwise user accounts at RP could theoretically be compromised. >>>> >>>> John B. >>>> >>>> >>>> _______________________________________________ >>>> security mailing list >>>> [email protected] >>>> http://lists.openid.net/mailman/listinfo/openid-security >>> >>> _______________________________________________ >>> security mailing list >>> [email protected] >>> http://lists.openid.net/mailman/listinfo/openid-security >> >> >> >> -- >> Website: http://hallambaker.com/ >> >> >> >> >> _______________________________________________ >> security mailing list >> [email protected] >> http://lists.openid.net/mailman/listinfo/openid-security >> >>
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ security mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-security
