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

41–50 of 255 posts

Re: How not to run a CA

#41

Post by dpark »

cup-of-tea wrote: post #35
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.

The first line of the blog post calls it SSL. It's irrelevant to what I said because I'm talking about the public key infrastructure.

The blog author is also not a security expert.

And I understand that your real criticism was with PKI. That makes it even worse that you called it SSL. Again, I feel like you're showing your lack of expertise in this area. I'm not an expert at all in this area and yet even I can recognize that you're playing armchair security expert.

Re: How not to run a CA

#42

Post by pfg »

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, other certificate types do not judge content either. The difference is that they verify your organisational details (to a varying degree, depending on the validation level) and include them in the certificate. The CA is not going to check whether the business is fraudulent or anything like that.

Re: How not to run a CA

#43

Post by cjalmeida »

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

Worse yet, the tool seems to run JS on the client side and the page includes JS code from 5 different sources, including ad companies.

Any of them can capture the generated key.

Re: How not to run a CA

#44

Post by cup-of-tea »

dpark wrote: post #37
cup-of-tea wrote: post #34

Earlier quoted context omitted.

True. But at least web-of-trust gives you the ability to do something you are comfortable with.

If by "something you are comfortable with" you mean "reject web of trust". Trust is not transitive, which is the problem with web of trust. I trust a set of people. I do not necessarily trust the people those people trust.

If you reject the web of trust then you're saying you trust nobody (except yourself). Do you really not know anybody you trust to verify identities on your behalf? (That's a trick question because you trust the CAs).

Re: How not to run a CA

#46

Post by TheCoreh »

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

Earlier quoted context omitted.

All you've told me is you don't understand web-of-trust.

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

From my understanding, the example posted is an unlikely degenerate case where the whole "web of trust" between you and another peer consists of three separate parallel paths.

Re: How not to run a CA

#47

Post by sphix0r »

slim wrote: post #23
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.

Security depends on your threat model. HTTP is generally secure for publishing and has the added advantage of being cacheable by proxies. This blog is secure

TLS = encryption TLS = authentication TLS = tamper proof

Re: How not to run a CA

#49

Post by cratermoon »

slim wrote: post #23
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.

Security depends on your threat model. HTTP is generally secure for publishing and has the added advantage of being cacheable by proxies. This blog is secure

There is a lot more to the threat model than "will my content be stolen or compromised?"

Re: How not to run a CA

#50

Post by inetknght »

slim wrote: post #23
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.

Security depends on your threat model. HTTP is generally secure for publishing and has the added advantage of being cacheable by proxies. This blog is secure

> HTTP is generally secure

This statement is wholly incorrect. HTTP is not generally secure.

> for publishing

When I publish something I do not intend for third parties to interfere with the delivery of what I publish.

> and has the added advantage of being cacheable by proxies

If you trust your proxy, you can still have cached data at your proxy. If you don't trust your proxy, then why are you proxying through it?

Post reply on HN