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

271–280 of 318 posts

Re: Let's Encrypt is Trusted

#271

Post by bradyd »

johncolanduoni wrote: post #133
lorenzhs wrote: post #120

Earlier quoted context omitted.

I don't think that's true anymore, see https://www.cloudflare.com/ssl ("Full SSL" and "Full SSL (strict)" options)

Unfortunately, this means you either have to use a self-signed cert which CloudFlare will not verify at all (meaning it can be MITMed) or use one signed by a trusted CA... which brings you back to square one.

CloudFlare has a free CA for signing certificates specifically for this situation. It was beta in February. Not sure if it is generally available yet.

https://blog.cloudflare.com/universal-ssl-encryption-all-the...

Re: Let's Encrypt is Trusted

#272

Post by tkinom »

teabee89 wrote: post #265

Are they planning on not relying on a 3rd party root CA and instead, ask all browsers and OS vendors to include LetsEncrypt CA? IOW, is this [trusting IdenTrust] a first step, or is this the original goal?

Instead of 3rd party CA, wouldn't it be more secure if the browser will send a hash of website's public key to a few trusted websites and have them verified the public key is valid?

If someone needs to create a fake CA/public key, they have to hack multiple trusted sites.

It is not current https sys design, but would it be more secure?

Re: Let's Encrypt is Trusted

#273

Post by okigan »

alwillis wrote: post #165
flashman wrote: post #43

Earlier quoted context omitted.

> You can only obtain a certificate for a domain if you can validate that you control the domain. Technically, you only have to make their systems think you control the domain. If their servers or 'establish proof of ownership' process are hacked, wouldn't this allow an attacker to do the same thing that happened in the DigiNotar hack? https://en.wikipedia.org/wiki/DigiNotar

This is why HTTP Public Key Pinning was created as a way to tell browsers to trust only a particular certificate, not just any certificate that was signed by a CA in the browser's trust store: https://news.ycombinator.com/item?id=10418144 .

Another follow up: from your link, looks like the server adds a header specifying which certificates are allowed.

Would not MITM just remove that header?

Re: Let's Encrypt is Trusted

#274

Post by pquerna »

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…

Using the OpenSSH Certificate format, many of the common features from X.509, like intermediates, cross signing, key usage attributes or restricting access based on an attribute in the certificate are not part of the spec:

https://github.com/openssh/openssh-portable/blob/master/PROT...

When I first learned about OpenSSH Certskeys, I was really excited; Spent awhile trying to make it useful, but you end up building all the CA infrastructure, and this time instead of distributing certificates to servers once a year, you want to distribute certificates to your _users_ every month or two -- so the pain is higher, there is less automation, and everyone on your team feels it....

Exploring OpenSSH certs is what led me to founding ScaleFT. There had to be a better way.

ScaleFT Access leverages these SSH Certificates, but we expire them every 5 minutes to provide other features that are hard with the limited capabilities of the format:

https://www.scaleft.com/products/access/

There are patches to make OpenSSH use X.509, but they are not widely adopted... and asking people to patch a sshd is a non-starter for many environments.

Re: Let's Encrypt is Trusted

#275

Post by jdkasten »

throwaway7767 wrote: post #168

Can someone who's tried the client confirm if it's possible to get a key/cert out of it without having it mess with my configuration files? I'd like a manual mode, as years of sysadmin work have made me extremely skeptical of tools that try to automatically modify config files.

Yes, there are now several options to manually attain the certificate.

There is a "manual" mode, "Here is the file that you need to post, press Enter when you are ready to continue"

There is a "standalone" option. If you don't have a webserver running, it will bind to port 443 and solve the challenge for you.

There is also a "Webroot" option. Enter in your server's webroot and it will automatically post a file to .well-known and delete the file after validation.

Re: Let's Encrypt is Trusted

#276

Post by geofft »

dredmorbius wrote: post #257
Spooky23 wrote: post #212

Earlier quoted context omitted.

You would like to buy a knitted scarf from a yak herder in Ecuador. How do you propose that establish trust between you and the yak guy without an intermediary?

What's wrong with intermediaries?

The commenter above implicitly rejected intermediaries. To me it is clear that my browser is a trusted intermediary, and part of my trust in them extends to letting them decide whether to trust IdenTrust. And part of my browser's trust in IdenTrust extends to letting them decide whether to trust Let's Encrypt.

In the yak-herding analogy, Let's Encrypt is a new charity in Ecuador that provides market services for scarf knitters. IdenTrust is a large regional trader in South America. My browser is the local yak-scarf store down the street. It seems totally obvious to me that, in this case, of course I'd hear about IdenScarf making deals with Let's Shave Yaks on the news. But the parent commenter is unhappy about the local yak store not being directly involved, and thinks it's some form of failure of the global yak-scarf supply chain that an individual consumer isn't part of that conversation.

Re: Let's Encrypt is Trusted

#277

Post by jrochkind1 »

jsprogrammer wrote: post #264
jrochkind1 wrote: post #254

Earlier quoted context omitted.

Well, Let's Encrypt models is based on automated confirmation of domain ownership (or to be more accurate, control rather than ownership). Automated software proves that the entity who is asking for a cert for a.example.com really does have control over a.example.com, because they were able to make a change on the host that a.example.com refers to. And based on this, issues the cert to the entity. This level of proof…

Wouldn't they just need to verify control of the domain, instead of a single host on the domain? If I control example.com, it's fair to believe I can control all hosts on the domain.

How do you verify control of a domain? Their current mechanisms verify control of a _host_ pointed to by a hostname, not of a domain. They'd need different mechanisms to verify control of a domain.

If you control the domain `example.com`, sure. if you just control the single host that `example.com` points to, that doesn't neccesarily mean you control the domain, and in fact DNS contortions are needed to even have example.com point to a host.

Re: Let's Encrypt is Trusted

#278

Post by schoen »

Natanael_L wrote: post #161
mtgx wrote: post #96

Earlier quoted context omitted.

So, Let's Encrypt doesn't support Certificate Transparency?! If there's one place where CT should be adopted, it's probably here.

I'm sure they're not opposed to it. It's a work in progress!

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.

Re: Let's Encrypt is Trusted

#279

Post by schoen »

vinay_ys wrote: post #263

In a mobile only world where your critical business runs only via mobile app do CA based SSLs even matter? Why not use your own CA with your own certificates and don't have to trust any CA?

If you're doing TLS solely with your own app, this is often described as a best practice -- avoiding exposure to the public PKI entirely.

Personally, I'm typing this post into a web site using a web browser, so I appreciate that it has a certificate that my browser can validate!

Post reply on HN