Debian Bug report logs - #744027

Please remove StartCom Certification Authority root certificate

Reported by: Klemens Baum <klemensbaum@gmail.com> Date: Wed, 9 Apr 2014 13:09:01 UTC Severity: normal Tags: fixed-upstream, wontfix Done: Michael Shuler <michael@pbandjelly.org> Bug is archived. No further changes may be made. Forwarded to https://bugzilla.mozilla.org/show_bug.cgi?id=994033

Toggle useless messages

Report forwarded to debian-bugs-dist@lists.debian.org, Michael Shuler <michael@pbandjelly.org> :

Bug#744027 ; Package ca-certificates . (Wed, 09 Apr 2014 13:09:06 GMT) (full text, mbox, link).

Acknowledgement sent to Klemens Baum <klemensbaum@gmail.com> :

New Bug report received and forwarded. Copy sent to Michael Shuler <michael@pbandjelly.org> . (Wed, 09 Apr 2014 13:09:06 GMT) (full text, mbox, link).

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Klemens Baum <klemensbaum@gmail.com> To: submit@bugs.debian.org Subject: Please remove StartCom Certification Authority root certificate Date: Wed, 9 Apr 2014 15:07:08 +0200

Package: ca-certificates Following the OpenSSL CVE-2014-0160 "Heartbleed" vulnerability [1,2], any certificate that was used with an vulnerable version of OpenSSL (I read somewhere 1/3 of the web) should be handled as it is compromised. Compromised certificates have to be replaced with new ones (new keys) and the old ones should be revoked. StartCom provides cheap and even free SSL certificates via the StartSSL brand. However, certificates revoking cerificates requires a US$ 24.90 fee [3]. This discourages responsible sysadmin procedure and and will ensure many compromised certificates remain in use. As a consequence you can't trust certificates signed by StartCom before 2014-04-07. Solution 1: StartCom should revoke affected certs. (unlikely[4-6]) Solution 2: StartCom should be removed from the truststore. See also: https://bugzilla.mozilla.org/show_bug.cgi?id=994033 [1] https://www.openssl.org/news/secadv_20140407.txt [2] http://heartbleed.com/ [3] http://www.startssl.com/?app=25#72 [4] https://news.ycombinator.com/item?id=7557764 [5] https://twitter.com/startssl/status/453583493386485760 [6] https://twitter.com/startssl/status/453631038883758080 Solution 2: StartCom should be removed from the truststore.

Information forwarded to debian-bugs-dist@lists.debian.org :

Bug#744027 ; Package ca-certificates . (Wed, 09 Apr 2014 13:42:12 GMT) (full text, mbox, link).

Acknowledgement sent to Michael Shuler <michael@pbandjelly.org> :

Extra info received and forwarded to list. (Wed, 09 Apr 2014 13:42:12 GMT) (full text, mbox, link).

Message #10 received at 744027@bugs.debian.org (full text, mbox, reply):

From: Michael Shuler <michael@pbandjelly.org> To: 744027@bugs.debian.org Cc: Klemens Baum <klemensbaum@gmail.com> Subject: Re: Bug#744027: Please remove StartCom Certification Authority root certificate Date: Wed, 09 Apr 2014 08:39:25 -0500

Control: forwarded -1 https://bugzilla.mozilla.org/show_bug.cgi?id=994033 On 04/09/2014 08:07 AM, Klemens Baum wrote: > Following the OpenSSL CVE-2014-0160 "Heartbleed" vulnerability [1,2], > any certificate that was used with an vulnerable version of OpenSSL (I > read somewhere 1/3 of the web) should be handled as it is compromised. > > Compromised certificates have to be replaced with new ones (new keys) > and the old ones should be revoked. > > StartCom provides cheap and even free SSL certificates via the > StartSSL brand. However, certificates revoking cerificates requires a > US$ 24.90 fee [3]. This discourages responsible sysadmin procedure and > and will ensure many compromised certificates remain in use. As a > consequence you can't trust certificates signed by StartCom before > 2014-04-07. > > Solution 1: StartCom should revoke affected certs. (unlikely[4-6]) > > Solution 2: StartCom should be removed from the truststore. If mozilla believes this is justification for removal, which I doubt will happen, then the same will happen in ca-certificates. Debian ca-certificates users may remove trust locally at any time, if they desire. > See also: https://bugzilla.mozilla.org/show_bug.cgi?id=994033 Marking this as the upstream bug report. > [1] https://www.openssl.org/news/secadv_20140407.txt > [2] http://heartbleed.com/ > [3] http://www.startssl.com/?app=25#72 > [4] https://news.ycombinator.com/item?id=7557764 A user comment here says the CVE was cited, and StartSSL waived the revocation fee. > [5] https://twitter.com/startssl/status/453583493386485760 > [6] https://twitter.com/startssl/status/453631038883758080 -- Kind regards, Michael

Set Bug forwarded-to-address to 'https://bugzilla.mozilla.org/show_bug.cgi?id=994033'. Request was from Michael Shuler <michael@pbandjelly.org> to 744027-submit@bugs.debian.org . (Wed, 09 Apr 2014 13:42:12 GMT) (full text, mbox, link).

Information forwarded to debian-bugs-dist@lists.debian.org, Michael Shuler <michael@pbandjelly.org> :

Bug#744027 ; Package ca-certificates . (Wed, 09 Apr 2014 13:51:20 GMT) (full text, mbox, link).

Acknowledgement sent to Thijs Kinkhorst <thijs@debian.org> :

Extra info received and forwarded to list. Copy sent to Michael Shuler <michael@pbandjelly.org> . (Wed, 09 Apr 2014 13:51:20 GMT) (full text, mbox, link).

Message #17 received at 744027@bugs.debian.org (full text, mbox, reply):

From: Thijs Kinkhorst <thijs@debian.org> To: Klemens Baum <klemensbaum@gmail.com> Cc: 744027@bugs.debian.org Subject: Re: Bug#744027: Please remove StartCom Certification Authority root certificate Date: Wed, 9 Apr 2014 15:48:56 +0200

Op woensdag 9 april 2014 15:07:08 schreef Klemens Baum: > Package: ca-certificates > > Following the OpenSSL CVE-2014-0160 "Heartbleed" vulnerability [1,2], > any certificate that was used with an vulnerable version of OpenSSL (I > read somewhere 1/3 of the web) should be handled as it is compromised. > > Compromised certificates have to be replaced with new ones (new keys) > and the old ones should be revoked. > > StartCom provides cheap and even free SSL certificates via the > StartSSL brand. However, certificates revoking cerificates requires a > US$ 24.90 fee [3]. Whatever you and I think of this pricing structure, people free to chose any provider of certificates that matches their pricing interest and that people are knowingly or should be knowlingly buying a product that has a certain price structure when they get the certificates in the first place. Revoking a certificate is generally primarily in the interest of the owner of said certificate so there is incentive to actually pay this fee. I do not believe it is Debian's place to pass judgement on which pricing scheme people should prefer, even if you and I personally rather pay up front and have no costs on revocation. Cheers, Thijs

Information forwarded to debian-bugs-dist@lists.debian.org, Michael Shuler <michael@pbandjelly.org> :

Bug#744027 ; Package ca-certificates . (Wed, 09 Apr 2014 18:27:07 GMT) (full text, mbox, link).

Acknowledgement sent to David Wilson <dw@botanicus.net> :

Extra info received and forwarded to list. Copy sent to Michael Shuler <michael@pbandjelly.org> . (Wed, 09 Apr 2014 18:27:07 GMT) (full text, mbox, link).

Message #22 received at 744027@bugs.debian.org (full text, mbox, reply):

From: David Wilson <dw@botanicus.net> To: 744027@bugs.debian.org Date: Wed, 9 Apr 2014 19:22:43 +0100

It's worth bearing in mind that a leaked private key has so far not been reproducible on Debian, only for first request on specific configurations of FreeBSD. Following from that, it is really questionable whether such mass certificate compromises have really happened, and whether removal of Startcom CA would have any quantifiable benefit. I believe the onus is on the bug submitter to demonstrate such a compromise has occurred before this request should be seriously considered.

Information forwarded to debian-bugs-dist@lists.debian.org, Michael Shuler <michael@pbandjelly.org> :

Bug#744027 ; Package ca-certificates . (Wed, 09 Apr 2014 19:12:14 GMT) (full text, mbox, link).

Acknowledgement sent to Jan Niehusmann <jan@gondor.com> :

Extra info received and forwarded to list. Copy sent to Michael Shuler <michael@pbandjelly.org> . (Wed, 09 Apr 2014 19:12:14 GMT) (full text, mbox, link).

Message #27 received at 744027@bugs.debian.org (full text, mbox, reply):

From: Jan Niehusmann <jan@gondor.com> To: 744027@bugs.debian.org Subject: Re: Bug#744027: Please remove StartCom Certification Authority root certificate Date: Wed, 9 Apr 2014 20:47:50 +0200

On Wed, Apr 09, 2014 at 03:48:56PM +0200, Thijs Kinkhorst wrote: > Whatever you and I think of this pricing structure, people free to chose any > provider of certificates that matches their pricing interest and that people > are knowingly or should be knowlingly buying a product that has a certain > price structure when they get the certificates in the first place. Well, the fee was not prominently advertised. And as revocations were free a few years ago[1], even reading all the terms and conditions back then wouldn't have helped. Or is one expected actively search for new fees in the FAQ when refreshing a certificate? (Please note that I'm not arguing that the CA should be removed - just that the argument that people knowingly chose that pricing structure may be invalid.) Regards, Jan [1] https://cv.exbit.io/emails/startssl_heartbeat.txt

Information forwarded to debian-bugs-dist@lists.debian.org, Michael Shuler <michael@pbandjelly.org> :

Bug#744027 ; Package ca-certificates . (Wed, 09 Apr 2014 19:57:10 GMT) (full text, mbox, link).

Acknowledgement sent to Raphael Geissert <geissert@debian.org> :

Extra info received and forwarded to list. Copy sent to Michael Shuler <michael@pbandjelly.org> . (Wed, 09 Apr 2014 19:57:10 GMT) (full text, mbox, link).

Message #32 received at 744027@bugs.debian.org (full text, mbox, reply):

From: Raphael Geissert <geissert@debian.org> To: 744027@bugs.debian.org Cc: Klemens Baum <klemensbaum@gmail.com> Subject: Re: Bug#744027: Please remove StartCom Certification Authority root certificate Date: Wed, 9 Apr 2014 21:54:18 +0200

Control: tag -1 wontfix On Wednesday 09 April 2014 15:39:25 Michael Shuler wrote: [...] > If mozilla believes this is justification for removal, which I doubt > will happen, then the same will happen in ca-certificates. Debian > ca-certificates users may remove trust locally at any time, if they > desire. Agreed, so marking it as wontfix. If anything changes upstream, it will be reflected here. For those reading at home don't waste your time, nor ours, sending arguments or "+1"s. If anywhere, do it on mozilla's bugzilla - all the while respecting their policies. Cheers, -- Raphael Geissert - Debian Developer www.debian.org - get.debian.net

Added tag(s) wontfix. Request was from Raphael Geissert <geissert@debian.org> to 744027-submit@bugs.debian.org . (Wed, 09 Apr 2014 19:57:11 GMT) (full text, mbox, link).

Information forwarded to debian-bugs-dist@lists.debian.org, Michael Shuler <michael@pbandjelly.org> :

Bug#744027 ; Package ca-certificates . (Wed, 09 Apr 2014 20:09:09 GMT) (full text, mbox, link).

Acknowledgement sent to Geoffrey Thomas <geofft@ldpreload.com> :

Extra info received and forwarded to list. Copy sent to Michael Shuler <michael@pbandjelly.org> . (Wed, 09 Apr 2014 20:09:09 GMT) (full text, mbox, link).

Message #39 received at 744027@bugs.debian.org (full text, mbox, reply):

From: Geoffrey Thomas <geofft@ldpreload.com> To: Klemens Baum <klemensbaum@gmail.com> Cc: 744027@bugs.debian.org Subject: Re: Please remove StartCom Certification Authority root certificate Date: Wed, 9 Apr 2014 12:55:31 -0700 (PDT)

On Wed, 9 Apr 2014, Klemens Baum wrote: > StartCom provides cheap and even free SSL certificates via the > StartSSL brand. However, certificates revoking cerificates requires a > US$ 24.90 fee [3]. This discourages responsible sysadmin procedure and > and will ensure many compromised certificates remain in use. I don't believe that any browser or HTTPS client in Debian checks revocations with hard failures if the CRL or OCSP responder is unreachable, so I don't see how this is relevant for decisions regarding Debian's default trust store. The certificate will (it seems) get reissued for free with a new key, so the compromised certificate will not be in use. And an attacker in a position to MITM is also in a position to make the revocation useless: https://news.ycombinator.com/item?id=7556909 https://www.imperialviolet.org/2012/02/05/crlsets.html https://twitter.com/agl__/status/453602748601495553 Multiple commentors on the HN thread you link to imply that StartCom is happy to reissue certs for free, but they charge for revocations, for instance: "The title is misleading. StartCom is asking for its fee for revoking, that's all. Not making revocation free of cost isn't refusal to reissue cert." If they were charging for reissues, there might be an argument here, but even if they didn't do revocations at all, I don't see how that affects security under the threat model used by the Debian packages that use on ca-certificates. > As a consequence you can't trust certificates signed by StartCom before > 2014-04-07. This only affects certs that were used on vulnerable versions of OpenSSL with allocation schemes that actually loaded the private key into freed memory that could be returned. I haven't seen a valid claim that this is anywhere near a significant fraction of the web. http://blog.erratasec.com/2014/04/why-heartbleed-doesnt-leak-private-key.html https://twitter.com/neelmehta/status/453625474879471616 -- Geoffrey Thomas https://ldpreload.com geofft@ldpreload.com

Information forwarded to debian-bugs-dist@lists.debian.org, Michael Shuler <michael@pbandjelly.org> :

Bug#744027 ; Package ca-certificates . (Wed, 09 Apr 2014 21:06:08 GMT) (full text, mbox, link).

Acknowledgement sent to Joey Hess <joeyh@debian.org> :

Extra info received and forwarded to list. Copy sent to Michael Shuler <michael@pbandjelly.org> . (Wed, 09 Apr 2014 21:06:08 GMT) (full text, mbox, link).

Message #44 received at 744027@bugs.debian.org (full text, mbox, reply):

From: Joey Hess <joeyh@debian.org> To: 744027@bugs.debian.org Subject: data point Date: Wed, 9 Apr 2014 17:01:30 -0400

StartSSL revoked one of my certs on request the night Heartbleed came out. I mentioned heartbleed in the form. However, that was a $24.90 gamble.. They could just has easily billed me. Especially if you have a lot of different certs, that gamble may not be worth it. Also, I'm a paying customer, having gone through their process to get a wildcard cert. A free customer may have different results. And then, browsers don't check SSL cert revocations, and the infrastructure to check reovocations is apparently broken too. So this is a gamble with not much of a payoff. I would be quite happy if Debian came with a way to say: "I don't trust any cert created before heartbleed was announced." -- see shy jo

Information forwarded to debian-bugs-dist@lists.debian.org, Michael Shuler <michael@pbandjelly.org> :

Bug#744027 ; Package ca-certificates . (Wed, 09 Apr 2014 21:27:04 GMT) (full text, mbox, link).

Acknowledgement sent to Kurt Roeckx <kurt@roeckx.be> :

Extra info received and forwarded to list. Copy sent to Michael Shuler <michael@pbandjelly.org> . (Wed, 09 Apr 2014 21:27:04 GMT) (full text, mbox, link).

Message #49 received at 744027@bugs.debian.org (full text, mbox, reply):

From: Kurt Roeckx <kurt@roeckx.be> To: Joey Hess <joeyh@debian.org>, 744027@bugs.debian.org Subject: Re: Bug#744027: data point Date: Wed, 9 Apr 2014 23:25:18 +0200

On Wed, Apr 09, 2014 at 05:01:30PM -0400, Joey Hess wrote: > > And then, browsers don't check SSL cert revocations, and the infrastructure to > check reovocations is apparently broken too. The major browser do check OCSP, but they do not import CRLs. The CAs are supposed to be providing OCSP. However, iceweasel/firefox by default is happy to ignore a OCSP timeout. You need to turn it on that it doesn't allow a timeout. I have no idea why they use that as default. You can change it in edit -> preferences -> advanced -> certificates -> validation: check both boxes. I think by default only the first is checked. Kurt

Information forwarded to debian-bugs-dist@lists.debian.org, Michael Shuler <michael@pbandjelly.org> :

Bug#744027 ; Package ca-certificates . (Wed, 09 Apr 2014 21:39:04 GMT) (full text, mbox, link).

Acknowledgement sent to Raphael Geissert <geissert@debian.org> :

Extra info received and forwarded to list. Copy sent to Michael Shuler <michael@pbandjelly.org> . (Wed, 09 Apr 2014 21:39:04 GMT) (full text, mbox, link).

Message #54 received at 744027@bugs.debian.org (full text, mbox, reply):

From: Raphael Geissert <geissert@debian.org> To: Joey Hess <joeyh@debian.org>, 744027@bugs.debian.org Subject: Re: Bug#744027: data point Date: Wed, 9 Apr 2014 23:37:03 +0200

On Wednesday 09 April 2014 23:01:30 Joey Hess wrote: [...] > So this is a gamble with not much of a payoff. The payoff is a certificate that is more likely not to have been compromised, and one that is signed by your CA. > I would be quite happy if Debian came with a way to say: > "I don't trust any cert created before heartbleed was announced." Can be done if you hack X509_verify and equivalent functions when they check the validity of the certificate. Not that I suggest that I am going to implement it or that I would be in favor of such a check. I believe that it would be an overreaction. Cheers, -- Raphael Geissert - Debian Developer www.debian.org - get.debian.net

Information forwarded to debian-bugs-dist@lists.debian.org, Michael Shuler <michael@pbandjelly.org> :

Bug#744027 ; Package ca-certificates . (Thu, 10 Apr 2014 01:27:04 GMT) (full text, mbox, link).

Acknowledgement sent to Geoffrey Thomas <geofft@ldpreload.com> :

Extra info received and forwarded to list. Copy sent to Michael Shuler <michael@pbandjelly.org> . (Thu, 10 Apr 2014 01:27:04 GMT) (full text, mbox, link).

Message #59 received at 744027@bugs.debian.org (full text, mbox, reply):

From: Geoffrey Thomas <geofft@ldpreload.com> To: Kurt Roeckx <kurt@roeckx.be> Cc: Joey Hess <joeyh@debian.org>, 744027@bugs.debian.org Subject: Re: Bug#744027: data point Date: Wed, 9 Apr 2014 18:22:10 -0700 (PDT)

On Wed, 9 Apr 2014, Kurt Roeckx wrote: > However, iceweasel/firefox by default is happy to ignore a OCSP > timeout. You need to turn it on that it doesn't allow a timeout. > I have no idea why they use that as default. Because it's an easy DoS if an attacker is in a position to MITM the connection between you and the OCSP service (or CRL file), no? And if the attacker can MITM the connection between you and the SSL service you're trying to talk to, they can probably also MITM the OCSP or CRL server. Also (as Adam Langley points out in the stuff I linked to earlier in this bug report) the OCSP servers risk becoming a single point of failure if you do that. If a CA's OCSP server is down, everything they sign becomes inaccessible. That would be a bad default, and probably not something you want to turn on for yourself either. Also also, http://www.thoughtcrime.org/papers/ocsp-attack.pdf which appears to be still valid with Firefox at least: https://bugzilla.mozilla.org/505812 So there's really no value at all in using OCSP, it seems. -- Geoffrey Thomas https://ldpreload.com geofft@ldpreload.com

Information forwarded to debian-bugs-dist@lists.debian.org, Michael Shuler <michael@pbandjelly.org> :

Bug#744027 ; Package ca-certificates . (Thu, 10 Apr 2014 12:12:07 GMT) (full text, mbox, link).

Acknowledgement sent to Thorsten Glaser <t.glaser@tarent.de> :

Extra info received and forwarded to list. Copy sent to Michael Shuler <michael@pbandjelly.org> . (Thu, 10 Apr 2014 12:12:07 GMT) (full text, mbox, link).

Message #64 received at 744027@bugs.debian.org (full text, mbox, reply):

From: Thorsten Glaser <t.glaser@tarent.de> To: Geoffrey Thomas <geofft@ldpreload.com> Cc: Klemens Baum <klemensbaum@gmail.com>, 744027@bugs.debian.org Subject: Re: Please remove StartCom Certification Authority root certificate Date: Thu, 10 Apr 2014 14:09:57 +0200 (CEST)

On Wed, 9 Apr 2014, Geoffrey Thomas wrote: > This only affects certs that were used on vulnerable versions of OpenSSL with > allocation schemes that actually loaded the private key into freed memory that > could be returned. I haven't seen a valid claim that this is anywhere near a > significant fraction of the web. > > http://blog.erratasec.com/2014/04/why-heartbleed-doesnt-leak-private-key.html Note that this has been updated by now. See also: Update: Errata Security's Robert Graham [12]has acknowledged that he was mistaken in his assessment, and that private keys could be at risk. The original story below has been marked up accordingly. […] In [17]a post to the Errata Security blog, Robert Graham explained that it is highly unlikely that private key data would be stored in the memory buffer that could be leaked using the Heartbleed exploit. “What you can eavesdrop on with Heartbleed hacks is dynamic stuff, stuff that was allocated only moments ago,” he wrote. But that assertion has been refuted, and Graham has since rescinded it, as noted above. […] Terrence Koeman of MediaMonks told Ars he found signs of attempts to use the exploit dating back to November 2013. He used the packet content of a successful exploit of the Heartbleed vulnerability to check inbound packets logged by his servers and found a number of incoming packets from a network suspected of harboring a number of “bot” servers that were apparently scans for the vulnerability—sending Heartbleed-style requests to two different development servers in requests that were about five minutes apart. [12] https://twitter.com/julianor/status/454015858042757120 By now, we must assume that private key material *can* have been leaked, and that this was being exploited five months ago already. bye, //mirabilos -- «MyISAM tables -will- get corrupted eventually. This is a fact of life. » “mysql is about as much database as ms access” – “MSSQL at least descends from a database” “it's a rebranded SyBase” “MySQL however was born from a flatfile and went downhill from there” – “at least jetDB doesn’t claim to be a database” ‣‣‣ Please, http://deb.li/mysql and MariaDB, finally die!

Information forwarded to debian-bugs-dist@lists.debian.org, Michael Shuler <michael@pbandjelly.org> :

Bug#744027 ; Package ca-certificates . (Thu, 10 Apr 2014 14:45:04 GMT) (full text, mbox, link).

Acknowledgement sent to Thorsten Glaser <tg@mirbsd.de> :

Extra info received and forwarded to list. Copy sent to Michael Shuler <michael@pbandjelly.org> . (Thu, 10 Apr 2014 14:45:04 GMT) (full text, mbox, link).

Message #69 received at 744027@bugs.debian.org (full text, mbox, reply):

From: Thorsten Glaser <tg@mirbsd.de> To: Walter Goulet <wgoulet@gmail.com> Cc: mozilla-dev-security-policy@lists.mozilla.org Subject: Re: Revocation Policy Date: Thu, 10 Apr 2014 14:38:45 +0000 (UTC)

Walter Goulet dixit: >offering. I personally have not yet decided if I will indeed revoke, You *must* revoke. http://arstechnica.com/security/2014/04/heartbleed-vulnerability-may-have-been-exploited-months-before-patch/ not only shows that this has been exploited since November, but also contains a comment from the guy who said “don’t panic, it is unlikely that private keys have leaked” yesterday, correcting himself. See also: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=744027 ObAmusing: switching to other implementations? Nope. OpenSSL, NSS and the Java™ crowd are the only ones to mostly get it right. http://pbs.twimg.com/media/Bk0DY8XCEAAPpS7.png:large bye, //mirabilos -- <Natureshadow> Warum ist MirWebseite eigentlich so cool? <mirabilos> weil ich ich sie geschrieben habe <Natureshadow> Hast du sie geschrieben oder geforkt? <mirabilos> geschrieben, from scratch <Natureshadow> Ach, deshalb finde ich auch so selten Bugs dadrin. Irgendwie hast du Recht.

Information forwarded to debian-bugs-dist@lists.debian.org, Michael Shuler <michael@pbandjelly.org> :

Bug#744027 ; Package ca-certificates . (Thu, 10 Apr 2014 15:09:08 GMT) (full text, mbox, link).

Acknowledgement sent to Raphael Geissert <geissert@debian.org> :

Extra info received and forwarded to list. Copy sent to Michael Shuler <michael@pbandjelly.org> . (Thu, 10 Apr 2014 15:09:08 GMT) (full text, mbox, link).

Message #74 received at 744027@bugs.debian.org (full text, mbox, reply):

From: Raphael Geissert <geissert@debian.org> To: Thorsten Glaser <tg@mirbsd.de>, 744027@bugs.debian.org Cc: Walter Goulet <wgoulet@gmail.com>, mozilla-dev-security-policy@lists.mozilla.org Subject: Re: Bug#744027: Revocation Policy Date: Thu, 10 Apr 2014 17:05:59 +0200

On 10 April 2014 16:38, Thorsten Glaser <tg@mirbsd.de> wrote: > http://pbs.twimg.com/media/Bk0DY8XCEAAPpS7.png:large You can not expect an implementation that doesn't provide key usage checks to, well, check key usage. That said, even if for instance OpenSSL supports them, applications must tell the library what they want it to check for. From a previous look at the openssl-using applications in Debian, those cases are rare. Cheers, -- Raphael Geissert - Debian Developer www.debian.org - get.debian.net

Information stored :

Bug#744027 ; Package ca-certificates . (Thu, 10 Apr 2014 16:00:11 GMT) (full text, mbox, link).

Acknowledgement sent to Thorsten Glaser <tg@mirbsd.de> :

Extra info received and filed, but not forwarded. (Thu, 10 Apr 2014 16:00:11 GMT) (full text, mbox, link).

Message #79 received at 744027-quiet@bugs.debian.org (full text, mbox, reply):

From: Thorsten Glaser <tg@mirbsd.de> To: Pontus Engblom | DigiSSL AB <pontus.engblom@digissl.eu> Cc: dev-security-policy@lists.mozilla.org Subject: Re: Revocation Policy Date: Thu, 10 Apr 2014 15:48:36 +0000 (UTC)

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.

Information forwarded to debian-bugs-dist@lists.debian.org, Michael Shuler <michael@pbandjelly.org> :

Bug#744027 ; Package ca-certificates . (Thu, 10 Apr 2014 16:57:08 GMT) (full text, mbox, link).

Acknowledgement sent to Kurt Roeckx <kurt@roeckx.be> :

Extra info received and forwarded to list. Copy sent to Michael Shuler <michael@pbandjelly.org> . (Thu, 10 Apr 2014 16:57:09 GMT) (full text, mbox, link).

Message #84 received at 744027@bugs.debian.org (full text, mbox, reply):

From: Kurt Roeckx <kurt@roeckx.be> To: Geoffrey Thomas <geofft@ldpreload.com>, 744027@bugs.debian.org Cc: Joey Hess <joeyh@debian.org> Subject: Re: Bug#744027: data point Date: Thu, 10 Apr 2014 18:55:37 +0200

On Wed, Apr 09, 2014 at 06:22:10PM -0700, Geoffrey Thomas wrote: > On Wed, 9 Apr 2014, Kurt Roeckx wrote: > > >However, iceweasel/firefox by default is happy to ignore a OCSP > >timeout. You need to turn it on that it doesn't allow a timeout. > >I have no idea why they use that as default. > > Because it's an easy DoS if an attacker is in a position to MITM the > connection between you and the OCSP service (or CRL file), no? And if the > attacker can MITM the connection between you and the SSL service you're > trying to talk to, they can probably also MITM the OCSP or CRL server. > > Also (as Adam Langley points out in the stuff I linked to earlier in this > bug report) the OCSP servers risk becoming a single point of failure if you > do that. If a CA's OCSP server is down, everything they sign becomes > inaccessible. That would be a bad default, and probably not something you > want to turn on for yourself either. > > Also also, > http://www.thoughtcrime.org/papers/ocsp-attack.pdf > which appears to be still valid with Firefox at least: > https://bugzilla.mozilla.org/505812 > So there's really no value at all in using OCSP, it seems. What we really need is OCSP stapling. That would mean that the server asks the CA for the OCSP response and adds that response in the TLS session, and the client doesn't have to contact the CA anymore to ask for the status. Only the server would need to contact the CA. The server should have enough time to be able to refresh the OCSP response, which is valid for maximum 10 days. I'm hereing some vague cases why OCSP mandatory checking can't be enabled by default because some users can't contact the OCSP server. I've never had this problem myself and I think I've seen way to many weird setups already to not consider this a real problem. Kurt

Information forwarded to debian-bugs-dist@lists.debian.org, Michael Shuler <michael@pbandjelly.org> :

Bug#744027 ; Package ca-certificates . (Thu, 10 Apr 2014 18:15:05 GMT) (full text, mbox, link).

Acknowledgement sent to Geoffrey Thomas <geofft@ldpreload.com> :

Extra info received and forwarded to list. Copy sent to Michael Shuler <michael@pbandjelly.org> . (Thu, 10 Apr 2014 18:15:05 GMT) (full text, mbox, link).

Message #89 received at 744027@bugs.debian.org (full text, mbox, reply):

From: Geoffrey Thomas <geofft@ldpreload.com> To: Kurt Roeckx <kurt@roeckx.be> Cc: 744027@bugs.debian.org, Joey Hess <joeyh@debian.org> Subject: Re: Bug#744027: data point Date: Thu, 10 Apr 2014 11:10:11 -0700 (PDT)

On Thu, 10 Apr 2014, Kurt Roeckx wrote: > What we really need is OCSP stapling. That would mean that the > server asks the CA for the OCSP response and adds that response > in the TLS session, and the client doesn't have to contact the > CA anymore to ask for the status. Only the server would need to > contact the CA. The server should have enough time to be able to > refresh the OCSP response, which is valid for maximum 10 days. Yes, agreed. Unfortunately not many sites enable it. I think it'd be productive to have Debian-packaged SSL _servers_ all support and document and maybe default to OCSP stapling, so that in a few years, maybe we can have the start of a working revocation protocol. Sadly, there isn't one right now, so I don't there's anything we can do today. This documentation seems to imply that upstream Apache HTTPD does not usefully support stapling when intermediate certs are in play, which is basically always: https://httpd.apache.org/docs/trunk/mod/mod_ssl.html#sslusestapling > I'm hereing some vague cases why OCSP mandatory checking can't be > enabled by default because some users can't contact the OCSP > server. I've never had this problem myself and I think I've seen > way to many weird setups already to not consider this a real > problem. Well, you'll have the problem as soon as you're being MITM'd. A cert verification solution that works fine when nobody's MITMing you is not particularly useful. :-) -- Geoffrey Thomas https://ldpreload.com geofft@ldpreload.com

Information forwarded to debian-bugs-dist@lists.debian.org, Michael Shuler <michael@pbandjelly.org> :

Bug#744027 ; Package ca-certificates . (Thu, 10 Apr 2014 18:42:05 GMT) (full text, mbox, link).

Acknowledgement sent to Kurt Roeckx <kurt@roeckx.be> :

Extra info received and forwarded to list. Copy sent to Michael Shuler <michael@pbandjelly.org> . (Thu, 10 Apr 2014 18:42:05 GMT) (full text, mbox, link).

Message #94 received at 744027@bugs.debian.org (full text, mbox, reply):

From: Kurt Roeckx <kurt@roeckx.be> To: Geoffrey Thomas <geofft@ldpreload.com> Cc: 744027@bugs.debian.org, Joey Hess <joeyh@debian.org> Subject: Re: Bug#744027: data point Date: Thu, 10 Apr 2014 20:38:21 +0200

On Thu, Apr 10, 2014 at 11:10:11AM -0700, Geoffrey Thomas wrote: > On Thu, 10 Apr 2014, Kurt Roeckx wrote: > > >I'm hereing some vague cases why OCSP mandatory checking can't be > >enabled by default because some users can't contact the OCSP > >server. I've never had this problem myself and I think I've seen > >way to many weird setups already to not consider this a real > >problem. > > Well, you'll have the problem as soon as you're being MITM'd. A cert > verification solution that works fine when nobody's MITMing you is not > particularly useful. :-) So if I'm understanding it right, we're not checking OCSP because the check might fail when there is a MITM attack, and we want to pretend nothing is going on in that case? That looks like a very good reason. Kurt

Added tag(s) fixed-upstream. Request was from bts-link-upstream@lists.alioth.debian.org to control@bugs.debian.org . (Mon, 09 Jun 2014 17:52:44 GMT) (full text, mbox, link).

Reply sent to Michael Shuler <michael@pbandjelly.org> :

You have taken responsibility. (Mon, 06 Oct 2014 01:51:06 GMT) (full text, mbox, link).

Notification sent to Klemens Baum <klemensbaum@gmail.com> :

Bug acknowledged by developer. (Mon, 06 Oct 2014 01:51:06 GMT) (full text, mbox, link).

Message #101 received at 744027-done@bugs.debian.org (full text, mbox, reply):

From: Michael Shuler <michael@pbandjelly.org> To: 744027-done@bugs.debian.org Subject: Re: Bug#744027: Please remove StartCom Certification Authority root certificate Date: Sun, 05 Oct 2014 20:48:02 -0500

Closing bug.

Bug archived. Request was from Debbugs Internal Request <owner@bugs.debian.org> to internal_control@bugs.debian.org . (Mon, 03 Nov 2014 07:35:28 GMT) (full text, mbox, link).

Send a report that this bug log contains spam.