StartCom will log all issued SSL certificates to public CT log servers

https://www.startssl.com/NewsDetails?date=20160323

by pfg • 10 years ago

74 53 10 years ago

ran290• 10 years ago

Context: https://news.ycombinator.com/item?id=11330877

pfg8• 10 years ago

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.

[1] https://www.startssl.com/NewsDetails?date=20160322

cypherpunks01• 10 years ago

That is real confusing, wouldn't that imply one party is outright lying?

Blog claims: In the last step of the validation process is where you can modify the email address and replace it with any regular email address

StartSSL claims: The email address used to verify the domain name is listed in the WHOIS records..

nailer• 10 years ago

Reminds me of Symantec's "we really like CT too, and have spontaneously decided to use it for all our certs" after Google ripped them a new one and demanded they do it: https://security.googleblog.com/2015/10/sustaining-digital-c...

BillinghamJ10• 10 years ago

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.

DoubleMalt• 10 years ago

If they are internal hostnames, don't you control both client and server? Why not create a PKI?

In my opinion the only advantage certificates from official CAs bring is that clients you have no control over are not MitMed.

BillinghamJ10• 10 years ago

Well yeah, that is a fair point actually. There would be a couple of issues to sort out, but nothing major or anything we couldn't deal with.

pfg8• 10 years ago

I think the end-game for CT is that all certificates will have to be submitted to log servers, so this is going to happen anyway.

hannob• 10 years ago

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.

Namidairo3• 10 years ago

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.

BillinghamJ10• 10 years ago

Most of these hostnames are on 10.x IPs, so not internet addressable anyway, but we don't really want to advertise how our internal services are structured.

geofft2• 10 years ago

The current CT draft spec permits the CA to generate a precertificate containing "?.example.com" instead of "secretproject.example.com", for exactly this reason:

https://tools.ietf.org/html/draft-ietf-trans-rfc6962-bis-13#...

Namidairo3• 10 years ago

I don't think that was really an option in this case as his CA just went and published the logs without asking the users first?

technion• 10 years ago

     not any of our wildcard

But if you get a wildcard, it doesn't leak anything about the names or details of your internal servers.

BillinghamJ10• 10 years ago

Not really true. Wildcard certs only work for one level of labels. As such, we still have to include quite a large proportion of a set of our internal hostnames in the cert

tptacek• 10 years ago

They pretty much have to, right? The alternative is for Google to make the announcement for them.

pfg8• 10 years ago

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.)

[1] https://www.startssl.com/NewsDetails?date=20160322

cat-dev-null• 10 years ago

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).

iancarroll• 10 years ago

If you believe it is relatively easy to issue a certificate for a domain you do not own, I am sure many people would like to hear about it.

Animats• 10 years ago

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.

IgorPartola• 10 years ago

Oh sure. Can I have your session key? Not your password, just the thing that lets me reset it, drain your bank account, etc.

StartCom will log all issued SSL certificates to public CT log servers

Related Stories