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

How not to run a CA

blog.koehntopp.info

Post reply on HN
Print view View original

141–150 of 255 posts

Re: How not to run a CA

#141

Post by thriftwy »

TheDong wrote: post #138
thriftwy wrote: post #40

I think we should use ssh instead of SSL and also ssh instead of username/password pairs. If somebody is doing a distributed chat/social system, I would use ssh if I were them. By ssh I don't mean execution commands but rather encryption/authentication framework.

ssh is, by default, Trust on First Use which is a significantly different model than a Trusted Thirdparty (CAs). There are some well known trade-offs, namely that having everyone manually verify fingerprints on initial connect and again on any server change is a large burden. I don't particularly want to have to go into my bank's local office and verify in person the fingerprint is correct each time they need to rota…

I think it works much better for contacts. You have to verify contact once and then you are assured that it's still the same person.

Re: How not to run a CA

#143

Post by tialaramex »

blattimwind wrote: post #108
tialaramex wrote: post #88

Earlier quoted context omitted.

You say "they of course ignored almost everything in the CSR apart from the public key" but it turns out they went a bit further than that, they also ignored the signature on the CSR. So you could put some other public key in there, add a bogus signature that wouldn't verify and they'd issue certificates for a key you never even controlled. The bad security implications for that scenario are a bit subtle, and situati…

Actually I've never seen a solid argument for why that's a problem. A similar issue exists in PGP, but again it's unclear what the actual problem is. Some (non-x509) PKIs can't do this anyway.

Two people have asked essentially the same thing here, I'll answer this one because it was at the top. I am going to deliberately use a far-fetched scenario rather than invoke specific technologies, because there is no benefit to learning more specific here than "Nope, a competent CA must never allow this to happen".

Alice has public key A, and Bob has public key B, and everybody trusts Charlie the Certificate Agency to issue certificates, Alice has one binding (Alice,A) and Bob has one binding (Bob,B).

Alice controls a missile she will only accept Major Tom's commands. Bob runs firework displays, he accepts the display organizer's commands.

I want to fire Alice's missile. I impersonate Bob, and I trick Charlie into issuing a certificate (Bob,A) because she doesn't verify that I know the Private Key for A. Then I offer (as Bob) to run a really great firework show for Tom, and I give him the (Bob,A) certificate so he can command firework launching.

When Tom sends me a launch message encrypted to A, I simply deliver it to Alice, who launches the missile as I desired.

Alice was never compromised, neither was Tom. Charlie's only mistake was not verifying that I controlled the Private Key for the cert she issued me. Bob was compromised, but he was just running a firework business, he didn't know this was a matter of national security.

Re: How not to run a CA

#144

Post by walrus01 »

This is such a clusterfuck I don't even know where to begin. I am very happy that "pay money" for DV SSL certs is going the way of the dinosaur, with Let's Encrypt.

The only SSL cert you should ever pay money for is $90/year for an EV SSL cert for an ecommerce/product purchasing website where people are entering credit card details. The big friendly green bar GUI element, for non-technical users, is worth it.

Re: How not to run a CA

#145

Post by PuffinBlue »

Bombthecat wrote: post #119
sneak wrote: post #107

Earlier quoted context omitted.

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?

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

I believe at the time they deployed their Universal SSL, which was over four years ago, is absolutely massive scale, and is free, they were the partner that could actually deliver the necessary integration and infrastructure to handle that sort of load.

Also, they were amongst the only ones to offer ECDSA certificates IIRC.

Cloudflare detailed a little bit about this in this and other blog posts:

https://blog.cloudflare.com/universal-ssl-how-it-scales/

Re: How not to run a CA

#146

Post by walrus01 »

herodotus wrote: post #21

letsencrypt is great and I use it. But I don't really get it. All I needed to do was prove that I could place a generated file on the server that I wanted the certificate for. This seems to me to be a very low bar. What am I missing?

That is basically the bar for a "DV" (domain validated) SSL cert. Let's say you are the owner of the domain rupertsdildoemporium.com and want to get an SSL cert. Since you own the domain you control the entries for what nameservers it uses. Since you control the nameservers, you can point the A record for the domain anywhere of your choosing. Or put an arbitrary TXT record in the DNS zonefile. That is the full extent of what you need to prove to get a domain validated SSL cert.

It is complete and total bullshit that DV SSL certs still cost money (thanks LetsEncrypt), anywhere from $9/year to $80/year.

The companies that rely on selling DV validated SSL certs for their business model are polishing the brass doorknobs on the Titanic. It's all going down. Just a question of when.

Re: How not to run a CA

#147

Post by walrus01 »

vsund wrote: post #30
herodotus wrote: post #21

letsencrypt is great and I use it. But I don't really get it. All I needed to do was prove that I could place a generated file on the server that I wanted the certificate for. This seems to me to be a very low bar. What am I missing?

There's a difference in certificate type. Let's encrypt (which only issues basic certificates) just verifies that you're the rightful owner of a domain, not whether the domain is what it says. If you'd like to have more verification for your certificate you need a extended validation certificate (which often costs money). These certificates also include your (company) name and the issuer verifies whether it's correct…

To clarify for people who've never bought one, an EV SSL cert actually involves work by humans at the CA. They do things like obtain copies of your state/provincial corporate registration, business license, LLC registration, local business license, etc. Then the do basic matching that your physical business address of record matches with what your state's Secretary of State has on file for your corporation. It's about a half hour process on the part of the CA of verifying the existence of a real business entity.

Re: How not to run a CA

#148

Post by 0XAFFE »

walrus01 wrote: post #144

This is such a clusterfuck I don't even know where to begin. I am very happy that "pay money" for DV SSL certs is going the way of the dinosaur, with Let's Encrypt. The only SSL cert you should ever pay money for is $90/year for an EV SSL cert for an ecommerce/product purchasing website where people are entering credit card details. The big friendly green bar GUI element, for non-technical users, is worth it.

I would pay for an acme endpoint that is not rate limited.

Re: How not to run a CA

#149

Post by walrus01 »

snuxoll wrote: post #106
discreditable wrote: post #82

Earlier quoted context omitted.

If someone is hijacking BGP to MITM the world, how are the old methods any better?

If you could hijack BGP you could just as easily inject routes to intercept DNS requests as well.

This is why ISPs use tools like RPKI validation of received routes, and things like the ARIN, RADB and RIPE route-servers.

Re: How not to run a CA

#150

Post by acobster »

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?

> mailed 23000 private keys

I had a similar thought. My thought was: "HOLY SHIT!"

Post reply on HN