Please remove StartCom Certification Authority root certificate(bugs.debian.org)
bugs.debian.org
Please remove StartCom Certification Authority root certificate
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=744027
15 comments
If I remember correctly, http://gandi.net/ offers 1 year free SSL cert if you buy a domain. To be honest the difference between an excellent cert and good-enough cert is what you want to protect. If you think your data is so sensitive and you accept that we must rely on CA at the moment, you wouldn't be using StartCom free cert.
Self signed certificates (i.e. free) are much better than a CA which won't revoke a certificate that's reported to be compromised.
Your customer relation to StartCom is irrelevant, this is about everybody else implicitly trusting them.
Your customer relation to StartCom is irrelevant, this is about everybody else implicitly trusting them.
Certificate revocation infrastructure (OSCP or CRL server) is something that needs to be maintained constantly (versus certificate requests, which are a one shot deal). In order to maintain that revocation, they have to keep serving it out for as long as someone might use your cert. It makes perfect sense to charge for it.
The certificate revocation infrastructure is something they're required to maintain in order for any of the browsers to actually accept their certificates, though.
StartCom customers knew the pricing before they signed up. They should take the hit. What more is there to it?
Bingo. If you don't like it, get your cert from somewhere else.
please remove all CA root certificate becaue they all charge fees for certs and that discourages spreading TLS and https more broadly?
StartCom almost has the right idea with the way they do EV certs: they charge you for identity verification (the thing that actually requires human labor to do), and then the EV certs themselves (as many as you like, for as long as you like) are free.
I think the optimal thing would be moving the job of identity verification into OpenID identity providers. So you could create a plain OpenID identity, or pay for a verified OpenID identity. Then, CAs would just be infrastructure to issue free certs to whichever verified identity obviously owns them.
In fact, if identity verification came before domain registration et al., the certificate-issuance part could even be done proactively: you'd buy a domain, put your verified OpenID in the SOA record, and then some CA-bot would notice, prompt your identity provider to generate a CSR using the private key the identity provider has on file, and then send back a signed cert.
I think the optimal thing would be moving the job of identity verification into OpenID identity providers. So you could create a plain OpenID identity, or pay for a verified OpenID identity. Then, CAs would just be infrastructure to issue free certs to whichever verified identity obviously owns them.
In fact, if identity verification came before domain registration et al., the certificate-issuance part could even be done proactively: you'd buy a domain, put your verified OpenID in the SOA record, and then some CA-bot would notice, prompt your identity provider to generate a CSR using the private key the identity provider has on file, and then send back a signed cert.
> moving the job of identity verification into OpenID identity providers
Please, don't. This idea is horrible.
With OpenID (and xAuth and Persona and whatever) your identity is provided, not asserted. This is very important distinction. I believe, any sane person wants to be a source of their identity (that's asserted by others), not to lease their very identity from a third party.
If you want an identity - generate a keypair. Publish your public key and let others sign it to assert this keypair is genuinely yours. It's that easy. (Although, sadly, X.509 doesn't support multiple signatures, so one can't do a proper web-of-trust with them.)
If you want automated domain ownership verification and completely automated certificate signing (and whois-pointed email ownership check is not to your taste) - well, how about putting a CSR right in TXT record of the domain? CA-bot would see those and sign them. No need for identity providers except for a domain registrar.
Please, don't. This idea is horrible.
With OpenID (and xAuth and Persona and whatever) your identity is provided, not asserted. This is very important distinction. I believe, any sane person wants to be a source of their identity (that's asserted by others), not to lease their very identity from a third party.
If you want an identity - generate a keypair. Publish your public key and let others sign it to assert this keypair is genuinely yours. It's that easy. (Although, sadly, X.509 doesn't support multiple signatures, so one can't do a proper web-of-trust with them.)
If you want automated domain ownership verification and completely automated certificate signing (and whois-pointed email ownership check is not to your taste) - well, how about putting a CSR right in TXT record of the domain? CA-bot would see those and sign them. No need for identity providers except for a domain registrar.
> If you want an identity - generate a keypair. Publish your public key and let others sign it to assert this keypair is genuinely yours.
You're hiding an unbounded amount of work under the word "publish" there. The important part of an identity is the part where people trust that someone using the identity is you. Just posting "hey, this is the public key for John Smith" on a website does nothing to prove that fact. (Key-signing parties prove that fact, but people don't do those.)
What does prove that fact is the background-check a CA does. But they only do it to create a private notion of your identity for themselves, which means that every CA has to do its own redundant background check, which is why certs cost money.
All I'm suggesting, here, is that the "background checking to create an ID number that maps to a specific person" part could be split off into its own business model, and the resulting ID number (in the form of an OpenID, or whatever else) reused by any-and-all organizations that wish to map tokens to real people.
Also:
> I believe, any sane person wants to be a source of their identity (that's asserted by others), not to lease their very identity from a third party.
You're never the source of your identity. For example, your name is only your name because the government you were born under has a law creating an identity, by mapping birth certificates to people, and your name is one aspect of that identity. Change citizenship from the US to China? Suddenly what you were considering "your name" is no more, and your new name is spelled in ideographs. You can certainly get people to call you by your old, alphabetic name--but that is a person-to-token mapping. In any token-to-person mapping--a phonebook, for example--you'll be found by your new government-created identity.
You're hiding an unbounded amount of work under the word "publish" there. The important part of an identity is the part where people trust that someone using the identity is you. Just posting "hey, this is the public key for John Smith" on a website does nothing to prove that fact. (Key-signing parties prove that fact, but people don't do those.)
What does prove that fact is the background-check a CA does. But they only do it to create a private notion of your identity for themselves, which means that every CA has to do its own redundant background check, which is why certs cost money.
All I'm suggesting, here, is that the "background checking to create an ID number that maps to a specific person" part could be split off into its own business model, and the resulting ID number (in the form of an OpenID, or whatever else) reused by any-and-all organizations that wish to map tokens to real people.
Also:
> I believe, any sane person wants to be a source of their identity (that's asserted by others), not to lease their very identity from a third party.
You're never the source of your identity. For example, your name is only your name because the government you were born under has a law creating an identity, by mapping birth certificates to people, and your name is one aspect of that identity. Change citizenship from the US to China? Suddenly what you were considering "your name" is no more, and your new name is spelled in ideographs. You can certainly get people to call you by your old, alphabetic name--but that is a person-to-token mapping. In any token-to-person mapping--a phonebook, for example--you'll be found by your new government-created identity.
> You're never the source of your identity.
I guess you're (or I'm, that's well possible too) mistaking identity with something other.
In my understanding, identities are what we - or part of us, as one could have multiple identities - are, not how we're called or what we look like. And names, personal or domain ones, are not identities but their properties. Others could assert your identity by confirming those properties (like when state issues a birth certificate with one's name in) or even associate their own information with person's identity (like assigning a trust level to a signature or limiting signature's timespan or, say, adding contract ID to a signature).
This is why OpenID and other attempts to shift identities from being owned (like one owns a certificate or password) to being merely leased doesn't look fancy to me.
I guess you're (or I'm, that's well possible too) mistaking identity with something other.
In my understanding, identities are what we - or part of us, as one could have multiple identities - are, not how we're called or what we look like. And names, personal or domain ones, are not identities but their properties. Others could assert your identity by confirming those properties (like when state issues a birth certificate with one's name in) or even associate their own information with person's identity (like assigning a trust level to a signature or limiting signature's timespan or, say, adding contract ID to a signature).
This is why OpenID and other attempts to shift identities from being owned (like one owns a certificate or password) to being merely leased doesn't look fancy to me.
I'm in your camp, identity is an intrinsic property of a person. Documents provide variously worthwhile assertions about that identity (legally recognized name of depicted individual is...).
One key point in this is that an authentic document can be fraudulent (just takes a bit of corruption down at the office).
One key point in this is that an authentic document can be fraudulent (just takes a bit of corruption down at the office).
[deleted]
Solution 3: cease trusting StartSSL certs issued before 2014-04-07?
This is implied by the request itself but is it possible to implement?
This is implied by the request itself but is it possible to implement?
This is actually not enough as you cannot be sure that certificates generated after that have never been used on a server with a vulnerable OpenSSL implementation.
You can't ever guarantee that for any certificate signed by any CA.
And what about those with StartSSL certs deployed to servers that never were vulnerable to heartbleed? No reason to be needlessly inconvenienced by the poor judgement of others.
Easily: they could get their upstream CA to revoke their own CA cert, and then get another one. All certs signed by the previous StartCom CA-cert would then be considered revoked.
There's more discussion on the Mozilla bugzilla, linked from this report:
https://bugzilla.mozilla.org/show_bug.cgi?id=994033
https://bugzilla.mozilla.org/show_bug.cgi?id=994033
Seems unlikely to happen based on what was said in the thread.
> 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.
> 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.
Either this request is naive, or I am.
As I understand it, not all StartCom certificates are necessarily vulnerable. I have a number of StartSSL certificates issued before 4/7 that, according to the HeartBleed checker here[1] are not vulnerable.
Is it wrong for me to assume that the tool is correct, or is it wrong to assume that all StartCom certificates are necessarily vulnerable?
[1] - http://filippo.io/Heartbleed/
As I understand it, not all StartCom certificates are necessarily vulnerable. I have a number of StartSSL certificates issued before 4/7 that, according to the HeartBleed checker here[1] are not vulnerable.
Is it wrong for me to assume that the tool is correct, or is it wrong to assume that all StartCom certificates are necessarily vulnerable?
[1] - http://filippo.io/Heartbleed/
What that tool says is irrelevant to the question of whether those certs have been compromised.
The risk is that before the vulnerability was patched, somebody used it to grab the private keys associated with the certs.
The risk is that before the vulnerability was patched, somebody used it to grab the private keys associated with the certs.
> is it wrong to assume that all StartCom certificates are necessarily vulnerable?
They aren't claiming all StartCom certificates are vulnerable, they are saying some StartCom certificates may be vulnerable because they impose a fee on revocation.
They aren't claiming all StartCom certificates are vulnerable, they are saying some StartCom certificates may be vulnerable because they impose a fee on revocation.
I don't think the certificates are vulnerable at all. Their private keys may have been stolen if people were using them with a vulnerable version of OpenSSL, but that has nothing to do with StartSSL certificates themselves.
That is exactly right and exactly why the bug report was insane.
I don't think that "charging for services you said you would charge for" is anywhere near reason enough to revoke a root certificate. I would be very disappointed by Debian if they actually went through with this.
From the customer’s point of view there’s not much to complain about.
If you’re maintaining a CA trust store, it might be a little different. The CA can adopt any pricing structure they want, but the one they’ve chosen will lead some customers to not revoke their certificates, resulting in potentially compromised certificates being used in a way that could have been avoided.
This could definitely factor into your judgment of whether it’s a good idea to trust certificates signed by that CA.
If you’re maintaining a CA trust store, it might be a little different. The CA can adopt any pricing structure they want, but the one they’ve chosen will lead some customers to not revoke their certificates, resulting in potentially compromised certificates being used in a way that could have been avoided.
This could definitely factor into your judgment of whether it’s a good idea to trust certificates signed by that CA.
> A user comment here says the CVE was cited, and StartSSL waived the revocation fee.
Seems like a straightforward solution for them to implement.
Seems like a straightforward solution for them to implement.
Not getting involved in the politics of being charged for revocations/re-keying, however it's worth pointing out that Google Chrome (linux and windows, and Chromium) all seem to have the "Check for server certificate revocation" option disabled by default.
In my experience, enabling it causes strange behavior with some plugins and even Chrome itself at some times. If the CRL check fails, related secure connections will fail with no notification.
This led to a bit of problem with a proxy server at work. A filter update blocked the CRL link, and suddenly nobody in my office could sign into their Chrome browsers. You'd hit "log in", it would appear to work, but nothing happens. An error saying that CRL checks were at fault would have saved a great deal of time....
This led to a bit of problem with a proxy server at work. A filter update blocked the CRL link, and suddenly nobody in my office could sign into their Chrome browsers. You'd hit "log in", it would appear to work, but nothing happens. An error saying that CRL checks were at fault would have saved a great deal of time....
Interesting; thank you for the warning -This explains some of the oddness I've been having this morning after enabling it last night.
I went an checked firefox too which does check CRLs as default but doesn't silently fail if it can't check them (it's a separate tickbox)
I went an checked firefox too which does check CRLs as default but doesn't silently fail if it can't check them (it's a separate tickbox)
Hats off to the Debian developer. I can not believe the report was handled so politely. This is one of the silliest bug reports I have seen. I can not think of what the possible thought process was that led to the formation and submission of this bug report.
# dpkg-reconfigure -p low ca-certificatesTL/DR from the Mozilla bugzilla (https://bugzilla.mozilla.org/show_bug.cgi?id=994033)
There doesn't appear to be a definitive argument as to should they or should they not waive their revocation fee.
On the side of StartCom an extremly resonable point as to why they should not waive their fee:
> 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.
And the also very reasonable counter point:
> 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.
At the very least its refreshing to see that people aren't just jumping on the rage bandwagon of, "OMG you mean I have to pay for something that you said I'd have to pay for. You are evil".
It's nice to see some even handed analysis of the situation!
On the side of StartCom an extremly resonable point as to why they should not waive their fee:
> 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.
And the also very reasonable counter point:
> 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.
At the very least its refreshing to see that people aren't just jumping on the rage bandwagon of, "OMG you mean I have to pay for something that you said I'd have to pay for. You are evil".
It's nice to see some even handed analysis of the situation!
I'm a StartCom user that's affected by Heartbleed. Right now, I am using the free certificates, so this FAQ entry applies (https://www.startssl.com/?app=25#72):
" Revocations carry a handling fee of currently US$ 24.90. Class 1 subscribers may use a different sub domain in order to create additional certificates without the need to revoke a previously created certificate. Alternatively it's possible to upgrade to Class 2 level which allows to create the same set of certificates once again (besides all the other benefits), because different levels are issued by different issuers, making revocation unnecessary."
I understand where Mozilla's coming from here, but I also see it from StartCom's side. StartCom requires manual verification for certain sensitive CA operations, so they've set up their (quite reasonable) fee schedule accordingly. Likewise, I'm sure that the terms and conditions of other CAs states that in the case of a key compromise, sure, they'll revoke the certificate for free, but the user must buy a new certificate to replace the compromised one - which is basically the same thing as StartCom charging for revocation.
" Revocations carry a handling fee of currently US$ 24.90. Class 1 subscribers may use a different sub domain in order to create additional certificates without the need to revoke a previously created certificate. Alternatively it's possible to upgrade to Class 2 level which allows to create the same set of certificates once again (besides all the other benefits), because different levels are issued by different issuers, making revocation unnecessary."
I understand where Mozilla's coming from here, but I also see it from StartCom's side. StartCom requires manual verification for certain sensitive CA operations, so they've set up their (quite reasonable) fee schedule accordingly. Likewise, I'm sure that the terms and conditions of other CAs states that in the case of a key compromise, sure, they'll revoke the certificate for free, but the user must buy a new certificate to replace the compromised one - which is basically the same thing as StartCom charging for revocation.
So, if StartCom is removed from trusted CAs you will have to buy a new certificate and spend $$$, something you obviously want to avoid. That's stupid.
And worse, the Debian developers would be at fault.
This is a sticky situation, really. On one hand, StartCom's pricing structure is fairly upfront. On the other hand, extracting $25 from every customer because of a bug they have no control over is dick behavior of the highest order.
Ideally they'd put out a notice saying that they will offer a one-time rekey for free. Without getting into ethics, it's an entirely automated process and costs Startcom absolutely nothing.
This is a sticky situation, really. On one hand, StartCom's pricing structure is fairly upfront. On the other hand, extracting $25 from every customer because of a bug they have no control over is dick behavior of the highest order.
Ideally they'd put out a notice saying that they will offer a one-time rekey for free. Without getting into ethics, it's an entirely automated process and costs Startcom absolutely nothing.
I don't think it is dick behavior at all. That has always been their policy. They have no control of the software originating the problem. It is up to them to wave or not but not choosing to doesn't make the anything but a business.
So it's a business. So it's policy. Those are not defenses.
A CA profiting from a vulnerability is a fairly perverse incentive, too.
A CA profiting from a vulnerability is a fairly perverse incentive, too.
What else do CAs profit from if it isn't security vulnerabilities?
Their whole purpose is to help with the authentication side of security. They didn't force anyone to use buggy code written by a third party and it is not their fault that many of their customers have gone and done so.
Their whole purpose is to help with the authentication side of security. They didn't force anyone to use buggy code written by a third party and it is not their fault that many of their customers have gone and done so.
I use a StartCom certificate, but it has never been used with OpenSSL, so I'm fine.
It costs money to maintain a CRL.
Maybe they could revoke their intermediate certificate and reissue certificates to everyone. That would take time to coordinate, and every month that goes by 1/12 of the bad certs expire anyway.
It costs money to maintain a CRL.
Maybe they could revoke their intermediate certificate and reissue certificates to everyone. That would take time to coordinate, and every month that goes by 1/12 of the bad certs expire anyway.
It might, but certainly not $25 per instance. That feels a lot like gouging.
It's an awfully sketchy business model. Like inverse insurance.
That's not the issue though. Most people are not StartCom customers and couldn't care less.
They still care about what that padlock icon signifies and that's why it's pertinent of large vendors to consider the CA status of StartCom in a situation like this.
That's not the issue though. Most people are not StartCom customers and couldn't care less.
They still care about what that padlock icon signifies and that's why it's pertinent of large vendors to consider the CA status of StartCom in a situation like this.
> It's an awfully sketchy business model. Like inverse insurance.
You mean "Real Life" if I buy an item from manufacturer X, and it breaks due to a product from manufacturer Y (which almost everyone uses with the product I bought since it's complementary), it would be nice if manufacturer X would replace the item for free, but it's not sketchy or a dick move if they don't.
You mean "Real Life" if I buy an item from manufacturer X, and it breaks due to a product from manufacturer Y (which almost everyone uses with the product I bought since it's complementary), it would be nice if manufacturer X would replace the item for free, but it's not sketchy or a dick move if they don't.
No, not at all. That's not how SSL certificate revocation works.
If the certificate is not revoked when compromised, the party harmed may not be the StartCom customer, but anyone still trusting certificates issued by them.
When this is happening on a large scale, considering the CA status of StartCom is certainly due dilligence.
If the certificate is not revoked when compromised, the party harmed may not be the StartCom customer, but anyone still trusting certificates issued by them.
When this is happening on a large scale, considering the CA status of StartCom is certainly due dilligence.
However, even though I own some certs with StartCom, I personally think this comment has literally no basis.
Looking at the CA market - if anything - we should be happy that a CA like StartCom exists. It is a very small team lead by Eddy Nigg (he is very helpful by the way) and given that they are the ONLY ones (as far as I am aware) offering free certs - we should applaud them. Besides, the fee for revoking is very small.
I also was very much aware that revoking a cert had a charge before I signed up for one - I think it is pretty clear - so not a problem for me at all. Of course if I had to revoke a cert because of StartCom's mistake that would be a different story.
Bare in mind these are only domain validated certificates - perfect for small website owners who wish to offer their site over httpS without paying any extra fee.