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

71–80 of 255 posts

Re: How not to run a CA

#71

Post by warent »

Ajedi32 wrote: post #64
warent wrote: post #51

Earlier quoted context omitted.

Cue the intro to Bohemian Rhapsody. This is a huge WTF. SQL injection? Too basic. We do raw shell injection now. To a CA. Welcome to the future of computers where security comes secondary to extra profits and marketing.

FWIW, Trustico isn't a CA. They're a certificate reseller; all certificate validation is handled by a different company. If Trustico hadn't been generating their customers private keys for them (or if their customers had refused to let them do things that way) they wouldn't have been able to screw things up this badly.

Got it, that kind of makes sense. The concept of certificate reseller doesn't make a whole lot of sense to me but thank you for making the distinction

Re: How not to run a CA

#72

Post by majewsky »

Ajedi32 wrote: post #57
ChrisSD wrote: post #14

Earlier quoted context omitted.

It sounds like Trustico got these certificates from Symantec. The CEO of Trustico was arguing that they should be revoked as they weren't secure and emailed the private keys as proof. Which, while a dumb thing to do, did prove his point I guess. EDIT: From Trustico's account > We believe the orders placed via our Symantec account were at risk and were poorly managed. We have been questioning Symantec without response…

Why would they not try to transition their customers to new certs _before_ getting all the old certs revoked though? Seems like suddenly revoking 23k of their customer's certs with only 24 hours notice is just shooting themselves in the foot.

We're using the Symantec/Digicert API for getting certs at work. I'm not directly involved in that, but I think when you want to issue a new cert you have to revoke the old one first. The API will just return an error if there is an existing cert for the same domain name.

I recall vividly that when we moved from manually-issued certs (using their website) to automatic issuing (using their API), we had to revoke all certs before starting the automatic job for the first time. I don't know how it works wrt moving from the old Symantec root to the new Digicert root; I'm not directly involved in that.

Oh, and BTW, of course we're investigating moving to Let's Encrypt instead, if only because we can use an existing ACME client and don't have to continue maintaining our own certificate automation.

Re: How not to run a CA

#73

Post by nemoniac »

sphix0r wrote: post #10

Ironically his blog isn't available on https. Would be time that browers mark http sites' address bar as "Not secure" in orange. It's either secure or it isn't. Fun fact; Europe's ePrivacy law is coming next year which enforces all communication to be secure.

Europe's GDPR data law contains no such stipulation.

Re: How not to run a CA

#74

Post by majewsky »

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.

Re: How not to run a CA

#75

Post by rkangel »

nailer wrote: post #60

> TL;DR: Forget your EV or other certs. Just run “Let’s Encrypt”. The author has a fundamental misunderstanding of the situation [1]. Trustico's awful decisions regarding a) storing customers private keys and b) improperly handling key material Have no bearing whatsoever on EV certs, which verify the legal entities that run websites. This is like saying Trustico is bad, therefore HTTPS is bad. [1] Assuming this is wh…

There is at least some merit to the argument that "Trustico Bad" => "CAs bad" => "HTTPS Bad".

More than one CA has been shown to be extremely lacking in trustworthiness and that trust is important. I'm OK with the centralised model but there needs to be a bit more visibility of the CA process.

Re: How not to run a CA

#76

Post by dpark »

cup-of-tea wrote: post #69
simonw wrote: post #36

Earlier quoted context omitted.

Could you help us out by explaining what this comment is misunderstanding?

You wouldn't trust a chain that long with something that sensitive. WOT gives you the ability to have different tiers of trust. If you verified the identity yourself then you can trust it completely. If you accept people verifiying identities on your behalf then you can choose exactly who you trust (ie. not everyone). It not only makes the delegation explicit, it gives you much more fine grained control about how muc…

Yeah, web of trust gives me the option to manually decide, every time, if the chain(s) of trust looks "good enough" for me to trust the other party. There are two problems with this:

1. This is a ton of work and a lot of guesswork even for educated individuals. I end up looking at either explicit chains of trust (I trust Bob and he trusts Alice and she says that this is definitely my bank's website) or some random value an algorithm spits out that tries to convey how "trusted" an entity is based on how many paths there are to it and how short they are. In either case, it's a manual decision that will often feel arbitrary.

2. Laypersons are completely fucked. No way my grandmother can reasonably decide who to trust this way.

If web of trust ever becomes widespread somehow, I guarantee you a month later Google and Apple and Microsoft will become the de facto CAs because everyone will just look to them in the web of trust and see if one of them vouches for their banking website.

Re: How not to run a CA

#77

Post by u801e »

aiCeivi9 wrote: post #6
firloop wrote: post #2

The thing that isn’t clear to me is how Trustico even had the private keys to begin with. It’s been a while since I’ve purchased a SSL certificate, but I remember generating the private key locally and providing a certificate signing request, which isn’t the private key. What am I misunderstanding here?

"Trustico allows customers to generate a Certificate Signing Request and Private Key during the ordering process," the statement read. "These Private Keys are stored in cold storage, for the purpose of revocation." Maybe they decided preparing CSR is too hard for their clients :/

> Maybe they decided preparing CSR is too hard for their clients :/

It seems that a lot of businesses and people feel that making things "easier and more convenient" takes priority over best security practices. For example, we can't support client side TLS cert authentication (in addition to a username and password) because customers won't be able to generate the CSR or know how to import the certificate into their client. Instead, let's use SMS or email based two factor authentication.

Re: How not to run a CA

#78

Post by devit »

Browsers need to remove all CAs except Let's Encrypt.

CAs have proven again and again to be ridiculously insecure, and the problem is that there is no penalty for their mistakes.

So just remove them all, after a warning period: Let's Encrypt is enough.

Or if they want to stay in business and be trusted by browsers, then require them to put up at least $100k in cash in escrow for each certificate they sign, which is forfeit if there's evidence that any compromise of that specific certificate, due to their fault, has or may have happened, with at least half of the money being distributed to whoever provides the evidence first.

Re: How not to run a CA

#79

Post by Piskvorrr »

majewsky wrote: post #72
Ajedi32 wrote: post #57

Earlier quoted context omitted.

Why would they not try to transition their customers to new certs _before_ getting all the old certs revoked though? Seems like suddenly revoking 23k of their customer's certs with only 24 hours notice is just shooting themselves in the foot.

We're using the Symantec/Digicert API for getting certs at work. I'm not directly involved in that, but I think when you want to issue a new cert you have to revoke the old one first. The API will just return an error if there is an existing cert for the same domain name. I recall vividly that when we moved from manually-issued certs (using their website) to automatic issuing (using their API), we had to revoke all c…

That doesn't make sense. Old cert expires 2018-03-01 23:59:59, yet I'm not even allowed to apply for a new one valid from 2018-03-02 00:00:00?

Re: How not to run a CA

#80

Post by LoSboccacc »

blattimwind wrote: post #53
kasperni wrote: post #13

They have a tool that allows you create a private key + CSR https://www.trustico.com/ssltools/create/csr-pem/create-a-ne... Apparently they decided to keep a copy of the private key. Edit: Looks like they are having problems atm. A copy can be found at https://web.archive.org/web/20180217071027/https://www.trust...

Up until a few years ago there was a tag which embedded a x509 CSR generator into a regular HTML form. The private key was generated by the browser(1) and was completely inaccessible to the site or any JS running on it. That's the proper way to generate certificates in browsers, but it's been removed since and was never supported in IE. StartSSL used it, for example, but also allowed you to hand them a CSR of your ow…

they didn't support the tag but you could do the same using activex components, seen once one vpn enrollment website doing that.
Post reply on HN