Let's Encrypt is Trusted • Hacker News Board

Re: Let's Encrypt is Trusted

#231

Post by axx » Tue, Oct 20, 2015, 1:30 PM UTC

callahad wrote: post #219

axx wrote: post #200

The big question: Does this mean we can now all use Let's Encrypt to generate new certificates without people running into problems?

It means certs signed by Let's Encrypt will work just fine for people without any special setup. See https://helloworld.letsencrypt.org/ for an example. This does not , however, mean that we can all start using Let's Encrypt. They're doing a slow roll-out before making certs generally available to the public. You can apply for the Beta at https://goo.gl/forms/kf0IGCeAk5 , or wait until general availability later this…

Thanks!

Re: Let's Encrypt is Trusted

#232

Post by gopowerranger » Tue, Oct 20, 2015, 1:35 PM UTC

vonklaus wrote: post #88

lorddoig wrote: post #81

Being told that you now trust someone with your secrets via a news website is a pleasingly succinct display of everything that's wrong with the CA model.

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…

Nothing you said is a reason for not using Let's Encrypt.

Re: Let's Encrypt is Trusted

#233

Post by gopowerranger » Tue, Oct 20, 2015, 1:37 PM UTC

grey-area wrote: post #145

cpach wrote: post #93

Earlier quoted context omitted.

I'm not sure what you're getting at. Care to elaborate?

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

So you trust yourself more than everyone behind Let's Encrypt, et al? Of course, you don't have to use Let's Encrypt so you do have a choice.

Re: Let's Encrypt is Trusted

#234

Post by wtbob » Tue, Oct 20, 2015, 1:47 PM UTC

rplnt wrote: post #216

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…

Is it (technically) possible to limit CAs validity to certain subset of.. something? I.e. certain CAs could only be used to verify limited number of.. domains? something?

That's how SPKI (RFCs 2692 & 2693) worked: one only trusted an authority for certain things. This would work very well for DNS names and IP addresses alike, since both are allocated hierarchically; with SPKI one could guarantee that one is talking to one of the parties who is allowed to use a name or an address.

Sadly, SPKI more-or-less died on the vine: the atrocious XPKI 'system' won by default. One of my rainy-day projects is to try to revive it: if the last 15 years have taught us anything, it's that centralised global trust is insane.

Re: Let's Encrypt is Trusted

#235

Post by ascorbic » Tue, Oct 20, 2015, 1:52 PM UTC

UserRights wrote: post #227

The headline is wrong and not very clever for such a project. The project was able to get a CA to sign their keys, this is what happened. Using the word "trust" is simply wrong and might be interpreted as a too simple kind of propaganda after we learned a lot about the untrustable nature of a hierarchical certification infrastructure. Another, even bigger trust-breaking elephant in the room is the fact that this proj…

It means it's trusted by all major browsers, which is what matters. You may not like the terminology, but that's what it's called.

Re: Let's Encrypt is Trusted

#236

Post by e12e » Tue, Oct 20, 2015, 2:01 PM UTC

darkr wrote: post #194

MertsA wrote: post #157

Earlier quoted context omitted.

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?

Yeah - [Open]SSH supports signing for host and user keys, and you can operate your own CA, and the certificates you issue can encode a signed set of permissions/access controls with them (E.g permit-agent-forwarding, permit-X11-forwarding, certificate life times) this functionality is IMHO vastly underutilised. OpenSSH certificates are not X509 certificates though, and out of the box SSH servers will not trust any pu…

There's a pretty old (but apparently updated) patch-set for using x509 certificates with openssh. I realize commenter above made a typo, but it might be of interest in this thread:

http://www.roumenpetrov.info/openssh/

Re: Let's Encrypt is Trusted

#237

Post by balabaster » Tue, Oct 20, 2015, 2:04 PM UTC

Er... you're trusted by a CA that's owned by a company that resides in Austin Texas...

Texas hasn't exactly got a glowing reputation in the software industry due to its mountain of intellectual property lawsuits filed by patent trolls... er, sorry, I mean non-practicing entities

Excuse me while I reserve some skepticism about just how trusted your security certificates should be.

Re: Let's Encrypt is Trusted

#238

Post by vtlynch » Tue, Oct 20, 2015, 2:06 PM UTC

balabaster wrote: post #237

Er... you're trusted by a CA that's owned by a company that resides in Austin Texas... Texas hasn't exactly got a glowing reputation in the software industry due to its mountain of intellectual property lawsuits filed by patent trolls... er, sorry, I mean non-practicing entities Excuse me while I reserve some skepticism about just how trusted your security certificates should be.

Absolutely pointless and irrelevant. This is the same logic that Donald Trump uses to dismiss all Mexican people as rapists.

Re: Let's Encrypt is Trusted

#239

Post by Karunamon » Tue, Oct 20, 2015, 2:08 PM UTC

balabaster wrote: post #237

Er... you're trusted by a CA that's owned by a company that resides in Austin Texas... Texas hasn't exactly got a glowing reputation in the software industry due to its mountain of intellectual property lawsuits filed by patent trolls... er, sorry, I mean non-practicing entities Excuse me while I reserve some skepticism about just how trusted your security certificates should be.

I'm not sure what you think CAs have to do with patent trolling. If there was a patent on the PKI, many large companies would have been sued already.

Re: Let's Encrypt is Trusted

#240

Post by geofft » Tue, Oct 20, 2015, 2:08 PM UTC

rplnt wrote: post #216

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…

Is it (technically) possible to limit CAs validity to certain subset of.. something? I.e. certain CAs could only be used to verify limited number of.. domains? something?

If you're talking about limiting to certain TLDs, like American CAs not being able to issue .ca or .in or .paris, there is a spec for that, called name constraints. It is intermittently supported, and there was a thread on mozilla.dev.security.policy, primarily focusing on government CAs, which argued that doing such a thing fractures the open/egalitarian nature of the internet, by making zones where security is less important:

https://groups.google.com/d/topic/mozilla.dev.security.polic...

I can imagine other ways you would restrict certificates (for instance, I'd kinda like to see a spec for a "half-CA", where you need two half-CAs under distinct organizational control to sign you), but I don't think anyone has specified the problem for those precisely, let alone proposed a solution.