
StartEncrypt considered harmful today - bartkappenburg
https://www.computest.nl/blog/startencrypt-considered-harmful-today/
======
pfg
I can't believe that they not only decided not to implement ACME (the protocol
behind Let's Encrypt), but also not to at least reuse large portions of ACME,
like the way HTTP ownership validation was implemented. It's simply mind-
boggling how they would discard a protocol that has received a lot of
attention from various security experts. What's more, this design could not
have been reviewed by _anyone_ familiar with how the web works - allowing
users to chose the path for HTTP domain validation is so incredibly dangerous
... sigh.

If you're curious if there are any rules for CAs that describe how domain
validation must be performed, the current Baseline Requirements can be
summarized with "do something that's safe" on that topic. A working group
within the CA/B Forum[1] is currently working on revising the document and
adding explicit rules declaring which methods are permitted. I believe [2] is
the latest draft.

[1]:
[https://cabforum.org/mailman/listinfo/validation](https://cabforum.org/mailman/listinfo/validation)

[2]:
[https://github.com/cabforum/documents/pull/25/files?short_pa...](https://github.com/cabforum/documents/pull/25/files?short_path=7f6d14a#diff-7f6d14a20e7f3beb696b45e1bf8196f2)

~~~
regecks
FWIW I got in contact with their R&D team earlier last week and they told me:

    
    
        no StartEncrypt API now, later it will support IETF ACME, maybe open source.

~~~
dopamean
I really don't understand why they wouldn't just implement ACME first if they
really do plan on getting around to it. What benefit do they really have of
trying to go out on their own on this?

~~~
jerf
"What benefit do they really have of trying to go out on their own on this?"

Apparently, "substantially negative".

Grabbing an open-source ACME implementation really is the canonical value
proposition for open source. Work together to make it secure, every individual
contributor (once it exists) does less work over all, and even _had_ they
successfully implemented StartEncrypt the first time, the value would be in
hosting it and attaching their reputation to it, not the API design. So even
the usual objections to using open source in a commercial setting hardly
apply. There's not much in the way of "look and feel", and no matter how this
was going to happen the actual "polish" was going to be done by creating a new
website that they could make as polished as they like with no trouble.

In other words, they have _comprehensively_ flubbed this. Even once the code
is fixed, the reputation damage is done.

Don't. Implement. Crypto.

------
Confiks
tl;dr: StartSSL would issue certificates for sites like Github and Dropbox,
and practically any site offering OAuth2, without having to have control over
the domain.

StartEncrypt by StartCom/StartSSL has a LetsEncrypt-like verification process
wherin the ownership of the domain is verified by doing a HTTP request, and
having the listening webserver return a specific token.

The problem was that they allowed the user to choose the path on the domain,
and so when you for example would host a raw file on Github or Dropbox, you
could issue a certificate for that domain. Also, it would follow redirects,
even to other domains, and with OAuth2 practically mandating open redirects,
this was easy to do on many sites.

~~~
mafuy
Thank you. Wow.

~~~
arcticfox
Woah. I have zero security experience or acumen and I probably could have
found that vulnerability. Remarkably poor.

------
rocqua
Is there any way to semi-blacklist CAs in the browser?

I'd like to be warned about certificates from certain CAs without access to
that site being blocked. That way I can still reach these sites, but know not
to trust them with confidential data. It also allows me to ask those sites to
use a CA I trust.

The point being to be able to punish CAs less harshly than the death-sentence
that is root removal.

~~~
tremon
There is, but how depends on the browser. Luckily :( we have precedents:

[http://www.techfleece.com/2011/09/09/how-to-delete-the-
digin...](http://www.techfleece.com/2011/09/09/how-to-delete-the-diginotar-ca-
certificate-in-chrome-firefox-and-ie/)

~~~
rocqua
The issue with that solution is that it will treat such certificates as
essentially self-signed. This means that it will essentially blocks access to
sites. I want a softer approach. Say one that strikes through the https in the
URL.

Essentially I am looking to be told about certificates signed by certain CAs
without them actually interfering with my browsing. Kinda like this:
[https://chrome.google.com/webstore/detail/tlsa-
validator/gmg...](https://chrome.google.com/webstore/detail/tlsa-
validator/gmgeefghnadlmkpbjfamblomkoknhjga)

------
Ruud-v-A
I distrusted all StartCom certificates anyway after 2014; StartCom is a rogue
CA who certify the authenticity of sites which they _know_ have been
compromised. Read the story here:
[https://web.archive.org/web/20140412085458/https://revokame....](https://web.archive.org/web/20140412085458/https://revokame.tonylampada.com.br/)
(the original page disappeared mysteriously a few days after the story was
published). And the HN thread about the incident:
[https://news.ycombinator.com/item?id=7577290](https://news.ycombinator.com/item?id=7577290)

~~~
Tomte
That publicity stunt by some over-zealous guy cannot be called a "compromised
key".

Intentionally publishing something is diametrically opposed to having
something compromised.

That was simply an attempt to shirk his contractual obligations with StartCom
and get internet points at the same time.

~~~
geofft
Yeah, IMO it would have been entirely reasonable for StartCom to revoke the
cert for free and cancel the account.

Also, the flip side of this is that occasionally (but very rarely), people
_want_ their private key to be a publicly accessible. See
[http://readme.localtest.me/](http://readme.localtest.me/), where everything
else .localtest.me resolves to 127.0.0.1, and they tried to post a wildcard,
but it got revoked.

------
philsnow
Certificate authorities are the (shaky af) basis of the entire trust chain of
the web.

Because its root certificate is in everybody's CA bundle, StartCom had a moral
responsibility to understand the security around this product. This is
negligence.

I don't have any StartCom certificates right now, but I sure won't have any in
the future after this display.

What would a "CA death penalty" look like? They're a "root" CA, is there an
entity that signed their root certificate that could issue a revocation? Or
would we have to get all the OS and browser vendors to agree to phase out
their root after some time?

~~~
haikuginger
> Or would we have to get all the OS and browser vendors to agree to phase out
> their root after some time?

Yup.

------
Karunamon
For those of you that wish to ensure your Macs never trust these amateurs ever
again:

* Applications -> Utilities -> Keychain Access

* Select System Roots on the top bar, then Certificates on the bottom one

* Double click on the 3 StartCom certificates in the list, and flag them as "Never Trust".

Verify by trying to access [https://startssl.com](https://startssl.com)

------
Animats
Let's Encrypt had a similar vulnerability late last year.[1] That was
successfully exploited in a malware attack. There's also a potential BGP
attack.[2]

Validating that a host is on the correct domain is very hard in the presence
of attacks. DNS can be spoofed. If there was an easy way to verify domains,
CA-issued SSL certs would be unnecessary.

[1] [http://blog.trendmicro.com/trendlabs-security-
intelligence/l...](http://blog.trendmicro.com/trendlabs-security-
intelligence/lets-encrypt-now-being-abused-by-malvertisers/) [2]
[https://community.letsencrypt.org/t/attack-on-domain-
verific...](https://community.letsencrypt.org/t/attack-on-domain-verification-
with-bgp-hijacking/169/12)

~~~
pfg
> How was this attack carried out? The malvertisers used a technique called
> “domain shadowing”. Attackers who have gained the ability to create
> subdomains under a legitimate domain do so, but the created subdomain leads
> to a server under the control of the attackers. In this particular case, the
> attackers created ad.{legitimate domain}.com under the legitimate site.

That's quite different. The attackers appear to have had full control of DNS
in that case. Being able to control DNS is essentially the definition of
domain ownership. Fraudulent issuance would be the smallest problem for a site
affected by this. They'd have gotten a certificate from practically any CA
issuing DV certificates.

Domain validation is messy and far from perfect, but this vulnerability is
just inexcusable.

------
ultramancool
Welcome to the world of certificate authorities, where the dumbest decision
maker means the whole system is a joke.

If you're a government authority or even just a individual looking to get a
nice signed certificate for some big domains you need look no further than
that giant CA list. Any one of thousands. It's damn hard to have one developer
write something reasonably secure, how hard do you think it is to have
thousands write everything perfect?

------
jxcl
Will StartSSL suffer any negative consequences of this? They've presumably
issued certificates they shouldn't have. What happens to them?

~~~
pfg
It's unlikely that they'll suffer any consequences. The CA death penalty (i.e.
root removal) is usually only used in cases of massive breaches, like in the
case of DigiNotar. Sometimes, root programs force CAs to adopt things like
Certificate Transparency or limit CAs to certain TLDs as a result (i.e. a CA
that primarily issues certificates for a specific country might be name-
constrained to that ccTLD to minimize the risk for other TLDs), but that
wouldn't apply here as StartCom already uses Certificate Transparency and they
don't really have a "primary" ccTLD they issue for.

------
jtchang
So this is actually huge. The StartCom CA is trusted in almost every damn
browser (mobile or otherwise).

This is basically saying the CA's private key has been leaked. Because the end
result is the same: I can now issue a certificate for any damn domain I want
and have it trusted.

The certificate authority system is broken.

------
gpvos
Vulnerafeature is my new favourite word.

------
sigio
Shame that these elemental security issues were present in the first case, and
that StartCom went live with such an 'untested' and 'unaudited' product
without doing a public-beta like Lets-Encrypt did (with non-trusted-by-default
certificates).

~~~
schoen
During Let's Encrypt's beta, the certificates were already publicly trusted.

~~~
sp332
They were untrusted for about a month at least. September 14 - October 19
[https://letsencrypt.org/blog/](https://letsencrypt.org/blog/)

------
GavinMcG
Is there a guide out there for how browser users can protect themselves from
untrustworthy CAs?

~~~
raimue
First of all, how do you define "untrustworthy"? Usually you delegate that
decision to your browser vendor or OS distribution. If you no longer trust
them for a specific CA, why trust them for any of the others?

Browsers may rely on the certificate store and trust settings provided by your
OS. For example, Firefox always uses their own certificate store, while Chrome
relies on the system.

certsimple has this guide on how to remove or distrust certificates in various
browsers:

[https://certsimple.com/blog/control-the-ssl-cas-your-
browser...](https://certsimple.com/blog/control-the-ssl-cas-your-browser-
trusts)

~~~
polynomeal
Does anyone know how browsers go about deciding which CAs to trust? It seems
like browsers should be auditing CAs if they are going to be making this
decision on our behalf. An audit should have caught this design flaw.

~~~
raimue
The requirements and procedures are discussed in the CA Browser Forum:
[https://cabforum.org/](https://cabforum.org/)

------
mrkgnao
SSL/info sec/whatever noob here. Why _can_ they produce certificates for, say,
google.com without the permission of Google? Or am I reading the article
wrong?

~~~
pfg
Slightly simplified: Each and every CA that's trusted by your browser is
capable of issuing a certificate for _every single domain_ on the internet. A
certificate is basically nothing more than a document saying "StartSSL has
verified that the certificate you're seeing right now belongs to the owner of
google.com", with some crypto sprinkled on top.

The only thing that's preventing you from getting a certificate for any domain
are software checks implemented on their end. If one of these checks fail
(i.e. because the methodology is broken, or there's a bug, or they can be
bypassed), you can get a certificate for any domain.

