Early Impacts of Let's Encrypt • Hacker News Board

Re: Early Impacts of Let's Encrypt

#31

Post by pfg » Sat, Feb 20, 2016, 8:55 PM UTC

sansidentity wrote: post #28

Hypothetical. If I run a website for a small town public library that only serves information, ie no user accounts and no logins on our domain, is there a valid reason for me to go through the process of https and certificates? Plus I'm on a shared host. I briefly looked at the install doc on letsencypt and while it's clear it's easier than it used to be I am uncertain my shell access will give me the necessary permi…

Encrypting sensitive user data is only one advantage of TLS. Without TLS, every single network hop between you and your client could modify your site. This could mean altering the content, adding ads or even malware. Some large ISPs have done so in the past. Furthermore, browsers vendors have decided that HTTPS is the way to go forward and will gradually mark HTTP-only sites as unsafe. New browser APIs might only be available in secure contexts.

You might be interested in this list of web hosts that support Let's Encrypt[1]. Generally speaking, your hoster should be able to provide a one-click interface for obtaining and installing a certificate for you, and odds are most hosts will eventually do so free of charge once HTTPS becomes mandatory.

[1]: https://github.com/letsencrypt/letsencrypt/wiki/Web-Hosting-...

Re: Early Impacts of Let's Encrypt

#32

Post by htor » Sat, Feb 20, 2016, 8:56 PM UTC

sansidentity wrote: post #28

Hypothetical. If I run a website for a small town public library that only serves information, ie no user accounts and no logins on our domain, is there a valid reason for me to go through the process of https and certificates? Plus I'm on a shared host. I briefly looked at the install doc on letsencypt and while it's clear it's easier than it used to be I am uncertain my shell access will give me the necessary permi…

I think Google penalizes non-https sites, so that's one reason.

Re: Early Impacts of Let's Encrypt

#33

Post by Titanous » Sat, Feb 20, 2016, 8:57 PM UTC

sansidentity wrote: post #28

Hypothetical. If I run a website for a small town public library that only serves information, ie no user accounts and no logins on our domain, is there a valid reason for me to go through the process of https and certificates? Plus I'm on a shared host. I briefly looked at the install doc on letsencypt and while it's clear it's easier than it used to be I am uncertain my shell access will give me the necessary permi…

Yes, there are many reasons to deploy TLS everywhere, and everyone should be working towards it for these reasons:

- Increased resistance to surveillance. Instead of seeing the pages/information that a client downloads from your server, state actors, ISPs, local attackers, and anyone else listening only learn that the client downloaded some bytes from your server.

- Mitigation of man-in-the-middle and man-on-the-side attacks against your website. These can be as simple as someone attacking a local open Wi-Fi access point to sophisticated attacks like the Chinese DDoS against GitHub and the NSA's QUANTUM INSERT. Potential attacks range from replacing/rewriting information to attacking client machines with browser exploits.

- Better SEO rankings, Google weighs HTTPS sites higher than their equivalent insecure plaintext.

If you need a shared host that supports HTTPS, take a look at DreamHost, they have a free one-click Let's Encrypt integration.

Re: Early Impacts of Let's Encrypt

#34

Post by shawn-furyan » Sat, Feb 20, 2016, 8:59 PM UTC

sansidentity wrote: post #28

Hypothetical. If I run a website for a small town public library that only serves information, ie no user accounts and no logins on our domain, is there a valid reason for me to go through the process of https and certificates? Plus I'm on a shared host. I briefly looked at the install doc on letsencypt and while it's clear it's easier than it used to be I am uncertain my shell access will give me the necessary permi…

Historically library usage has been surveilled, so I would say that making passive surveillance of your users more difficult is a 'valid reason' for going through the trouble.

You don't need logins/user accounts for your users to be identified. IP is sufficient in many cases, and browser fingerprint pretty much covers the other cases.

Also, if the website ever has need to become more complex, it will be easier and less error prone not to have to throw 'figure out how to implement TLS' on the pile of tasks.

Also, if permissions are the primary concern, might I recommend moving to a host that does SSL/TLS for you? Webhosts have come a long way in the last few years. Moving to a nicer one may actually save you effort in the long run.

Re: Early Impacts of Let's Encrypt

#35

Post by troels » Sat, Feb 20, 2016, 9:03 PM UTC

sansidentity wrote: post #28

Hypothetical. If I run a website for a small town public library that only serves information, ie no user accounts and no logins on our domain, is there a valid reason for me to go through the process of https and certificates? Plus I'm on a shared host. I briefly looked at the install doc on letsencypt and while it's clear it's easier than it used to be I am uncertain my shell access will give me the necessary permi…

If the library site serves over plain http, it is fairly easy to snoop on the visitors activity. So one could find out which kind of books certain visitors were looking for. That could easily reveal secrets about said visitors.

If we are not just being hypothetical, a simple solution for you could be to register with cloudflare and run your site behind that. They will give you a free ssl certificate. This isn't as secure as running your own, since the connection between cloudflare and your server is in plain http, but it's a lot better. As an added bonus, you get a free caching layer in front of your site, which might be a good thing if you're on a small shared host.

Re: Early Impacts of Let's Encrypt

#36

Post by ShakataGaNai » Sat, Feb 20, 2016, 9:07 PM UTC

So one thing that would be interesting to take a look at from this dataset is wildcard vs non-wildcard. My employer has two wildcard certs for public sites (purchased from your standard vendors) and that's all that is required (for a lot of places). However one of my personal domains I play with a lot of technologies, all on their own subdomains. So for that single domain I probably have 10 LE certs (and yes, none of these were secured before).

So maybe it's not wildcard vs non-wildcard, it's limit the datasets to root domain names?

Re: Early Impacts of Let's Encrypt

#37

Post by tga_d » Sat, Feb 20, 2016, 9:09 PM UTC

sansidentity wrote: post #28

Hypothetical. If I run a website for a small town public library that only serves information, ie no user accounts and no logins on our domain, is there a valid reason for me to go through the process of https and certificates? Plus I'm on a shared host. I briefly looked at the install doc on letsencypt and while it's clear it's easier than it used to be I am uncertain my shell access will give me the necessary permi…

>If I run a website for a small town public library that only serves information, ie no user accounts and no logins on our domain, is there a valid reason for me to go through the process of https and certificates?

Absolutely. The privacy of library searches has long been viewed as one of the archetypal examples of why privacy matters. A user's ISP shouldn't be able to learn what sort of books, movies, and music a library patron is interested in. And that's before we get into matters like injection of malicious content by local miscreants at your favorite cafe, or ads by mobile networks. Fundamentally, it's an issue of your users being the ones deciding what they do and do not care about being secure, and security being the default (could you imagine the emotional hurdle someone who has a real need for their privacy when using the library website would have to go through to explicitly ask for it?). The Library Freedom Project, who has been in the news a lot as of late, was in part started to push the use of SSL in all libraries, even if you "don't need it."

https://libraryfreedomproject.org/ourwork/digitalprivacypled...

https://github.com/EbookFoundation/library-privacy-pledge/wi...

Re: Early Impacts of Let's Encrypt

#38

Post by pfg » Sat, Feb 20, 2016, 9:10 PM UTC

Slightly OT: It would be great if CT logs were available as part of Amazon's or Google's public data sets. Being able to access that data via BigQuery (or similar) would make generating something like this way easier. It would also be immensely useful when implementing CT log monitors.

Re: Early Impacts of Let's Encrypt

#39

Post by iancarroll » Sat, Feb 20, 2016, 9:11 PM UTC

IgorPartola wrote: post #19

jonlucc wrote: post #16

Earlier quoted context omitted.

There were free options. I think the biggest benefits to Let's Encrypt are the EFF's clout and the simplicity.

I used to use Wossl and StartSSL before for lots of little personal projects. I recently switched everything over to LE. I am looking forward to switching other projects to it too, such as ones for clients where we had to pay for wildcard certs in the past. Not having to mark the calendar to renew certs every year is going to be really nice. Incidentally, does anyone have a good way to integrate LE with EC2's load ba…

Amazon operates a free CA (Amazon Certificate Manager) for use with ELB and CloudFront.

Re: Early Impacts of Let's Encrypt

#40

Post by iancarroll » Sat, Feb 20, 2016, 9:15 PM UTC

AcidBurn wrote: post #20

MCRed wrote: post #9

Does anyone know where one can get a free wildcard certificate? Need it for development and foo/bar/baz/biff.example.com change names regularly (they include the hash of the code commit) so I would like to get a *.dev.example.com wildcard cert. (one that won't give warnings that scare the business types who are testing the code, and won't understand what self-signed means.)

Other than Amazon Certificate Manager as moatra mentions (which I don't think let's you export the certificate), I don't think there is currently an option for free wildcard certificates. As an alternative you could incorporate provisioning of a Let's Encrypt certificate for the new subdomain into your deployment process since the process is designed to be automated.

Current rate limiting wouldn't really make it possible, unfortunately.