
StartCom will log all issued SSL certificates to public CT log servers - pfg
https://www.startssl.com/NewsDetails?date=20160323
======
ran290
Context:
[https://news.ycombinator.com/item?id=11330877](https://news.ycombinator.com/item?id=11330877)

~~~
pfg
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](https://www.startssl.com/NewsDetails?date=20160322)

~~~
cypherpunks01
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..

~~~
pfg
It could be that, or the researcher really didn't think to try it with an
address that's completely unrelated to the domain.

Personally, I find it hard to believe that an audited CA has a system where
the web frontend can make a decision as to what would be an allowed
verification email address. I'm leaning towards believing their story, and
would assume they have a backend system which is responsible for checking that
input (and which happened to be out of sync with the options offered by the
frontend). That's a reasonable explanation for the complete lack of validation
in their frontend code.

Then again, some CAs have had a terrible track record, so I guess we'll never
know for sure now that they fixed the issue (whatever the issue actually was).

~~~
BillinghamJ
Honestly, while StartSSL's front-end is awful, their practices always seem to
far exceed other CAs - especially around verification.

I don't enjoy the website, or the verification procedure, but ultimately I
generally trust them pretty highly - they operate in a way which shows me they
care about security.

~~~
creshal
We've been generating certificates in direct violation of their TOS for over
six years. Every few years they pretend to find out, we do another blatantly
non-compliant verification, fork over 120 dollars, and they let us keep
printing certificates.

~~~
debaserab2
Went through the same headaches for a few years. Their atrociously unfriendly
and unintuitive interface finally just pushed me over to using a cheap
alternative that is much less painful (RapidSSL in our case).

~~~
creshal
Until Let's Encrypt came around we've heavily depended on wildcard
certificates (several domains with 100+ customer facing subdomains), so any
other alternative would have been massively more expensive.

But with LE allowing scripted certificate generation, we're just moving to
that instead.

~~~
haroldp
How do you plan to get around LE's 5 subdomains per 7 day period limit? You
can only get about 60 subdomains _in theory_ , and that only if you stagger
the registrations out carefully over three months and never make any mistakes.

~~~
jewel
If appropriate for your use case, you can get your domain added to the public
suffix list [1]. Then the restrictions no longer apply.

This has side-effects with browsers and cookies so you wouldn't want to do it
on a domain without understanding the impact.

[1]:
[https://github.com/publicsuffix/list/blob/master/public_suff...](https://github.com/publicsuffix/list/blob/master/public_suffix_list.dat)

P.S. In the unlikely event that someone involved is reading this, PLEASE make
this a DNS attribute that is set on the top-level domain instead, in a TXT
record perhaps. It's silly that we have to have a globally coordinated and
distributed list for this data.

~~~
pfg
> P.S. In the unlikely event that someone involved is reading this, PLEASE
> make this a DNS attribute that is set on the top-level domain instead, in a
> TXT record perhaps. It's silly that we have to have a globally coordinated
> and distributed list for this data.

The Dbound WG[1] was working on this, but sadly didn't seem to get anywhere.

[1]: [https://tools.ietf.org/wg/dbound/](https://tools.ietf.org/wg/dbound/)

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

~~~
BillinghamJ
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.

~~~
creshal
Setting up your own CA is rather easy, for internal hostnames I'd definitely
not bother with going to an external CA (nor want an external CA to have
control over internal certificates).

~~~
ryan-c
Having set up and run an internal CA for a > 1000 person org that needed to
issue a couple certificates a week, I would refute the "easy" claim.

~~~
creshal
Still easier than StartSSL's horrible, occasionally unreachable, web interface
I'd bet.

~~~
TheSwordsman
I hope you don't often place bets. :P

Honestly, it's not that easy. The StartSSL process is much, much, much easier.

There are a myriad of problems you need to solve when running an internal CA
for your organization. Who has access to generate new certs? Is it automated,
and what security controls are around that system? What audits are there
around certs being cut? Who can revoke certificates? Then you get down to the
details of CRL/OSCP...

While running your own PKI is great and definitely recommended, it's much
easier to say "just set up PKI" than to actually do it and maintain it.

~~~
davenull
I've always enforced a strict policy of every certificate request be asked for
in person by someone with authority to ask us for one, and then a second
person actually issues the certs after an hour, just in case. Nobody likes
being responsible for data breaches, and I for one am a sadist and a masochist
when it comes to keeping control of my systems.

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

~~~
pfg
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](https://www.startssl.com/NewsDetails?date=20160322)

------
cat-dev-null
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
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
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
Oh sure. Can I have your session key? Not your password, just the thing that
lets me reset it, drain your bank account, etc.

