Closed Bug 994033 Opened 10 years ago Closed 10 years ago

Most StartSSL certs will stay compromised

Categories

(CA Program :: CA Certificate Root Program, task)

Product:
CA Program
Component:
CA Certificate Root Program
Type:
task
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED INVALID

People

(Reporter: mail, Assigned: kathleen.a.wilson)

References

Details

(Whiteboard: [please discuss in the mailing list, not in this bug; see comment 18][bugday-20140407]) 

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:28.0) Gecko/20100101 Firefox/28.0 (Beta/Release)
Build ID: 20140314220517

Steps to reproduce:

OpenSSL CVE-2014-0160 "Heartbleed": https://www.openssl.org/news/secadv_20140407.txt

With Heardbleed every certificate which 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.




Actual results:

You can get certs for 25 USD. But there are people who can't or don't like to pay for a cert. These people are now forced to revoke there free StartSSL certs. Unfortunately StartCom charges 25 USD for every revocation.

I believe that this will result in a huge amount of certs which are considered as compsomised but are still active. As a consequence you can't trust certificates signed by StartCom before 2014-04-07.


Expected results:

Solution 1: StartCom should revoke affected certs. (We will see)

Solution 2: StartCom should be removed from the truststore.
Assignee: nobody → kwilson
Component: Untriaged → CA Certificates
OS: Mac OS X → All
Product: Firefox → mozilla.org
Hardware: x86 → All
Version: 28 Branch → other
Verifying, though Solution 1 would be on the Tech Evangelism product to contact StartCom and find out what their plan is.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Whiteboard: [bugday-20140409]
Whiteboard: [bugday-20140409] → [bugday-20140407]
As can be seen here: https://twitter.com/startssl/status/453631038883758080 (scroll up), StartSSL has made their stance clear on that they require everyone to pay for the revocation.
You pay the fire department with the taxes, not when you call them.

Every company has to choose their business model, but this idea in this context (trust!) makes it not very trustworthy for me. I don't want that in my truststore because they know that the certs are not secure but they keep them signed. That is simply careless.
To add some information to the mix, let's not generalize without having complete knowledge, for what I can add:

- EV certs from StartSSL will be replace for free as per their page (http://www.startssl.com/?app=25#72)
- Technically Class 2 Personal and Org Certificates would also be required to pay the revocation fee.
  Unconfirmed rumours seem to tell that some (paying) customers might not have to pay those fees this time, but StartSSL hasn't put out a statement (yet) to set the record straight.

This leaves mostly leaves Class 1 free certificates in the discussion, let's see how things continue. At least the OpenSSL debacle has yet again shown where the weak spots in the CA and trust system are.
(In reply to Mathieu S. from comment #4)
> To add some information to the mix, let's not generalize without having
> complete knowledge, for what I can add:
> 
> - EV certs from StartSSL will be replace for free as per their page
> (http://www.startssl.com/?app=25#72)
> - Technically Class 2 Personal and Org Certificates would also be required
> to pay the revocation fee.
>   Unconfirmed rumours seem to tell that some (paying) customers might not
> have to pay those fees this time, but StartSSL hasn't put out a statement
> (yet) to set the record straight.
> 
> This leaves mostly leaves Class 1 free certificates in the discussion, let's
> see how things continue. At least the OpenSSL debacle has yet again shown
> where the weak spots in the CA and trust system are.

As a paying customer of StartSSL (Class 2 Organizational Certificate) I have been refused the right to revoke the certificates due to this issue and cannot issue new ones until I pay the additional fee on top of the $100~ I already had to pay for the validation procedure.

All other Certificate authorities I've had to deal with have revoked certificates where the keys have been compromised. 

In their policy (https://www.startssl.com/policy.pdf) section 4.9.1 only subscribers explicitly requesting revocation is listed for carrying a fee. That means that compromised certificates/keys should not carry a revocation charge.

These misleading actions by StartSSL should throw their trust into doubt as leaving these potentially vulnerable certificates in the wild could lead to excessive damage to customers and corporate data.

Would YOU trust your data knowing that these certificates could be stolen and used maliciously with little or no visibility?
Every other certificate provider requires payment for certificates.  StartCom is the one provider offering free certificates, which goes a long way to spreading TLS and https more broadly, and the complaint here is that they're daring to charge a fee to maintain their revocation list?  Removing them over that would do more harm than good to security.
(In reply to Josh Triplett from comment #6)
> Every other certificate provider requires payment for certificates. 
> StartCom is the one provider offering free certificates, which goes a long
> way to spreading TLS and https more broadly, and the complaint here is that
> they're daring to charge a fee to maintain their revocation list?  Removing
> them over that would do more harm than good to security.

The problem is not them charging for revocations. If someone has lost their key or got hacked, okay fine. Their own fault.
The problem is that thanks to Heartbleed we now have potentially leaked private keys (leaked due to circumstances outside of the control of anyone) and thus insecure sites.
Now with StartSSL charging for every single revoked certificate they are encouraging people to "eh, the chance my key got leaked is so low, I'll just stay with my old certificate" thinking and behaviour.
This is actively compromising the security of SSL and consumers (no one I know checks the SSL vendor on certificates of sites they visit if there's the lock icon and it says it is trustworthy). Therefor customers and site users expose themselves to potential security risks while the browser ensures them they are communicating securely with the website.
(In reply to mriq91 from comment #7)
> (In reply to Josh Triplett from comment #6)
> > Every other certificate provider requires payment for certificates. 
> > StartCom is the one provider offering free certificates, which goes a long
> > way to spreading TLS and https more broadly, and the complaint here is that
> > they're daring to charge a fee to maintain their revocation list?  Removing
> > them over that would do more harm than good to security.

Spreading **** certificates all over the place for free and then forcing people to pay for the revocation of those certificates is certainly not doing any good for security. I can't see any reason why startssl.com should be in the truststore while cacert.org (which do not charge for revocation nor for anything else) are denied the same status.

> The problem is not them charging for revocations. If someone has lost their
> key or got hacked, okay fine. Their own fault.
> The problem is that thanks to Heartbleed we now have potentially leaked
> private keys (leaked due to circumstances outside of the control of anyone)
> and thus insecure sites.
> Now with StartSSL charging for every single revoked certificate they are
> encouraging people to "eh, the chance my key got leaked is so low, I'll just
> stay with my old certificate" thinking and behaviour.
> This is actively compromising the security of SSL and consumers (no one I
> know checks the SSL vendor on certificates of sites they visit if there's
> the lock icon and it says it is trustworthy). Therefor customers and site
> users expose themselves to potential security risks while the browser
> ensures them they are communicating securely with the website.

No CA which charges for either revocation or replacement of compromised certificates should be in the truststore. This has nothing to do with the Heartbleed vulnerability, this should be a general principle, regardless of the reason for which people revoke or replace a certificate.
I was just going to file a new bug here and ask whether refusal to rekey (or at least revoke, even without permitting to get a new one) certificates in the face of Heartbleed is reason enough for distrusting a CA, but you beat me to it (considering I had a “meeting-only” day at work, and was busy all day yesterday to rekey the other certs we have).

The one other CA I use (GoDaddy) and the one I do not use (CAcert) permit rekeying. Startcom doesn’t.

I’m a bit, no scratch that, very annoyed at Startcom, since I have one for MirBSD (hobby project, no money there) which is not affected by the bug, and one for Teckids (soon-to-be tax-exempt non-profit society of public utility, so, no money there either) which was affected (Linux) and I need to rekey. (Despite not handling credit card data or anything, the idea of having a compromised SSL session is inacceptable. Both websites only serve public data, from a public CVS or git repository, over http and https.)

But considering that Startcom does not seem to want to revoke or rekey those certificates, I seriously must ask Mozilla, Debian, and others to distrust most, if not all, certificates issued by Startcom. I think, for OpenSSL/GnuTLS, this means removing all of their certs from /etc/ssl/certificates and ca-certificates.txt and similar.

Are there any other CAs that refuse to rekey? If so, I suggest to track them here as well.

Any words from Startcom about this yet, asides the Twitter response above? Has anyone contacted them directly about it? If not, I’ll mail tonight, and remove them from all of my installations in 2 days or so if there will be no positive answer. (NB: I did request a revocation and told them I could not pay the fee and asked them to do it nevertheless due to this bug. So I consider the duty of the certificate requester to “request” (but not succeed in getting) a revocation done.)
Tracked in Debian at: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=744027

Not tracked in Red Hat/Fedora or Gentoo yet, AFAICT.
When I think about it I get the feeling that they don't care if they sign a compromised key or not. Keep in mind that they are providing a private key generation on their website.

It is nice that they are providing a free service which is helping to spread TLS. But more and more it only looks like a leak in the truststore.

A company which doesn't care about what they sign should be is any truststore. Whatever they did in the past. Every second they don't care makes me more angry.

We need a guideline that revocations must not be more complicated and expensive that the certification itself.
The business model for this free tier is based on profiting from security breaches. StartSSL lures in users with free certificates without making it clear that there is a revocation fee. During a crisis when users of these certificates are most vulnerable, they attempt to extort money with this fee. Many people are using the free certificates because they can't or won't pay fees like this. Certificates signed by StartSSL are no longer trustworthy, because the people who own the certificates can not revoke them even if they want to without paying an unexpected fee.
(In reply to mriq91 from comment #7)
> (In reply to Josh Triplett from comment #6)
> > Every other certificate provider requires payment for certificates. 
> > StartCom is the one provider offering free certificates, which goes a long
> > way to spreading TLS and https more broadly, and the complaint here is that
> > they're daring to charge a fee to maintain their revocation list?  Removing
> > them over that would do more harm than good to security.
[...]
> Now with StartSSL charging for every single revoked certificate they are
> encouraging people to "eh, the chance my key got leaked is so low, I'll just
> stay with my old certificate" thinking and behaviour.

And other CAs charging for certificates encourages people to think "eh, I don't really need https enough to pay for it, I'll just not have a certificate at all".
(In reply to Josh Triplett from comment #13)
> (In reply to mriq91 from comment #7)
> > (In reply to Josh Triplett from comment #6)
> > > Every other certificate provider requires payment for certificates. 
> > > StartCom is the one provider offering free certificates, which goes a long
> > > way to spreading TLS and https more broadly, and the complaint here is that
> > > they're daring to charge a fee to maintain their revocation list?  Removing
> > > them over that would do more harm than good to security.
> [...]
> > Now with StartSSL charging for every single revoked certificate they are
> > encouraging people to "eh, the chance my key got leaked is so low, I'll just
> > stay with my old certificate" thinking and behaviour.
> 
> And other CAs charging for certificates encourages people to think "eh, I
> don't really need https enough to pay for it, I'll just not have a
> certificate at all".

But if they do that, then there at least is no lock icon or other feeling of security conveyed to the end user of the service. The user flat-out knows there is no encryption provided by the service and can make their decisions to enter certain details based on that fact.
They are not "tricked" by the fact the browser assures them that all communication is secured properly.
(In reply to Josh Triplett from comment #13)
> (In reply to mriq91 from comment #7)
> > (In reply to Josh Triplett from comment #6)
> > > Every other certificate provider requires payment for certificates. 
> > > StartCom is the one provider offering free certificates, which goes a long
> > > way to spreading TLS and https more broadly, and the complaint here is that
> > > they're daring to charge a fee to maintain their revocation list?  Removing
> > > them over that would do more harm than good to security.
> [...]
> > Now with StartSSL charging for every single revoked certificate they are
> > encouraging people to "eh, the chance my key got leaked is so low, I'll just
> > stay with my old certificate" thinking and behaviour.
> 
> And other CAs charging for certificates encourages people to think "eh, I
> don't really need https enough to pay for it, I'll just not have a
> certificate at all".

A self-signed certificate is more trustworthy because it can be revoked without paying a hidden protection fee.
It's not like StartSSL performs any meaningful validation of identity for most accounts anyway. The inability for people to revoke the certificates in the *free tier* without paying a hidden fee is just icing on the cake. Firefox marking these certificates as more trustworthy than self-signed certificates is clearly a bug.
I don't object to a policy of generally charging for revocations - it should not be easy to generate frivolous revoked certificates, I believe that would increase entropy and lowers security overall. Especially when major browsers like Chrome don't enforce revocation checks: https://www.imperialviolet.org/2012/02/05/crlsets.html

Also, StartSSL is the only CA in the trust store that offers free 1-year certificates. It's a great practice, and I don't agree that the revocation fee is "extortion". Under "normal" circumstances, most users will never have to revoke their certificate. It doesn't follow that revocation for free certificates should also be free -- that just makes for an even worse situation.

HOWEVER, I strongly believe StartSSL should, in the interest of making the web more secure, waive the revocation fee once for each certificate issued before April 7, 2014. In fact, they did this for me -- I am a StartSSL customer, and they allowed me to revoke the certificate for isitchristmas.com and replace it with a new one for free. Their revocation confirmation email had an extra note saying "Revoked without charge."

This is obviously in disagreement with their tweet, and I've registered my disappointment with that tweet: https://twitter.com/konklone/status/453958291279065088

HOWEVER HOWEVER, I don't think this adds up to justification for removing them from the trust store. That's a devastating move, and while I believe they have an ethical obligation to waive revocation fees once per certificate, I don't believe that not doing so is such an ethical breach to warrant the death penalty.

> It's not like StartSSL performs any meaningful validation of identity for most accounts anyway.

For free certificates, they validate that you own the domain name. In other words, that you are capable of receiving a confirmation code in an email that only the domain's administrator could operate (or is attached to the domain registration metadata). It's not identity, but it confirms site ownership, and as a baseline that seems acceptable, and significantly better than self-signed.
This is an interesting and important discussion to have. However, the Mozilla project prefers to have such discussions in our mailing lists instead of in the bug's comments. Please move the discussion of StartSSL's revocation practices to the dev-security-policy mailing list. You can subscribe to the list here:
https://lists.mozilla.org/listinfo/dev-security-policy. For example, there was a discussion on this topic before on that mailing list:
https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/3naC_Qosfq4/G90NCqzVuK8J

Thanks for your cooperation.
Whiteboard: [bugday-20140407] → [please discuss in the mailing list, not in this bug; see comment 18][bugday-20140407]
Rather than removing the certificate authority, Firefox could simply not trust StartSSL certificates issued before the disclosure of heartbleed. Whether the CA policy should be altered to deal with issues like this in the future can be separate from the response to this specific incident.
(In reply to Daniel Micay from comment #19)

Daniel, I think just not trusting certificates issued prior to this day does not help either: there are still vulnerable versions out there (not everyone patches immediately), and there were non-vulnerable versions before. This is also impossible to do with OpenSSL and probably GnuTLS and NSS.

Also, who is to say they will not repeat that? How often are we going to play with them?


(In reply to Eric Mill from comment #17)

I’ve received a clear statement from them saying they will *not* rekey (or at least revoke) this certificate for free:


From: "StartCom Certmaster (Nikolay Duhman)" <certmaster@startcom.org>
Message-ID: <53458F35.8090706@startcom.org>
Date: Wed, 09 Apr 2014 21:19:33 +0300
Subject: Re: Revocation Request: 07:43 pm 09 Apr 2014
Parts/Attachments:
   1 Shown    25 lines  Text
   2   OK    ~71 lines  Text
----------------------------------------

Revocations carry a handling fee of US$ 24.90. Please add your credit card or PayPal details to your account
at the StartSSL Control Panel -> Tool Box -> Add Credit Card. We'll process your revocation request upon
receipt of the handling fee.

Regards
Signer:         Nikolay Duhman, CVO

        StartCom Ltd. <http://www.startcom.org>
E-Mail:         nikolayd@startcom.org <mailto:nikolayd@startcom.org>
Phone:  +972-57-631-56-27


I think this behaviour, in face of the severity of this bug, warrants exclusion of *all* of StartCom from the list of acceptable CAs.


(In reply to Josh Triplett from comment #13)

Josh, I’d rather people not have “pretend” SSL at all than insecure SSL. Even using self-signed certificates, or (not much, but a bit, better) certificates signed by one’s own CA (e.g. the one from Debian situated in Ankh-Mopork, or the one I recently set up for MirBSD’s internal infrastructure servers), is better than using insecure SSL like this.

A CA clearly has a certain set of responsibilities, because it’s a service to the public and has to hold up SSL and X.509-based services in general. If they decide to spew out certificates for free, just like CAcert, that doesn’t free them of this responsibility. Additionally, they also want horrid “handling” fees for certificate revocation for paid-for certificates, as someone else said. This is clearly inacceptable.
> It's not like StartSSL performs any meaningful validation of identity for most accounts anyway.

It's not like many other CA's perform any meaningful validation of identity.  Many just require you to be able to place a challenge file at an arbitrary URL on the domain in question, fetched over HTTP— or receive an email to the administrative contact on the DNS registration.

Heck, one CA instantly hands cloudflare certs for any domain that resolves to a cloudflare IP— a fact that has been exploited to extend tricking a registrar to a full SSL MITM sites in the past.

Please don't hold StartSSL responsible for the bad norms in the CA ecosystem, their failure to issue revocations is the relevant problem here...

Even then I don't know how relevant it is:  Revocations are not very useful and are, honestly, almost completely useless in the face of a substantial fraction of the certs needing to be revoked.  To fix this it probably makes more sense to reboot the entire infrastructure and replace all CA root keys with post-event root keys. :(
(In reply to Gregory Maxwell from comment #21)
> > It's not like StartSSL performs any meaningful validation of identity for most accounts anyway.
> 
> Please don't hold StartSSL responsible for the bad norms in the CA
> ecosystem, their failure to issue revocations is the relevant problem here...

Mozilla takes on the responsibility of trusting specific certificate authorities on behalf of their users. If Firefox ships certificate authorities holding known vulnerability certificates hostage for a fee or with weak identity verification, Mozilla is responsible for any security breaches. The 'bad norms' in the CA ecosystem are the norms written down in the Mozilla CA policy.
I'm not sure what world you're living in, but let me break some news for you: most non-StartSSL certificates issued by CAs who doesn't charge for revocations will *also* stay compromised.

No CA who want to stay in business will start to proactively revoke certificates without a customer request, and 99.9% of all certificate owners will not revoke their certificates. Either because of ignorance or laziness, or both.

That leaves us with the other 0.1% who want to revoke their certificates. If you are in that category and you got your certificate for free, or in the case of StartSSL class 2 certificates for about one 10:th of the price other CAs charge for equivalent functionality, you're quite pathetic to complain about having to pay 25 USD to revoke a certificate when *you* are the one who has been running broken software. Sensible persons who care about their website visitors will revoke their certificates regardless of whether it costs a symbolic sum of money or not.
(In reply to Thorsten Glaser from comment #20)
> (In reply to Josh Triplett from comment #13)
> Josh, I’d rather people not have “pretend” SSL at all than insecure SSL.
> Even using self-signed certificates, or (not much, but a bit, better)
> certificates signed by one’s own CA (e.g. the one from Debian situated in
> Ankh-Mopork, or the one I recently set up for MirBSD’s internal
> infrastructure servers), is better than using insecure SSL like this.

This bug is not the place to argue the failings of the CA system in general; there are other places to tilt at that windmill.  Like it or not, having a certificate that chains back to a trusted CA (e.g. one supported by all major browsers) is a hard requirement for the vast majority of SSL deployments.

Meanwhile, let's stop throwing around assertions like "pretend SSL" and "clearly unacceptable" without support.  We're not going to make any progress in this discussion that way.  If there's a change to be made here, it'll have to be made to Mozilla's general CA inclusion policies, not reactively to this one particular CA.

Per comment #18, this bug is also the wrong place to discuss Mozilla's general CA inclusion policies.
(In reply to Brian Smith (:briansmith, was :bsmith; NEEDINFO? for response) from comment #18)

> https://lists.mozilla.org/listinfo/dev-security-policy. For example, there
> was a discussion on this topic before on that mailing list:
> https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/
> 3naC_Qosfq4/G90NCqzVuK8J

Is there an accessible (preferrably Lynx or Pine, NNTP interface okay)
version of this?

(Sorry about getting off-topic, but I was asked to continue there and cannot.)
(In reply to Thorsten Glaser from comment #25)
> (In reply to Brian Smith (:briansmith, was :bsmith; NEEDINFO? for response)
> from comment #18)
> 
> > https://lists.mozilla.org/listinfo/dev-security-policy. For example, there
> > was a discussion on this topic before on that mailing list:
> > https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/
> > 3naC_Qosfq4/G90NCqzVuK8J
> 
> Is there an accessible (preferrably Lynx or Pine, NNTP interface okay)
> version of this?
> 
> (Sorry about getting off-topic, but I was asked to continue there and
> cannot.)

Email is the most reliable way. But see the other options (News, Web) here:
http://www.mozilla.org/about/forums/#dev-security-policy. Posting and reading through Google Groups is the least reliable way, based on others' experience.
(In reply to Josh Triplett from comment #13)
> (In reply to mriq91 from comment #7)
> > (In reply to Josh Triplett from comment #6)
> > > Every other certificate provider requires payment for certificates. 
> > > StartCom is the one provider offering free certificates, which goes a long
> > > way to spreading TLS and https more broadly, and the complaint here is that
> > > they're daring to charge a fee to maintain their revocation list?  Removing
> > > them over that would do more harm than good to security.
> [...]
> > Now with StartSSL charging for every single revoked certificate they are
> > encouraging people to "eh, the chance my key got leaked is so low, I'll just
> > stay with my old certificate" thinking and behaviour.
> 
> And other CAs charging for certificates encourages people to think "eh, I
> don't really need https enough to pay for it, I'll just not have a
> certificate at all".

A cert that is (or even could be) compromised is more dangerous than HTTP. A false sense of security would be had by using a site with a StartSSL cert and thus endangers the very idea of a cert.

Somewhat related: http://lorddoig.svbtle.com/heartbleed-should-bleed-x509-to-death
This bug is a bit "cart before the horse"; we can file a bug to implement a policy decision when that decision has been made. Right now there's nothing actionable here that the developers can work with so it's just clogging up the system and attracting discussion that should go in the .policy group.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → INVALID
(In reply to Thorsten Glaser from comment #25)
> Is there an accessible (preferrably Lynx or Pine, NNTP interface okay)
> version of this?

news://news.mozilla.org/mozilla.dev.security.policy
It is now Saturday, and there is no response from StartCom other than a vague “promise to get back to you all in due time”. In the meantime, people proved secret key extraction is possible.

It is inacceptable to wait any longer. Please remove *all* of StartCom from the root stores. The CA has to regain trust from the beginning, now.
(In reply to Thorsten Glaser from comment #31)
> It is now Saturday, and there is no response from StartCom other than a
> vague “promise to get back to you all in due time”. In the meantime, people
> proved secret key extraction is possible.
> 
> It is inacceptable to wait any longer. Please remove *all* of StartCom from
> the root stores. The CA has to regain trust from the beginning, now.

Before you start claiming that key extraction was possible we must also consider the fact that after the CloudFlare challenge they came to the conclusion that, for the events of making key extraction possible;

1) They do suspect it is easier immidiately after the server has restarted.
2) The key extraction requires atleast (what we know) 100k requests.
3) Assuming that we are on Apache, the private key has been stolen on the first request after that it restarted.

(http://blog.cloudflare.com/answering-the-critical-question-can-you-get-private-ssl-keys-using-heartbleed)

This said, I agree with CloudFlare that any systems that might have been vulnerable should renew their certificates, I do not however agree with all the publish bashing of this. I am also sure that StartCom as a CA are currently getting drowned in revocation requests and other questions from PAYING customers, which I assume would be prior support. 
With that said, I can see how they can have limited time to sit and discuss this on public forums until they resolved a solution.

So I deem we will have a bigger chance to hear from StartCom if we stick to the mailing list and not create several bugs for this, easier to track the mailinglist.
(Which you have been posting on, please continue using that per comment #18).

This bug should stay resolved invalid until Mozilla has made a clear statement about their policies,
Thijs Kinkhorst @ Debian said it best;
"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"
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=744027#17).
(In reply to Pontus Engblom from comment #32)
>
> Before you start claiming that key extraction was possible we must also
> consider the fact that after the CloudFlare challenge they came to the
> conclusion that, for the events of making key extraction possible;
> 
> 1) They do suspect it is easier immidiately after the server has restarted.
> 2) The key extraction requires atleast (what we know) 100k requests.
> 3) Assuming that we are on Apache, the private key has been stolen on the
> first request after that it restarted.
> 
> (http://blog.cloudflare.com/answering-the-critical-question-can-you-get-
> private-ssl-keys-using-heartbleed)
> 
> This said, I agree with CloudFlare that any systems that might have been
> vulnerable should renew their certificates, I do not however agree with all
> the publish bashing of this. I am also sure that StartCom as a CA are
> currently getting drowned in revocation requests and other questions from
> PAYING customers, which I assume would be prior support. 
> With that said, I can see how they can have limited time to sit and discuss
> this on public forums until they resolved a solution.

This is not "public bashing". There are many people reasonably concerned that their certificate is compromised, but who are unwilling to pay an unexpected fee for their personal web sites. They subscribed to a "free" plan with no mention of any fees in sight.

> So I deem we will have a bigger chance to hear from StartCom if we stick to
> the mailing list and not create several bugs for this, easier to track the
> mailinglist.
> (Which you have been posting on, please continue using that per comment #18).

Other people need to use the mailing list, but you're going to keep replying here?

> This bug should stay resolved invalid until Mozilla has made a clear
> statement about their policies,
> Thijs Kinkhorst @ Debian said it best;
> "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.

Mozilla has made a clear statement about their policies:

https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/maintenance/

According to the existing policy, this bug is not invalid.
 
> 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.

This fee did not used to exist, and it has *always* been hidden since it was introduced. There is no mention of this anywhere on the main pages describing the various plans. Only a fraction of those using this plan would have been aware of the fee... you're trying to turn this into a political issue about "free markets" and "user choice" when talking about false advertising and a clear breach of the Mozilla CA policy.
According to the Mozilla CA policy:

CAs must revoke Certificates that they have issued upon the occurrence of any of the following events:

* 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), or that the certificate has otherwise been misused;

This issue is not invalid, and does not involve changing any policies. It states unequivocally that the CA *must* revoke the certificate if they are made aware that it is suspected of compromise. It even gives an example of a similar bug (the Debian entropy issue). It gives no wiggle room to extort fees hidden in the fine print - they *must* revoke the key if it has been, or is suspected to be compromised.
(In reply to Pontus Engblom from comment #32)

> Before you start claiming that key extraction was possible we must also
> consider the fact that after the CloudFlare challenge they came to the
> conclusion that, for the events of making key extraction possible;

This doesn't matter: we know that private keys can have been stolen.
This means that every private key that was on a system where this attack
was possible must be considered compromised. This is not a “prove to me
it was stolen” situation, this is a “we assume stolen unless otherwise
shown” one. (I can't believe I have to explain this here.)

> the publish bashing of this. I am also sure that StartCom as a CA are
> currently getting drowned in revocation requests and other questions from
> PAYING customers, which I assume would be prior support. 

You know, they even charge PAYING customers extra for the revocation.
And if they are indeed drowning, they have been doing something wrong.

> With that said, I can see how they can have limited time to sit and discuss
> this on public forums until they resolved a solution.

Nevertheless, there was no reaction for *days*. StartCom has lost its trust.

> mailinglist.

There is nothing to discuss any more. We informed StartCom that the private
keys have been compromised. Under Mozilla's own policy, StartCom must have
revoked the certificates within 24 hours. They did not do that. Time is up.
The bug is now valid, and StartCom must be distrusted. If they want to regain
any trust, they have to start anew from the beginning.
(In reply to Thorsten Glaser from comment #35)
> (In reply to Pontus Engblom from comment #32)
> > With that said, I can see how they can have limited time to sit and discuss
> > this on public forums until they resolved a solution.
> 
> Nevertheless, there was no reaction for *days*. StartCom has lost its trust.

Sorry to hear that StartCom has lost your personal trust.  You're not Mozilla, however, and Mozilla does not yet have an official response, nor is it clear that there's any violation of Mozilla's CA policy here.

> > mailinglist.
> 
> There is nothing to discuss any more.

Clearly there is; feel free to participate, or not.

> Under Mozilla's own policy, StartCom must have
> revoked the certificates within 24 hours.

Even assuming there's any violation of Mozilla policy here (and that's not a given), "24 hours" appears nowhere in https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ .

If you'd like to discuss this further, this bug is *still* not the right place to do it.  Assertions will not get this bug reopened or your will enacted.  Go convince people, and come back with the result of that discussion.
(In reply to Josh Triplett from comment #36)
> Sorry to hear that StartCom has lost your personal trust.  You're not
> Mozilla, however, and Mozilla does not yet have an official response, nor is
> it clear that there's any violation of Mozilla's CA policy here.

What's your interpretation of the following paragraph from the CA policy then?

* 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), or that the certificate has otherwise been misused;

The policy clearly states that a key known or suspected to be compromised *must* be revoked. It gives no time limit, but it also gives no room for StartCom to blatantly deny these revocation requests as they have done. The certificate authorities are too big to fail as Mozilla is unwilling to enforce the policies over fear of losing users. There is no proposed policy change here, simply an issue report asking that Mozilla enforce the policy they pretend to have.
> * 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), or that the certificate has otherwise been misused;

I remain disappointed in StartCom, but I don't believe they are "blatantly denying" revocation requests. 

As best as we can tell from the outside, they have a revocation fee in place for all certificates, free or paid. They have decided to waive them for at least a few customers who have paid certificates (like mine). They have decided not to waive them for at least a few customers with free certificates (a couple cases linked from this thread).

I don't believe StartSSL has an ethical obligation, as a *general business practice*, to revoke freely obtained certificates for free. I do believe StartSSL has an ethical obligation, as a responsible participant in Internet security at a time of great need, to offer a one-time fee waiver to all certificates issued to vulnerable customers pre-Heartbleed.

But that's my personal view of their ethical obligations. They've had a clear policy of fee-for-revocation, and I don't think their refusal to do so meets Mozilla's criteria for removing them from the trust store. 

I also don't think that CloudFlare's challenge (which demonstrated that it was possible but also *difficult*) to obtain a private key means StartCom must operate under the assumption that all customer private keys are compromised or risk breaching Mozilla's policy.

But again: these are just my opinions. To say this situation meets Mozilla's criteria for removal from the trust store is subjective, and those who believe that need to convince more people to see it their way. 

That argument will be more persuasive by refraining from lines like "There is nothing more to discuss." and "I can't believe I have to explain that here." Those who don't currently favor removing them from the trust store are not acting out of cowardice or stupidity. Let's keep it civil and constructive. 

We're also being asked to keep it on the mailing list, and I believe this is the correct thread: https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/ItSu2bebBKk/VCkm92M28lIJ
> I don't believe StartSSL has an ethical obligation, as a *general business practice*, to revoke freely obtained certificates for free. I do believe StartSSL has an ethical obligation, as a responsible participant in Internet security at a time of great need, to offer a one-time fee waiver to all certificates issued to vulnerable customers pre-Heartbleed.

Charging a fee to re-issue a new certificate is completely reasonable. It would have the same end result for their business model, but would conform to the current CA policy. A poorly advertised fee in their free tier for *revoking* a certificate is a different story.

Once again, Mozilla's stated policy:

CAs must revoke Certificates that they have issued upon the occurrence of any of the following events:

* 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), or that the certificate has otherwise been misused;

> To say this situation meets Mozilla's criteria for removal from the trust store is subjective, and those who believe that need to convince more people to see it their way. 

I think it takes quite a bit of mental gymnastics to interpret that paragraph another way.

> That argument will be more persuasive by refraining from lines like "There is nothing more to discuss." and "I can't believe I have to explain that here." Those who don't currently favor removing them from the trust store are not acting out of cowardice or stupidity. Let's keep it civil and constructive.

This is an obvious straw man argument. I never made statements resembling either of those things. I stated that I think Mozilla is unwilling to enforce the established CA policy to the letter because the consequences of removing a CA are too dire. I might even agree with someone arguing it from that angle. However, I think it takes intellectual dishonesty to pretend that there is no violation of the existing policy as written down in that document.

> We're also being asked to keep it on the mailing list, and I believe this is the correct thread: 

You're replying here, so I'm replying to you here.
It would be completely reasonable for Mozilla to remove the unenforceable clauses from the CA policy. The original bug report here approached this as an issue requiring new/changed policy, but that's not the case. I'll open another without the same confrontation tone and without a request for any policy changes. I understand why this was closed, but I do think there is a valid bug here.
It doesn't take mental gymnastics or intellectual dishonesty to believe Mozilla's policy has not been violated. On the thread I linked to, Peter Eckersley of the EFF has a good take on what the standard for "suspected of compromise" should be for this event, which I agree with: 

https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/ItSu2bebBKk/7QBGYz5W0DQJ

Look, he may not be right, and neither may I. But it's not cut-and-dry, and by assuming bad faith of those who disagree with you (that's what "intellectual dishonesty" means), you weaken your ability to convince others of your case.
I'm not trying to convince you of anything or force action on the part of Mozilla. It's not feasible to rip out widely used certificate authorities from Firefox for simply violating the CA policy. I do think that the policy is clearly being violated, and Mozilla needs to state that they're not enforcing that part of the policy (or remove StartCom, which I can't see happening).

I don't think you're acting in bad faith. I do think you're reaching for reasons to paint Mozilla as the good guy and venturing outside of reasonable arguments.

> Look, he may not be right, and neither may I. But it's not cut-and-dry, and by assuming bad faith of those who disagree with you (that's what "intellectual dishonesty" means), you weaken your ability to convince others of your case.

For context, here's your straw man again:

> That argument will be more persuasive by refraining from lines like "There is nothing more to discuss." and "I can't believe I have to explain that here." Those who don't currently favor removing them from the trust store are not acting out of cowardice or stupidity. Let's keep it civil and constructive.

I never stated any of these things, so this is a cut and dry case of dishonesty.
Perhaps those comments weren't directly at me, if so I apologize for the misunderstanding.
> Perhaps those comments weren't directly at me, if so I apologize for the misunderstanding.

They were not - I deliberately phrased the comment that's excerpted from to be at no one person in particular. But I did quote you at the top, which made it easier to miss that (and I could have been clearer). That's my bad. But anyway, I'm prepared to just talk on the mailing list from here on out.
(In reply to Daniel Micay from comment #33)
> This fee did not used to exist ...
> Only a fraction of those using this plan would have been aware of the fee.

FWIW, the fee appears to have shown up in 2010:
  https://web.archive.org/web/20101124022655/http://www.startssl.com/?app=37

IIRC they issue for a max of 3 years so we're not dealing with any pre-policy-change certs at this point.  Also, you have to agree to the policies to get a cert (I doubt we can accept "everybody lies about that" as a fair argument).

I'll reserve my opinions about incentives for the list - just clarifying the comment left here.
(In reply to Bill McGonigle from comment #45)

> FWIW, the fee appears to have shown up in 2010:
>   https://web.archive.org/web/20101124022655/http://www.startssl.com/?app=37
> 
> IIRC they issue for a max of 3 years so we're not dealing with any

Eh, you don’t read that for every cert, you read that once when you sign
up for their service.
Hmm anything new on that? Seem like it has just run dead again, like the countless other issue where Mozilla gives a shi* on any security or sane policies?
(In reply to Christoph Anton Mitterer from comment #47)
> Hmm anything new on that? Seem like it has just run dead again, like the
> countless other issue where Mozilla gives a shi* on any security or sane
> policies?

There's a response from Mozilla on this particular bug in comment #28, and a link to a location to discuss Mozilla's CA policies.  That discussion evidently either took place and did not result in a change in CA policy, or nobody cared enough to have that discussion in the first place.  Either way, I think you have your answer in regards to this particular CA; if you want to change that answer, pinging this bug won't affect that.
Please also note that those free StartCom certificates issued before Heartbleed should be invalid by now (as this is more than 1 year ago).
@Josh: I don't see that this comment would clear up that the CA doesn't break the policy.
It rather delegates responsibility for serious security issues somewhere else (ideally into the void), as it happens so often in Mozilla.
The original submitter has reported a quite clear problem and a quite clear technical solution is available (drop the CA).
So what are all of Mozilla's nice policies worth if no-one cares (either here or on some discussion lists) about them?


@"Shoulds" aren't guarantees...

But the main problem here is apparently anyway a different one, isn't it? Namely the policy breaking.
Product: mozilla.org → NSS
Product: NSS → CA Program
You need to log in before you can comment on or make changes to this bug.