Link for blog article doesn't work. So, there is any way to remove compromised part of certificate, without removing whole Comodo root?

It's taken the trailing bracket as part of the url - try this.

There isn't any compromised "part". Some certificates were fraudulently signed, and they've since been revoked (and, as far as I'm aware, have never actually been seen in use). If the browser is handling the CRLs properly then the certificates will be flagged as invalid. The only level above this is to flag the issuing certificate as invalid, in which case you automatically distrust every single certificate they have issued (or will issue in future). In the case of the large CAs (like Comodo) this is just not a workable option.

Admittedly, this is not an ideal solution and there are lots of people talking about replacements for the current SSL setup. Unfortunately nobody seems to have come up with a solution that's acceptable.

Hi, all!

Sorry for being silent so long. I am the maintainer of the maemo-security-certman package which should be updated to fix this problem.

First of all, the "cmcli -c common-ca -r 88..." command as root is the proper way to remove the DigiNotar CA. Just removing the certificate from from /etc/certs/common-ca may cause browser crashes because of bug https://bugs.maemo.org/show_bug.cgi?id=10423. Sorry about that.

Unfortuntately that is not enough. Besides their own root DigiNotar has also several intermediate signing certificates issued by other CAs, and these have also been used to create fraudulent certificates. The Fox IT's report at http://www.rijksoverheid.nl/document...version-1.html gives an idea of what happened.

Certificate revocation does not really work because DigiNotar does not even know the serial numbers of all the fraudulent certificates. Also removing all the roots the intermediate signing certificates are based on would be a bit drastic.

Mozilla mitigated the problem by adding special blocker certificates in their built-in certificate store. These are fake self-signed certificates that have the same subject name than the compromised intermediate CAs with an explicit "do not trust" setting. When doing validation the browser stops if anywhere in the trust chain a match is found. Check out Mozilla bug https://bugzilla.mozilla.org/show_bug.cgi?id=683261 for technical details. They first did this last April with the Comodo breach and Sep 2nd they added five DigiNotar certificates, including the root.

In Maemo 5 the browser does not use the built-in certificates but the container library is replaced by another PKCS#11 module which maps to the system certificate store. This is how certificates added by the Settings -> Certificates applet are made visible to the browser and the e-mail.

There is now a Maemo bug 12379 for a similar blacklisting mechanism in N900. A working implementation can be found from https://gitorious.org/maemo-5-certif...curity-certman. The new version 0.2.0 also adds the new roots from the Mozilla set added since Oct 2010, removes expired roots, fixes the browser crasher 10423 and a couple of other nasty bugs. I have tested it in two devices, one with a pristine PR1.3 (2010.36-2) image and another with all the community udpates added. It seems not to break anything and blocks sites that have any of the blacklisted certificates in the trust chain. At the time of writing this for instance https://sha2.diginotar.nl.

I'm currently looking into ways of getting the new version integrated. If Nokia will not make any more system updates then the package should be included in the next community SSU at least.

Meanwhile, if anyone is interested in testing the fix by building and installing the related packages manually that would be great. Please contact me directly at juhani dot makela at asiaa dot fi if you need help of how to do that. If any regressions are found please report them to bugzilla or to me directly.

And one more piece of information. To implement a man-in-the-middle with https the attacker has to be able to do two things: acquire a valid-looking certificate for the target site and route the victim's traffic to his site, usually by some kind of a DNS spoofing or cache poisoning. The latter may be easy or hard depending on the connection. If the attacker controls some part of the network (for instance the WiFi access point you are using) it is trivial, on the other hand for instance in the 3G network it is very hard. Avoiding open WiFi at the time being might be a good idea, although there are reasons to believe that the area in which such attacks are probable is geographically limited: http://blog.trendmicro.com/diginotar...he-real-target

Cheers, JuM

@juhanima - will you please join #maemo-ssu to further discuss how this could be delivered to users

I'm terribly sorry but I don't do IM, so we'll have to sort this out via e-mail. I was planning to send mail to council@maemo.org as soon as Nokia's plan is clear anyway.

If we're going to do that over e-mail can it be on the maemo-developers mailing list, rather than the council's "private"(?) email?

If one has Iranian friends or friends who have connections to Iran, it would be a good move to warn them, if they don't know this stuff already!

See also:
http://www.h-online.com/security/new...s-1341842.html

And the next one seems to be SSL:
"Hackers break SSL encryption used by millions of sites"
http://www.theregister.co.uk/2011/09...ts_paypal_ssl/

Well let's wait for the "proof-of-concept code called BEAST".

Damn, it seems that fix for it will require browser update As bugging Nokia to implement it is totally hopeless, I guess we'll need a Open source browser replacement in some point of future... Using Iceweasel via Easy Debian may be workaround, but I'm not sure about it, cause never version of Iceweasel - addressing issues - may require gconf2 update. And ever if - somehow - we may force it to work, it's hardly a solution.

According to the Chrome developers, the issue has been rather overblown by the press, and there's really not anything to get worried about.

A "proper" fix will require both browser and server updates (which are completely out of our hands), but they've put a browser-only fix into Chrome which supposedly will dramatically reduce the risk (if not prevent it altogether).