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

201–210 of 318 posts

Re: Let's Encrypt is Trusted

#201

Post by schoen »

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

I think there are other problems for doing this for Sandstorm. One is the delay when starting to use a new hostname (right now Let's Encrypt might take around 20 seconds to issue a new hostname, which may well increase to the originally-predicted one minute eventually), while another is that all Let's Encrypt certificates are published, so if you really want the hostname to be completely unknown to an attacker, the individual Let's Encrypt certs wouldn't work.

Anyway, Sandstorm developers told me that they wouldn't plan on using Let's Encrypt while it doesn't offer wildcards, so I think we are missing out on supporting this use case.

Re: Let's Encrypt is Trusted

#202

Post by signaler »

This will still require early stage overhead for many people switching over / 'going dark all the things'. Even though Let's Encrypt's goal is to make the process of encrypting the Transport Layer seamless, ubiquitous and non-commercial.

Take for example my setup. It sits on a private NGINX server, and is proxied through a public facing CDN. Trying to simply 'switch on' TLS involves absorbing academic style tutorials from multiple disparate sources, and requires me to have a background in DevOps and that I have at least tried some technical task like this before. In layman's terms: Unnecessary Early Stage Overhead.

Now give Let's Encrypt a few more years and it will be a lot more seamless; possibly the default. It could possibly be 'baked in' to things like Softaculous, and cPanel, which are brilliant drivers for the success of web software. Digital Ocean staff are probably already working on a droplet with LetsEncrypt baked in...

Re: Let's Encrypt is Trusted

#203

Post by corney91 »

tychuz wrote: post #166

I'm all for native desktop and mobile applications, but in this case I'd actually love a web app - enter your domain, get certificate. Downloading a tool, reading man page, works out of the box only with apache/nginx - ehhh, seems like a lot of work, considering some comments touting 'user friendliness' compared to StartSSL.

Except a tool can be automated, and a webapp is a pain to maintain for more than one domain.

Re: Let's Encrypt is Trusted

#204

Post by axx »

signaler wrote: post #202

This will still require early stage overhead for many people switching over / 'going dark all the things'. Even though Let's Encrypt's goal is to make the process of encrypting the Transport Layer seamless, ubiquitous and non-commercial. Take for example my setup. It sits on a private NGINX server, and is proxied through a public facing CDN. Trying to simply 'switch on' TLS involves absorbing academic style tutorials…

I don't see how TLS is early stage overhead for someone runnig a private nginx server behind a CDN?

Sure, someone with no devops skills at all will have a harder time, but it's for the better. Soon it will be The Way to install a webserver. Thanks to Let's Encrypt it's so easy to install TLS that nearly every future webserver tutorial will include it.

Re: Let's Encrypt is Trusted

#205

Post by jnbiche »

aianus wrote: post #122
itistoday2 wrote: post #75

Earlier quoted context omitted.

EV certs are a total waste of money. Pretty much everyone except maybe the site administrator won't notice and won't consider it a problem when a lock icon is shown instead of a green bar.

> Pretty much everyone except maybe the site administrator won't notice and won't consider it a problem when a lock icon is shown instead of a green bar. I don't know if it's worth the money per se, but you can pin a couple of trusted CA root EV certs via HPKP and know it's much more difficult for someone to "accidentally" issue a valid cert for your site. If you do that, users won't see a lock instead of a green bar…

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.

Re: Let's Encrypt is Trusted

#206

Post by peterwwillis »

alwillis wrote: post #158
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 rog…

You don't get to say there is no threat if almost every website today is vulnerable.

First, this is optional software that almost every public server in the world is currently not using. It's like saying just because executable whitelisting exists that downloaded exploit payloads on operating systems is no longer a threat. If nobody uses it, the threat still exists.

In addition to actually implementing it on your server, every single user still has to make a secure initial connection over a trusted network on every device they'll ever use to get to that site.

But not every client even supports HPKP. There's lots of older software which doesn't support it, and IE doesn't support it at all, which by itself would leave 12% of all clients vulnerable.

https://projects.dm.id.lv/Public-Key-Pins_test

https://en.wikipedia.org/wiki/Usage_share_of_web_browsers

Re: Let's Encrypt is Trusted

#208

Post by davidcollantes »

ersii wrote: post #162
mholt wrote: post #3

Congratulations LE team! Final Star Wars VII trailer and LE gets cross-signed. Best. Day. Ever.

I would just like to point out the irony in using 'LE' as a short for Let's Encrypt, as 'LE' usually gets used for shortening Law Enforcement. (Also: Congratulations and well done, Team Let's Encrypt!)

"LE" is identified more with "Limited Edition," I think. At least in the US.

Re: Let's Encrypt is Trusted

#209

Post by chmike »

nailer wrote: post #183
jonah wrote: post #167

Earlier quoted context omitted.

Do you have any recommendations on which CA is good for EV certs (that work in Chrome)?

Hi Jonah, I run https://certsimple.com . We only do EV certificates, and we do it much faster than any of the existing companies, which normally quote 7-10 days to complete the validation process. I waited around a month for GoDaddy earlier this year, which is how I ended up making CertSimple. CertSimple do EV certificates in an average of 5 hours. - We check the customers info against the required government informa…

Dis you hear about the CIA AOL mail box hacked ? Watch out for "social" intelligence. Other people could get the info you are checking and pretending to be the company.
Post reply on HN