How not to run a CA • Hacker News Board

Re: How not to run a CA

#91

Post by yjftsjthsd-h » Thu, Mar 01, 2018, 5:07 PM UTC

zeveb wrote: post #38

nfoz wrote: post #15

Earlier quoted context omitted.

I think the real sentiment here is: good PKI is an unsolved (and perhaps unsolvable) problem.

I agree. The CA model is broken (why should I trust a Russian to certify cia.gov?). The Web of Trust model is less broken in some ways, more in others. I think a real solution would be something like a multi-root, score-based system (e.g. if the U.S. government, Underwriters Laboratories & ICANN all state that I'm talking to www.google.com/172.217.13.238, then I honestly probably am) — but I'm worried that it'd be wa…

I would settle for restricting scope of CAs. As you say, cia.gov should only be signable by (at least) US CAs, but whatever.gov.ru should probably NOT be signable by any American CAs.

CAA records help with this, where available, but still leave some things to be desired.

Re: How not to run a CA

#92

Post by dpark » Thu, Mar 01, 2018, 5:07 PM UTC

jlgaddis wrote: post #70

dpark wrote: post #33

Earlier quoted context omitted.

You presumably got downvoted for being pedantic here, but I think your pedantry is reasonable. If someone's going say "X is fundamentally broken", they should know what X is actually called. Referring to TLS as SSL reeks of amateur hour and shallow knowledge[1], and is a mistake on par with referring to Javascript as Java. [1] This is the sort of lazy mistake I would make, because I'm not a security expert.

Yes, technically it's TLS, not SSL. TLS, however, is an "evolution" of SSL and many, many people still use this nomenclature. It doesn't "reek of amateur hour and shallow knowledge", it's just a holdover from the past. We all know and understand what others are referring to when they say "SSL". It's like when I tell the girlfriend I'm going to go on a "bike ride". She understands that I mean I'm going for a ride on m…

Your examples are not really comparable, mostly because of context. If someone at a party mentions SSL casually and you feel the need to explain that SSL is dead and they are really talking about TLS, you're just annoying. If someone presents themselves as an expert and says that SSL is "fundamentally broken", it's pretty reasonable to question their expertise. Especially when they actually aren't even talking about TLS but about CAs and PKI.

To make an absolute statement about the fundamental soundness of PKI and then use completely the wrong term? Come on. Can you imagine a real expert doing this and not at least recognize their own mistake? Don't talk about "fundamental flaws" when you don't know the difference between SSL and TLS and PKI. This is very much like someone trying to criticize the design of TCP/IP and not knowing the difference between an IP address and a MAC address.

Re: How not to run a CA

#93

Post by jnbiche » Thu, Mar 01, 2018, 5:07 PM UTC

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?

They're not verifying your identity since it's a domain validated cert. The point is just to ensure that communications between a user's browsers an www.somerandomdomain.com are secure, regardless of who is behind the domain in question.

For identify validation, you'd need to buy an EV or OV cert. But for most organizations, particularly if your domain IS your identity, a domain-validated cert is absolutely fine.

Re: How not to run a CA

#94

Post by yjftsjthsd-h » Thu, Mar 01, 2018, 5:08 PM UTC

zaarn wrote: post #68

dpark wrote: post #33

Earlier quoted context omitted.

You presumably got downvoted for being pedantic here, but I think your pedantry is reasonable. If someone's going say "X is fundamentally broken", they should know what X is actually called. Referring to TLS as SSL reeks of amateur hour and shallow knowledge[1], and is a mistake on par with referring to Javascript as Java. [1] This is the sort of lazy mistake I would make, because I'm not a security expert.

While not a security expert, I frequently refer to TLS as SSL, mostly when I talk about encrypted connections in general rather than specific protocol versions. It's not quite as bad as calling JS Java or vice versa, it's more like saying Java and then saying Java 1.2 and Java 1.8 and so forth.

Or better yet, it's like calling it Java 8 and then someone says you don't know what you're talking about because it's technically Java 1.8.

Re: How not to run a CA

#95

Post by syncsynchalt » Thu, Mar 01, 2018, 5:09 PM UTC

While the article title is accurate (you should not run your CA in this manner), Trustico is not a CA but is instead a reseller of CA services.

Re: How not to run a CA

#96

Post by originalsimba » Thu, Mar 01, 2018, 5:12 PM UTC

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

Cloudflare uses Comodo for their SSL. They could use some other cert authority, but they chose to use Comodo. This is on topic, in a general sense of CAs and trust. It bears repeating: Bad actors tend to flock together.

Re: How not to run a CA

#97

Post by recursive » Thu, Mar 01, 2018, 5:12 PM UTC

u801e wrote: post #77

aiCeivi9 wrote: post #6

Earlier quoted context omitted.

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

And they're probably not wrong. In other words, I suspect that if there were two identical competing services, the convenient one would win. If one only supported client certs, and one only supported 2FA, I have a (unsupported) feeling that the client cert company would not survive long.

Re: How not to run a CA

#98

Post by zbentley » Thu, Mar 01, 2018, 5:13 PM 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.

> root commands to the shell seems too far out there

You haven't been in software too long, have ya? /s

Glibness aside (and I meant the above as a joke, not a personal attack), this is distressingly common to the point of being near-universal in some areas of our industry.

Re: How not to run a CA

#99

Post by anonymfus » Thu, Mar 01, 2018, 5:14 PM UTC

kbsletten wrote: post #84

devit wrote: post #78

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

I'm not sure that's as good an idea as you think. Even LE has designed ACME to ideally be replicated elsewhere. The big problem with having only one CA is that if they get compromised or go down, that's the entire internet . For good reason, it's not like you can launch a CA in a day, so we will always need a few horses in this race. Culling the herd isn't a bad idea, but without some diversity any issue could be cat…

>The big problem with having only one CA is that if they get compromised or go down, that's the entire internet.

Compromising any CA affects the entire internet.

Re: How not to run a CA

#100

Post by sphix0r » Thu, Mar 01, 2018, 5:14 PM UTC

pjc50 wrote: post #66

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 ePrivacy law is coming next year which enforces all communication to be secure. Link to Directive please? (The reason I ask is that news reporting on EU law in English is extremely unreliable, and it's best to go to primary sources)

> Link to Directive please?

I-scoop[0] explains it well. Do some digging in the documents[1] and you'll get the idea where it's heading to.

"Respect for the privacy of one’s communications is an essential dimension of this right, applying both to natural and legal persons. Confidentiality of electronic communications ensures that information exchanged between parties and the external elements of such communication, including when the information has been sent, from where, to whom, is not to be revealed to anyone other than to the parties involved in a communication. The principle of confidentiality should apply to current and future means of communication, including calls, internet access, instant messaging applications, e-mail, internet phone calls and personal messaging provided through social media." [1](page 6, article 7)

> (The reason I ask is that news reporting on EU law in English is extremely unreliable, and it's best to go to primary sources)

Completely agreed, it's a complete jungle of information and the source documents are hard to digest.

[0] https://www.i-scoop.eu/gdpr/eu-eprivacy-regulation/#The_cons... [1] http://data.consilium.europa.eu/doc/document/ST-15333-2017-I...