How not to run a CA • Hacker News Board

Re: How not to run a CA

#201

Post by djsumdog » Thu, Mar 01, 2018, 11:59 PM UTC

sneak wrote: post #107

originalsimba wrote: post #96

"Bad Actors" in the tech field tend to flock together. Comodo has been at the center of several really ugly stories, this one being the latest. The CEO of Comodo attempted to sue Lets Encrypt before they launched, in order to kill the project because of the threat it represented to their business model. after 24 hours of backlash from the internet public he backed down and said it was all a misunderstanding. Of cours…

Your argument for guilt by association is not compelling. Cloudflare is their customer. I am Cloudflare’s customer. Does that make me a bad actor too?

Continued usage of Cloudflare baffles me. They spewed tons of private data, across customer boundaries, on random web responses, which made its way into search engine cache around the world. They conducted an act of Internet censorship:

https://fightthefuture.org/article/the-new-era-of-corporate-...

..and the CTO who made that decision later backed down and said he wouldn't make that same decision again. O_o

I really feel like the biggest reason they're still in business is that very few alternatives offer anything really competitive.

Re: How not to run a CA

#202

Post by flamingcow » Fri, Mar 02, 2018, 12:05 AM UTC

TheDong wrote: post #194

tetha wrote: post #135

Earlier quoted context omitted.

I am aware this is not contributing to the thread but... the only way I can summarize my feelings on that is 'holy fuck'. I just spent a minute just muttering 'holy fuck' to myself. They are running the good old php shell of " ". As root. As a security company. This entire company is just blowing my mind at the moment. What's next, are they running their services on a notebook in the office?

What they actually had was probably more like: system('openssl req -config /prod/prod-config.cnf -subj "/CN={$DOMAIN}" ....' And whoever wrote that function assumed someone else had sanitized DOMAIN. It looks like a lot more understandable of a mistake when framed like that.

Does it really? Even if the code author hadn't learned to escape/sanitize close to use so it's visible (or to avoid cases where you need to escape/sanitize entirely, like using something that bypasses the shell and takes array arguments), let's look at the manpages.

PHP's system() manpage: http://php.net/manual/en/function.system.php

  [red box]
  Warning
  When allowing user-supplied data to be passed to this function, use escapeshellarg() or escapeshellcmd() to ensure that users cannot trick the system into executing arbitrary commands.

system(3): http://man7.org/linux/man-pages/man3/system.3.html

  Any user input that is employed as part of command should be carefully sanitized, to ensure that unexpected shell commands or command options are not executed.  Such risks are especially grave when using system() from a privileged program.

This is a canonical mistake that's used as a mistake example in textbooks.

Re: How not to run a CA

#203

Post by jopsen » Fri, Mar 02, 2018, 12:13 AM UTC

devit wrote: post #130

jnbiche wrote: post #87

Earlier quoted context omitted.

> Browsers need to remove all CAs except Let's Encrypt. No. I love Let's Encrypt, but we can't put all our eggs in a single basket like that. Now, if we could somehow foster multiple non-profit organizations like Let's Encrypt, but run under the aegis of different boards and sponsors, I'd be 100% for this idea. It's very odd that companies for whom CAs business is quite literally a money printing operation can't be b…

Security requires that ALL CAs be secure, since any compromised CA can compromise all websites (barring fragile schemes like pinning or certificate transparency checks), so the less CAs there are, the more secure the system is. It's like a building that needs secure doors: it's better to invest in a single, massive, bulletproof, guarded door rather than inviting anyone who meets some standards to add a door to the bu…

Certificate transparency seems like it'll make a compromised CA much less of an issue.

If it can be reliably proven that a CA is compromised, then it can be fixed.

Re: How not to run a CA

#204

Post by peterwwillis » Fri, Mar 02, 2018, 12:29 AM UTC

jiggliemon wrote: post #55

dx034 wrote: post #26

Earlier quoted context omitted.

This probably happened because they allowed users to execute root commands on their server. Either they quickly shut down the site or someone else did it by shutting down some servers. > https://twitter.com/svblxyz/status/969220402768736258

Oh my. There must be some sort of hall of fame for security vulnerabilities. And this belongs in it. Perhaps they’re passing this command to a secured container? I shouldn’t make excuses for them, but passing root commands to the shell seems too far out there.

> There must be some sort of hall of fame for security vulnerabilities.

It's called the Pwnie Awards.

https://pwnies.com/

Re: How not to run a CA

#205

Post by originalsimba » Fri, Mar 02, 2018, 12:32 AM UTC

sneak wrote: post #107

originalsimba wrote: post #96

"Bad Actors" in the tech field tend to flock together. Comodo has been at the center of several really ugly stories, this one being the latest. The CEO of Comodo attempted to sue Lets Encrypt before they launched, in order to kill the project because of the threat it represented to their business model. after 24 hours of backlash from the internet public he backed down and said it was all a misunderstanding. Of cours…

Your argument for guilt by association is not compelling. Cloudflare is their customer. I am Cloudflare’s customer. Does that make me a bad actor too?

I'm not suggesting guilt by association. What I'm suggesting is that the crooked CEO of $Comodo and the crooked CEO of $Cloudflare probably made some back room deals where they laughed about how they'd be taking advantage of all the peasants who've made them both wealthy.

I'm simply pointing out that when you have incompetent and crooked people in tech, they often run in packs.

You might argue that altruism has no place in business but I disagree. When the CEO of Comodo launched his attack on Let's Encrypt, Cloudflare had opportunity to cut all ties with them. There's plenty of other CAs they could work with. They chose to ignore that scandal, and that matters.

Re: How not to run a CA

#206

Post by originalsimba » Fri, Mar 02, 2018, 12:34 AM UTC

prdonahue wrote: post #195

Bombthecat wrote: post #119

Earlier quoted context omitted.

The question is: why does cloadflrare even use them? There are like ten thousand other options...

We use several CAs to issue—Comodo, DigiCert, GlobalSign—and will be adding Let's Encrypt once they support i) SHA-2/ECDSA signatures and ii) wildcards. Having multiple issuers is important for us as each CA, at some point in time, has operational issues. Additionally, as you've seen with Symantec, browsers take action to distrust certain issuers/roots. When either of these scenarios happens, our customers don't care…

If Cloudflare wants wildcards it's so they can have multiple customers, each using completely different origin servers, on a single certificate, which makes those certificates worthless, and I hope Let's Encrypt blacklists Cloudflare from using them when wildcards are launched.

Re: How not to run a CA

#207

Post by Manozco » Fri, Mar 02, 2018, 12:35 AM UTC

slrz wrote: post #179

teraflop wrote: post #153

Earlier quoted context omitted.

> You have to verify contact once Only if users never replace their keys, which puts them at significant risk in the event of a key compromise.

Replace your key by signing a message announcing your new key?

If your key is compromised, anyone can send that message and sign it with your key... :)

Re: How not to run a CA

#208

Post by Sukotto » Fri, Mar 02, 2018, 12:50 AM UTC

tetha wrote: post #135

mkhalil wrote: post #61

In related news, Trustico's site is down apparently due to users being able to run commands as root on their webserver. I wonder if this was used to extract some private keys? https://twitter.com/svblxyz/status/969220402768736258 https://twitter.com/Manawyrm/status/969230542578348033

I am aware this is not contributing to the thread but... the only way I can summarize my feelings on that is 'holy fuck'. I just spent a minute just muttering 'holy fuck' to myself. They are running the good old php shell of " ". As root. As a security company. This entire company is just blowing my mind at the moment. What's next, are they running their services on a notebook in the office?

I propose a new term: "Clown Car" security.

For situations like this where a fiasco just keeps getting worse, each step its own facepalm.

* Asking users to generate private keys on the issuer's server

* Storing those private keys

* Emailing those private keys

* Sending that email completely in the clear

* Running unsanitized user input on their server

* as root

Re: How not to run a CA

#209

Post by peterwwillis » Fri, Mar 02, 2018, 12:51 AM UTC

majewsky wrote: post #74

0xbadcafebee wrote: post #52

> TL;DR: Forget your EV or other certs. Just run “Let’s Encrypt”. It gets you a cert, it’s fresh, and it does not make any difference whatsoever. At least not any you or anyone else can check for, or cares for. Let's Encrypt shut down their new test interface because of a security flaw they found. If this was in a production service, this would have been about as bad of a security flaw as is possible in a PKI system.…

That doesn't make sense. You cannot criticize someone for finding an issue in the testing environment before it hits production. That's literally what the testing environment is for.

I was not criticizing them (can you quote the part of my comment that was critical?). I was illustrating that they are not perfect, and just using them without considering that they too could be compromised is a bad idea.

Re: How not to run a CA

#210

Post by dredmorbius » Fri, Mar 02, 2018, 1:36 AM UTC

inetknght wrote: post #160

dredmorbius wrote: post #126

Earlier quoted context omitted.

HTTP plus a trusted hash would provide an integrity measure of the content of a page, and enable hashing. It would not prevent anyone from examining that content in flight, or altering it. It would allow any such alteration to be identified . It is possible to offer various levels of assurance on unencrypted communications. Mind: I'm describing a possible world, not the one most of us happen to live in. Unless, say,…

You cannot have a "trusted hash" if you cannot trust the delivery mechanism (unencrypted and unauthenticated TCP). The content of the delivered payload (your blog and your "trusted hash") can be altered by anyone in transit. When you take unencrypted and unauthenticated TCP and upgrade to encrypted and authenticated TLS, only then can you begin to have trust.

False.

That is what PGP / GPG's Web of Trust offers.