Pontus Engblom | DigiSSL AB dixit: >I would like to inform you that when you get a service you tend to >read the FAQs and Certificate Policy Statements, i.e StartSSL have a >FAQ where a whole bunch of numbers concern revocation and handling fees. >http://www.startssl.com/?app=25#72 >(#70 to #74). So please do not claim they do not clearly state it, >either you didn't read or didn't care to read.
They apparently changed this practice sometime in between. People who signed up for their service years ago did not have any “handling fee” for revocations. >Now they do not charge the certificate in anyway for revocation, it's >merely a handling fee, i.e the guys that work there need to get paid >to do their job. I do not disagree with people needing to get their money. I’d happily pay 5 € for certificates, and possibly a handling fee for a revocation “on my whim”, but not acting in the face of a security breach like this one is inacceptable (and, as Rob Stradling pointed out, a violation of their obligations). >I can agree that some certificates _MIGHT_ be compromised and need No. We must assume that all private keys ever used in vulnerable systems have been compromised; there is evidence that this has been exploited as early as November 2013. >revocation, but as StartSSL stated earlier, if you got no intention of >paying $24.90 you could also create a _NEW_ certificate with a >different subdomain and replace yours, that would cost you.. nothing? This would help absolutely nobody because the attacker *still* can use the private key (which they stole from you) and the StartCom-signed certificate (which they get during the handshake anyway) to do an MITM attack on your visitors, with StartCom saying that the MITM attacker is “the genuine thing”. The only option is, for example, if you have www.foo.org as StartCom certificate, to remove A and AAAA records for both www.foo.org. and foo.org. from the DNS, and get a certificate for www2.foo.org – good luck getting any traffic there. And even then, an attacker can just redirect their target’s DNS, making the attack once again successful. No, no matter what, those StartCom/StartSSL-issued certificates *must* be revoked, or StartCom/StartSSL *must* be removed from the trusted root store, no later than this Friday. >But I can not for the life of me see why we can't pay $24.90, they >have given us a service for free and now when we need to do something >we think its wrong of them to charge us? Compare it to the real world, It’s an obligation. CAs have an oligopoly and as such, they have certain social responsibilities, for the good of the SSL ecosy- stem as a whole. >Also this is issue is quite hard to handle, it is unknown how many >certs that actually have been compromised since it's not traceable. All certificates that have been in use on systems running OpenSSL 1.x versions since the introduction of the bug and before its fix, even if only for a fraction of a second. >> ... - the CA obtains _reasonable evidence_ that the subscriber’s >private key (corresponding to the public key in the certificate) has >been compromised or is _suspected of compromise_ (e.g. Debian weak keys)" > >This is a bit of an issue here, we don't know whom might have been >targeted with this bug, I find it hard that low traffic domains could We must assume everyone has been compromised, by now. Please see my messages to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=744027 and https://bugzilla.mozilla.org/show_bug.cgi?id=994033 for sources. >have been compromised but theres a possibility, in this case there is >no way to get reasonable evidence of a subscriber loosing its private >key. And to suspect every cert has been compromised well, then all CAs >would need to make a huge CRL and pretty much revoke any certificate Yes. (It would probably be easier to reboot the system…) But for all we know, they need to act. (Note that I am currently running a StartCom certificate that was never compromised (due to only using OpenSSL 0.x) on one system, a compromised one (which they refuse to revoke) on another system, and a healthy mix of GoDaddy-rekeyed ones on most other systems.) >> If the servers in your SSL environment do not use OpenSSL, if your >servers >> use OpenSSL 1.0.0 or earlier, if your servers do not use OpenSSL >> 1.0.2-beta1, or if your servers are compiled without the heartbeat >extension >> enabled, then your environment is not vulnerable to the Heartbleed >> Bug attack. Right, there’s still two years of certificates, and a stable release of Debian, two releases of OpenBSD, and other OSes, to cover. Since responsible admins would contact StartCom and ask for rekey/revoke Right Now™ (or after getting back from vacation, i.e. this month, probably), it would not be bad for them to waive their fees this month to people citing this vulnerability. Just revoking *every* certificate is probably a bit too much. The important thing is to do that *right now*, and issue a statement that they accept their responsibility for the ecosystem and will waive fees for everyone affected. (I fully understand they will want handling fees for “at-will” revocals normally. But this is an exceptional situation!) >To actually have a chance here as a CA you would need to contact every >certificate holder and get their SSL environment. Most servers usually You cannot access every SSL system. Things like firewalls exist. >But as a end here, try to get a new certificate for a new subdomain if >you can not pay $25. Or actually start to pay for SSL from the first This does not change the fact that there are already-compromised keys and certificates signed by a trusted CA out there, waiting to be used (or already being used, who knows?) by attackers to fraud by pretending false identities. >cost. IMHO this removing of StartCom is just bogus. Maybe that Mozilla Are you speaking for DigiSSL AB here, or just privately? bye, //mirabilos -- <diogenese> Beware of ritual lest you forget the meaning behind it. <igli> yeah but it means if you really care about something, don't ritualise it, or you will lose it. don't fetishise it, don't obsess. or you'll forget why you love it in the first place. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
