It's worth pointing out that StartCom claims the verification email address in the article in question was only accepted because it matched the WHOIS record of said domain[1], which is permitted according to CA/B Baseline Requirements and their CPS. Definitely not a good choice by the researcher either way.
As a Class 4 StartCom subscriber, this is quite irritating.
We use StartCom to issue a lot of certificates for sensitive internal hostnames. While we don't rely on security by obscurity, we'd really prefer it if our internal hostnames weren't published all over the internet... :\
Given Lets Encrypt does this too, I'm not sure what other options we have with regards to certificates without paying on a per-certificate basis. :( I like StartCom's model of only paying for verifications (i.e. the only thing which really directly costs money).
We definitely want our EV certs going to CT logs, but not any of our wildcard or Class 2/3 certificates.
The plan for CT was always to be once extended to all certs. And I think this is right. This whole system has suffered from security failures kept under the rug for too long, more transparency is good.
If you don't want transparency of your certificates don't participate in the public CA system. You still have the option of using wildcards for internal names.
The current CT draft spec permits the CA to generate a precertificate containing "?.example.com" instead of "secretproject.example.com", for exactly this reason:
Did all of those internal hostnames need to be accessed over the internet in the first place?
I don't envy you though, that's quite a few subdomains you have there. Although I think that quite a few/almost all of those would have been found anyway if someone were to throw their dictionary at it.
Not sure about that, based on this[1]. The turnaround time for this is a bit too fast for it to be just a reaction to that incident, I think. (Not saying that it's a coincidence either.)
SSL CA's are broken in some sense in that it's currently relatively easy to acquire rogue certs because it's a Tragedy of the Commons of the unaddressed issue of a single-source of truth, trust and cert issue authorization for cert management for a given domain.
Perhaps all CAs for should be married to internet-facing domains with an encrypted, authoritative, non-repudiable cert discovery protocol... perhaps something like DNSSEC+DANE or something else.
Likely the only way to fix the situation is make some nonrepudiable proof-of-domain-ownership mandatory before any CA can issue any cert... although that doesn't solve the other issue of clients figuring out which certs to trust, although there have been some web-of-trust efforts to improve it (un-authoritatively).
The next step is to have browsers check the CT database for any page that requires a login. Pages you just look at aren't really security-critical; it's user input that matters.
[+] [-] ran290|10 years ago|reply
[+] [-] pfg|10 years ago|reply
[1]: https://www.startssl.com/NewsDetails?date=20160322
[+] [-] nailer|10 years ago|reply
[+] [-] BillinghamJ|10 years ago|reply
We use StartCom to issue a lot of certificates for sensitive internal hostnames. While we don't rely on security by obscurity, we'd really prefer it if our internal hostnames weren't published all over the internet... :\
Given Lets Encrypt does this too, I'm not sure what other options we have with regards to certificates without paying on a per-certificate basis. :( I like StartCom's model of only paying for verifications (i.e. the only thing which really directly costs money).
We definitely want our EV certs going to CT logs, but not any of our wildcard or Class 2/3 certificates.
[+] [-] hannob|10 years ago|reply
If you don't want transparency of your certificates don't participate in the public CA system. You still have the option of using wildcards for internal names.
[+] [-] DoubleMalt|10 years ago|reply
In my opinion the only advantage certificates from official CAs bring is that clients you have no control over are not MitMed.
[+] [-] pfg|10 years ago|reply
[+] [-] geofft|10 years ago|reply
https://tools.ietf.org/html/draft-ietf-trans-rfc6962-bis-13#...
[+] [-] Namidairo|10 years ago|reply
I don't envy you though, that's quite a few subdomains you have there. Although I think that quite a few/almost all of those would have been found anyway if someone were to throw their dictionary at it.
[+] [-] technion|10 years ago|reply
[+] [-] unknown|10 years ago|reply
[deleted]
[+] [-] tptacek|10 years ago|reply
[+] [-] pfg|10 years ago|reply
[1]: https://www.startssl.com/NewsDetails?date=20160322
[+] [-] cat-dev-null|10 years ago|reply
Perhaps all CAs for should be married to internet-facing domains with an encrypted, authoritative, non-repudiable cert discovery protocol... perhaps something like DNSSEC+DANE or something else.
Likely the only way to fix the situation is make some nonrepudiable proof-of-domain-ownership mandatory before any CA can issue any cert... although that doesn't solve the other issue of clients figuring out which certs to trust, although there have been some web-of-trust efforts to improve it (un-authoritatively).
[+] [-] iancarroll|10 years ago|reply
[+] [-] Animats|10 years ago|reply
[+] [-] IgorPartola|10 years ago|reply