Let's Encrypt is Trusted • Hacker News Board

Re: Let's Encrypt is Trusted

#301

Post by robin_reala » Tue, Oct 20, 2015, 7:29 PM UTC

smoyer wrote: post #246

robin_reala wrote: post #174

Earlier quoted context omitted.

An encrypted communication channel specifically doesn’t say that you trust the person at the other end with your secrets. It means that you both agree that the secrets being transferred are safe from 3rd parties.

It might not say that you trust what the person at the other end does but it does indicate that a third-party has vetted the identity of the person at the other end. Do you trust Google? Probably not with everything but you do trust that the certificate that was issued to them proves that they're at the other end of your search bar.

OK, but that’s only with EV certificates. No-one issues EV certificates for free, especially not Let’s Encrypt:

Let’s Encrypt has no plans to issue EV certificates at this time.

https://community.letsencrypt.org/t/frequently-asked-questio...

Re: Let's Encrypt is Trusted

#302

Post by MrOwen » Tue, Oct 20, 2015, 7:47 PM UTC

Animats wrote: post #8

joshmoz wrote: post #2

See a Let's Encrypt cert in action: https://helloworld.letsencrypt.org/ Nice work team!

"This website does not supply ownership information."

I thought only EV certs (where you have to turn in some sort of financial and other types of documents to prove you're a real institution) were granted that info in certs. And EV certs are the only certs that turn most browser's address bars green.

Re: Let's Encrypt is Trusted

#303

Post by hellbanner » Tue, Oct 20, 2015, 9:15 PM UTC

chc wrote: post #297

hellbanner wrote: post #295

Earlier quoted context omitted.

Crypto currency with escrow, receipt of goods validated by a robot camera sending a picture to an anonymous network of validators who say "yep that's the scarf they ordered, trigger the payment"

That system still appears to include intermediaries. They're just stuck in a Rube Goldberg machine rather than dealing directly with the two parties.

Good point. I don't think there's a solution.

Re: Let's Encrypt is Trusted

#304

Post by Natanael_L » Tue, Oct 20, 2015, 9:20 PM UTC

MichaelGG wrote: post #289

Natanael_L wrote: post #152

Earlier quoted context omitted.

Because it doesn't settle with having as many single points of failure as the number of CA entries in your root CA list, they are getting multiplied over and over.

How would it be any different if these CA's made a choice to instead issue end-user certs but based off of Let's Encrypt's authorization?

Fewer master keys to target

Re: Let's Encrypt is Trusted

#305

Post by kentonv » Tue, Oct 20, 2015, 9:31 PM UTC

discreditable wrote: post #255

robryk wrote: post #123

Earlier quoted context omitted.

An interesting usecase of wildcard certs: when I do not want to publish the hostnames I am using. Sandstorm[1] uses unpredictable hostnames as one mitigation against various cross-origin attacks -- if the attacker doesn't know the domain of the app, he can't try to use XSRF against it[2]. [1] https://sandstorm.io [2] https://docs.sandstorm.io/en/latest/using/security-practices...

Any level of reliance on hostnames being secret seems like a very poor design decision.

It's a mitigation strategy for other bugs, not a first-line defense. Read the doc before passing judgment.

Re: Let's Encrypt is Trusted

#306

Post by schoen » Tue, Oct 20, 2015, 9:59 PM UTC

tokenizerrr wrote: post #299

schoen wrote: post #278

Earlier quoted context omitted.

It's up and running now -- J. C. Jones gave a reference to search the log via a web interface. https://crt.sh/?caid=7395 If you want to dive in more, you can get this data in other formats too.

So does this make the existence of my https site public, even if I'm not linked to from anywhere?

Yes.

Re: Let's Encrypt is Trusted

#307

Post by robryk » Tue, Oct 20, 2015, 10:29 PM UTC

icebraining wrote: post #184

robryk wrote: post #123

Earlier quoted context omitted.

An interesting usecase of wildcard certs: when I do not want to publish the hostnames I am using. Sandstorm[1] uses unpredictable hostnames as one mitigation against various cross-origin attacks -- if the attacker doesn't know the domain of the app, he can't try to use XSRF against it[2]. [1] https://sandstorm.io [2] https://docs.sandstorm.io/en/latest/using/security-practices...

If you are willing to only accept SNI enabled clients (the vast majority nowadays), you can achieve the same by having one cert issued per subdomain, then configuring the web server/reverse proxy to use them. There are a few existing Nginx configs for that (search for "nginx dynamic ssl cert").

Certs are published in certificate transparency logs, which would make the hostnames public.

Re: Let's Encrypt is Trusted

#308

Post by MichaelGG » Tue, Oct 20, 2015, 11:42 PM UTC

Natanael_L wrote: post #304

MichaelGG wrote: post #289

Earlier quoted context omitted.

How would it be any different if these CA's made a choice to instead issue end-user certs but based off of Let's Encrypt's authorization?

Fewer master keys to target

I'm gonna guess that getting into Let's Encrypt's HSM is as hard or harder than breaking their auth procedures.

Re: Let's Encrypt is Trusted

#309

Post by broodbucket » Tue, Oct 20, 2015, 11:46 PM UTC

josteink wrote: post #137

broodbucket wrote: post #91

Earlier quoted context omitted.

Here's a cert! Hopefully you still have it around somewhere when you try to renew in a year!

They specifically tell you that you need to back up your login-cert or you will lose access . One year passed, and I checked my backups. Yup, there it was. If you take security seriously, you should actually read what's on the page instead of clicking "next, next, next" like some driveby malware-installing Windows-installer. And then this shouldn't be an issue. I guess this is StartSSL's way of not having to deal wit…

The rest of the connected world has determined that username and password, supplemented by OTP methods or some other multifactor authentication, is enough.

Having a login cert is fine if the "user" is an organisation. It is a broken model for individuals or small businesses.

Re: Let's Encrypt is Trusted

#310

Post by vtlynch » Tue, Oct 20, 2015, 11:47 PM UTC

aianus wrote: post #228

jnbiche wrote: post #205

Earlier quoted context omitted.

You can pin any certs via HPKP, including self-signed ones. The only security feature EV certs have over regular ones right now is the use of certificate transparency, but that should be extended to non-EV certs within 1-2 years.

No, the security feature is that if you only pin, say, Verisign EV root and Digicert EV root then an attacker would have to pass EV validation at those vendors. Which is much more difficult to do than to get any cert anywhere. You could pin your own cert, but that makes it difficult to rotate keys in a heartbleed type situation.

Wow, I never thought of that before!

Though it would not protect from factoring because most EV roots are the same key length/hash.

For anyone else reading, this works because the root programs give authority to issue EV certs separately from other certs. To keep the authority separate (most, perhaps all) CAs use separate roots for EVs.