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

Let's Encrypt is Trusted

letsencrypt.org

Post reply on HN
Print view View original

151–160 of 318 posts

Re: Let's Encrypt is Trusted

#151

Post by Natanael_L »

sgc wrote: post #100
vonklaus wrote: post #88

Earlier quoted context omitted.

We’re pleased to announce that we’ve received cross-signatures from IdenTrust This is what is wrong with the CA, model, not their method of announcing it to a community anxiously awaiting the arrival of their product. What is absurd is that identrust has a shitty non-responsive 90's looking website and wants $299 for an SSL certificate, which is something that should be free. I will say though, they really did sell m…

I don't think he was saying they acted poorly by announcing on HN, but that he would prefer to grant someone trust rather than have it forced on him before he even knew about it. Not an easy task for a functional web, but it would obviously be better if possible.

There's many ways, all obnoxiously complex unless you go back to a CA-ish voluntary trust model.

Keys as addresses (I2P, Tor hidden services, CJDNS) fixes a large part of the security problem, then on top of that you can add your choice of address translation. WoT style individualized trust webs? Trusted lists of name assignments DNS style? First-come first-serve á la Namecoin?

Re: Let's Encrypt is Trusted

#152

Post by Natanael_L »

MichaelGG wrote: post #144
harshreality wrote: post #104

Earlier quoted context omitted.

New wannabe CA Entity B can approach an established CA entity A, convince A to sign B's root or intermediate cert, and then B can forge browser-trusted certs for every SSL website on the net that's not pinned. In this case, B is LetsEncrypt and is (hopefully) pretty solid, but that isn't always the case. Earlier this year, it became known that CNNIC had issued a CA cert to MCS Holdings (of Egypt), which then did bad…

How is this any worse than trusting the original CA? There's almost assuredly some high standard they use to cross sign, and they'd get revoked if they do that incorrectly. You're failing to note that MCS was revoked as was CNNIC. So, boom, 2 bad/laughably incompetent players are out. Trusting a CA means trusting them to write certs, even via an intermediary. If you don't actually trust them, remove those CAs. The CA…

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.

Re: Let's Encrypt is Trusted

#153

Post by vetrom »

toomuchtodo wrote: post #41
mastax wrote: post #35

Earlier quoted context omitted.

An argument can be made that Let's Encrypt doesn't need wildcard certificates since new certs can be generated automatically every time a subdomain is added.

True! But wildcards make cert management so much easier . If I have a handful of subdomains, that's fine. If I have thousands, I want a wildcard cert.

Arguably though wildcard certs are a bad hack on security, as it binds multiple distinct endpoints to a given keypair.

Given the occasional implementation weakness, and key recoveries, I would much rather bind only one key to a name.

Re: Let's Encrypt is Trusted

#154

Post by cpach »

1K2bCjh1aH wrote: post #134

./letsencrypt-auto Updating letsencrypt and virtual environment dependencies.....Command "python setup.py egg_info" failed with error code 1 in /tmp/pip-build-KgdEvk/ConfigArgParse

HN is not a support forum. Please look here instead: https://community.letsencrypt.org/t/welcome-to-lets-encrypt-...

Re: Let's Encrypt is Trusted

#155

Post by Natanael_L »

cpach wrote: post #147
grey-area wrote: post #145

Earlier quoted context omitted.

Probably just that we're being told who to trust, instead of deciding who to trust.

I guess we could have some kind of web of trust system instead. But are there any web of trust systems that actually work in practice?

Allowing multisignature models would at least drop the single point of failures, by being able to require verification from multiple CAs. In combination with certificate transparency and DNSSEC+DANE it would add much stronger security.

Re: Let's Encrypt is Trusted

#156

Post by Natanael_L »

j4cob wrote: post #52
toast0 wrote: post #45

It seems odd to me that the intermediates were cross signed instead of the having the root be cross signed. With a cross signed root, clients with only the IdenTrust root will validate the cert, and clients with only the LetsEncrypt root can validate the cert. With a cross signed intermediate, the server has to guess which root the client has and serve the correct path, there's a TLS extension to indicate roots the c…

This was a performance decision. Cross-signing the root instead of the intermediate would mean that web servers would have to include both the root and the intermediate in the chain they serve, rather than just the intermediate. That would add a full packet to each handshake.

Why are there multiple intermediate certs? I don't know the details of the standard procedure.

Re: Let's Encrypt is Trusted

#157

Post by MertsA »

landr0id wrote: post #17
icelancer wrote: post #6

Huge win for them - will help push SSL/TLS on everything. Can't overstate how important this is for the web. Now to get the word out to everyone! edit: initially said SSH. I blame the plane wifi

I think you meant SSL/TLS

can you sign a cert for SSH? I know that you can add the SSH server public key fingerprint as a DNS record and sign an openSSH certificate with your own private CA but are there any public CAs who will sign SSH certs and would the ssh client even trust anything other than a manually added CA?

Re: Let's Encrypt is Trusted

#158

Post by alwillis »

peterwwillis wrote: post #127

Remember that you only need one of the hundreds of CAs (650 at my last count) to generate you a cert to essentially compromise a site's connection security. Free certs mean more sites will use TLS, which means there will be more targets, which means more incentive to start attacking the weakest CAs and/or their verification practices. But this is kind of a good thing, because after enough attacks on the old model, pe…

Thanks to HTTP Public Key Pinning (HPKP), this is no longer a threat:

HTTP Public Key Pinning, or HPKP, is a security policy delivered via a HTTP response header much like HSTS and CSP. It allows a host to provide information to a user agent about which cryptographic identities it should accept from the host in the future. This can protect a host website from a security compromise at a Certificate Authority where rogue certificates may be issued for your hostname.

You can read all about it: https://scotthelme.co.uk/hpkp-http-public-key-pinning/

And here are web-based tools for examining and generating HPKP hashes: https://report-uri.io/home/tools

Re: Let's Encrypt is Trusted

#159

Post by StavrosK »

josteink wrote: post #132

From a comment on a similar reddit-thread[1]: > So thus beings the transition. EV certs are going to be the only ones that get the "green" chrome in browsers anymore. Sites using standard SSL are going to get the normal no-lock/white treatment. And sites without SSL will get the caution symbol/yellow treatment. I don't like it, but I suspect this is where we're heading. [1] https://www.reddit.com/r/linux/comments/3pg…

And the advice will become "make sure the browser bar is not yellow", and everything will be safe by default, and everyone will be happy.

Re: Let's Encrypt is Trusted

#160

Post by Natanael_L »

dingaling wrote: post #125
chipperyman573 wrote: post #90

Earlier quoted context omitted.

It would be relatively easy to write a simple bash script to automate it. Granted, it might take a bit of time to generate a few thousand certs, but it wouldn't take more than a day if you only have a thousand or so.

It's not just creating the certs that is the challenge but also managing them; back-up, revocation, re-testing after expiry and across different development environments etc And from the client perspective is makes pinning much easier. I'm not a fan of one-wildcard-to-rule-them either but keeping active certs to a handful through the judicious use of wildcards is a real boon.

If you use the Cloudflare style delegation of SSL authentication signing to a trusted auth server, it can be simplified. The individual servers only holds the public cert and a private internal secret, one server holds your certificate private keys.

That server would be used to keep track of your domains and certificate status and which servers are authorized to work with which domains, etc... Also easier to backup.

Post reply on HN