Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

StartEncrypt considered harmful today

computest.nl

Post reply on HN
Print view View original

31–40 of 42 posts

Re: StartEncrypt considered harmful today

#31

Post by geofft »

mrkgnao wrote: 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?

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.

Re: StartEncrypt considered harmful today

#33

Post by haikuginger »

philsnow wrote: post #11

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" C…

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

Yup.

Re: StartEncrypt considered harmful today

#34

Post by rocqua »

tremon wrote: post #29
rocqua wrote: post #14

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.

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

Re: StartEncrypt considered harmful today

#35

Post by antif »

mrkgnao wrote: 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?

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.

Re: StartEncrypt considered harmful today

#36

Post by regecks »

pfg wrote: post #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 h…

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.

Re: StartEncrypt considered harmful today

#38

Post by dopamean »

regecks wrote: post #36
pfg wrote: post #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 h…

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?

Re: StartEncrypt considered harmful today

#39

Post by jerf »

dopamean wrote: post #38
regecks wrote: post #36

Earlier quoted context omitted.

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.

Re: StartEncrypt considered harmful today

#40

Post by polynomeal »

raimue wrote: post #20
GavinMcG wrote: post #13

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…

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.
Post reply on HN