StartEncrypt considered harmful today | Hacker News Reader

StartEncrypt considered harmful today

computest.nl

248 pointsbartkappenburg40 comments

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

[2]: https://github.com/cabforum/documents/pull/25/files?short_pa...

My guess is simple. As software design and development was not part of their product life-cycle, they outsourced both client and API to whomever bid least on Upwork.

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.

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?

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

Neat. Maybe they can even put license compliance on their roadmap (they statically linked in OpenSSL).

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.

Thank you. Wow.

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

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.

Yeah, I'd like that too. For a while I was running with StartSSL removed entirely, but eventually I run into sites that used them, that I just couldn't live without.

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

http://www.techfleece.com/2011/09/09/how-to-delete-the-digin...

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

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

And that's before we get into their mafia-like tactics when it comes to the mass-leak fiasco that was Heartbleed.

Startcom is unsafe, unethical, and the kiss of death for a CA, cannot be trusted.

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.

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/, where everything else .localtest.me resolves to 127.0.0.1, and they tried to post a wildcard, but it got revoked.

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?

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

Yup.

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

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... [2] https://community.letsencrypt.org/t/attack-on-domain-verific...

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

Those are not comparable. For better or worse, the attacks you speak of are not covered by DV's threat model, and all DV-issuing CAs--not just Let's Encrypt--suffer from them.

The Startcom vulnerabilities, on the other hand, are much easier to exploit and clearly violate DV's threat model.

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?

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

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.

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.

Vulnerafeature is my new favourite word.

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

It's also a shame they designed their own protocol instead of just using ACME[1], which is a standards-track IETF draft which has received significant security scrutiny. By ignoring ACME, they even managed to replicate my duplicate signature key selection vulnerability that was fixed in ACME nearly a year ago!

[1] https://datatracker.ietf.org/wg/acme/charter/

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

They were untrusted for about a month at least. September 14 - October 19 https://letsencrypt.org/blog/

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

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

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.

The requirements and procedures are discussed in the CA Browser Forum: https://cabforum.org/

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?

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.

The CA determines "permission of Google" by "can put something on a web page at google.com". This is well-accepted, and as long as the CA's own connection to the internets is hard to MITM, it's pretty reasonable for what domain-validated SSL does. (If you want more security than that, try EV, or something other than SSL.)

Usually, "a web page at google.com" means to put a specific, CA-picked string at a specific, CA-picked URL. The ACME protocol has you put it under /.well-known/, which is reserved for this sort of thing. Other CAs will give you a randomly-generated filename. The intention is that you shouldn't be able to, say, upload a file to GitHub or some forum and claim control of it; you actually have to operate the site.

StartEncrypt neglected to enforce that check.

For google.com in particular, when you click "Sign in with Google" to a third-party service, it sends you to a URL on google.com, and google.com will redirect you back to the third-party site when it's done. What the attacker does is they set up their own website and enable Google sign-in on it (which anyone can do without Google's permission). Then they sign in, and save the URL that's redirecting them back, and send that URL to StartEncrypt. StartEncrypt dutifully follows the redirect when fetching content from google.com, and tricks itself into thinking the file was actually at google.com.

In short: they are granted that capacity by your browser or operating system.

Hundreds of other companies also have the same ability, with new grants and revocations of trust occurring over time.

Reply on news.ycombinator.com