Live data from Hacker News

StartEncrypt considered harmful today

computest.nl

1–10 of 42 posts

Re: StartEncrypt considered harmful today

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

Re: StartEncrypt considered harmful today

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

Re: StartEncrypt considered harmful today

#4
post #2

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 t…

Thank you. Wow.

Re: StartEncrypt considered harmful today

#5
post #3

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/

Re: StartEncrypt considered harmful today

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

Re: StartEncrypt considered harmful today

#8
post #7

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.

Re: StartEncrypt considered harmful today

#10
post #9

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.

Post reply on HN