Live data from Hacker News

Still Why No HTTPS?

troyhunt.com

211–220 of 345 posts

Re: Still Why No HTTPS?

#211

Because it's always pain in the ass to set it up and then renew?

How exactly is it a pain in the ass? - If you are hosting a simple static page or blog, your hosting provider probably has Let's Encrypt plugin. - If you have your own VPS, Caddy has you covered with file serving, fastcgi support for PHP, and proxying to (g)unicorn/nodejs/Go/.NET, and has HTTPS enabled by default. - If you have more advanced setup (e.g. containers), traefik supports HTTPS with just a few lines of con…

1) Not everything is running bare Apache. In fact, some services might have some rather strange web-driven GUI (or, more interestingly, curses-like) that requires you to carefully load a certificate, a CSR, and so forth in a somewhat arcane manner. Some pretty niche serving exists out there and I have had to deal with a bunch of them, to the point where I had to write extensive documentation on keeping the certificates up to date on each separate weird service. Many of these services have a "no user-servicable parts inside, your warranty will be voided ..." clauses in the service contract which deter spelunking.

2) Some services require wildcards, like proxies.

3) Some organizations have, due to someone far away making strange decisions, policies about certificate authorities, and people to audit for compliance. Therefore, a cert costs money and, for a site which is purely informational, that's a hard sell.

4) Because we're not running on a hosting provider, a VPS, containers, or cloud.

5) Because not everyone wants to deal with some combination of the above every three months due to Let's Encrypt's expiration policy.

Re: Still Why No HTTPS?

#213

Why do browsers punish non-verified certs much harder than no-cert? If I want to quickly host my page and use encryption, then I have go through all that hustle to make it work. Perhaps allow use of self-signed certificates on same level as http instead of blocking my website.

>go through all that hustle.... I manage 100+ servers, hosting a significantly larger number of domains, on a variety of linux and FreeBSD operating systems. Under both Apache & Nginx. "..all of that hustle.." to initially setup is under 2 minutes with LetsEncrypt. The renewal (via a cron job) is completely out-of-sight/out-of-mind. The execution is shockingly simple. If you think it's "all that hassle" I guarantee y…

I find LetsEncrypt to be a hassle. About 1/3 of the time the auto-renew doesn't renew because some python dependency changed, etc.

Re: Still Why No HTTPS?

#214

Earlier quoted context omitted.

>go through all that hustle.... I manage 100+ servers, hosting a significantly larger number of domains, on a variety of linux and FreeBSD operating systems. Under both Apache & Nginx. "..all of that hustle.." to initially setup is under 2 minutes with LetsEncrypt. The renewal (via a cron job) is completely out-of-sight/out-of-mind. The execution is shockingly simple. If you think it's "all that hassle" I guarantee y…

You're a professional plumber working on hundreds of households saying it's shockingly simple and should take no time at all for a first time home owner to fix their own plumbing. You've already got the knowledge, experience, and tools/parts in the van - of course you don't think it's a hassle!

And he's not even right. There is no hassle only if you take plenty of risk and rely on a random crappy acme client to do it well, its dependencies to always work, disks, OSes, servers not failing, acme protocol not changing and not deprecating anything.

Otherwise you need some infrastructure: logging, monitoring, some way to manage upgrades, backups, testing recovery, oh and those private keys are better not be leaked anywhere, so you need encryption for backups, which brings key management and so on.

Re: Still Why No HTTPS?

#215

Earlier quoted context omitted.

You're a professional plumber working on hundreds of households saying it's shockingly simple and should take no time at all for a first time home owner to fix their own plumbing. You've already got the knowledge, experience, and tools/parts in the van - of course you don't think it's a hassle!

To be reasonably fair Lets Encrypt makes it easy. I even have a $5 a year shared hosting account that gives me Lets Encrypt SSL certs through cpanel. I can't imagine this feature is unique only to this one random shared hosting provider.

Your $5 instance with cPanel management isn't really quite the same as someone manually managing 100 servers hosting these services on disparate configurations and environments. In other words, what your tooling of choice automates in a specific situation doesn't necessarily apply to any one else's usage, and scalability-wise, would be even more detached.

Re: Still Why No HTTPS?

#216
Without HSTS preload anyone on your local network can arp/dns spoof your traffic, MITM you, and automatically inject malicious javascript (cryptominers, credential-stealers, etc.), access all of the page content, and manipulate the page or response.

If you are connecting to a "Free Public WiFi" and the malicious actor is the one broadcasting the access-point; it's even easier to MITM you.

Without Cert & Key Pinning your employee laptop can be MITM by corporate to eavesdrop on all of your HTTPS traffic. The browser will show that the connection is secure, but it isn't. When you pin the cert and key - even with a compromised corporate computer - the insecure site warning will show and you'll be alerted to the fuckery.

> Doing things this way is the final nail in the coffin for Internet Explorer 6

- Fucking great! Nothing else to say here.

> handshakes take enormous amounts of CPU

- This is vastly overstated (enormous?). Also, this is called a tradeoff. Security isn't free in time, money, or performance.

> Preloads list is an absolute kludge that does not and will never scale... and works only for specific browser

- The preload list, right now, is 10.6mb and contains 90,862 entries. This seems to function and scale just fine. Seeding your browser with known values is really the best way to do this until 99.X% of web traffic is provided over HTTPS... Also Chrome, Firefox, Safari, IE/Edge, and Opera make up 98% of all browser traffic today and they have all supported this standard for years.

> The biggest problem with forcing everything HTTPS is a false sense of security.

- Defense in depth. Layering security controls is the only way to go. Also; this is some crazy mental gymnastics to take the position "wearing a seatbelt is a false sense of security because you can still crash".

> Because it's hard and a pain.

- Feeling that pain is offset onto the attackers trying to compromise your site. If you don't feel the pain; they don't either.

> Secure websites can make the web less accessible for those who rely on metered satellite internet... TLS 1.3 with 1-RTT should improve this situation.

- Even if your entire business depended upon delivering data to metered satellite internet users; the risk outweighs the cost when not encrypting your traffic. WARNING: DON'T IMPLEMENT 0-RTT OR 1-RTT WITHOUT UNDERSTANDING YOUR APPLICATION-SPECIFIC REQUIREMENTS. You can really fuck this up by not properly managing tokens between your webserver and application layer. Not recommended.

> I don't get it. With Lets Encrypt, it's like one or two lines to get everything set up.

- True, but it get's confusing really fast if you don't 100% match the certbot use-case.

> HTTPS is not an obligation.

- For 99% of people running businesses; it is.

> Recently an OpenShift cluster I admin went down because of long-lived certs not being rotated in time.

- If you have had certbot running for a long time I would suggest you check your server logs TODAY and make sure your cron job is still working correctly. Recently there was a change with the certbot acme version requirement and your reissue might be failing. Seriously, take a quick look right now.

> Because frankly, I neither trust letsencrypt nor the certificate authority system in general... but won't help against industrial (e)spionage

- Places tinfoil hat on... you're not wrong.

Re: Still Why No HTTPS?

#217

Earlier quoted context omitted.

>go through all that hustle.... I manage 100+ servers, hosting a significantly larger number of domains, on a variety of linux and FreeBSD operating systems. Under both Apache & Nginx. "..all of that hustle.." to initially setup is under 2 minutes with LetsEncrypt. The renewal (via a cron job) is completely out-of-sight/out-of-mind. The execution is shockingly simple. If you think it's "all that hassle" I guarantee y…

I find LetsEncrypt to be a hassle. About 1/3 of the time the auto-renew doesn't renew because some python dependency changed, etc.

We've recently switched to a scheme where we run a Nginx reverse-proxy with LetsEncrypt. Everything is in docker containers.

Based on this:

https://medium.com/@pentacent/nginx-and-lets-encrypt-with-do...

Now, in our setup, everything is running on a different port, so it is easy to set up additional services all coming from the same hostname with the same IP address.

Re: Still Why No HTTPS?

#219

Earlier quoted context omitted.

To be reasonably fair Lets Encrypt makes it easy. I even have a $5 a year shared hosting account that gives me Lets Encrypt SSL certs through cpanel. I can't imagine this feature is unique only to this one random shared hosting provider.

Your $5 instance with cPanel management isn't really quite the same as someone manually managing 100 servers hosting these services on disparate configurations and environments. In other words, what your tooling of choice automates in a specific situation doesn't necessarily apply to any one else's usage, and scalability-wise, would be even more detached.

Certbot works with multiple configurations and servers / Operating Systems:

https://certbot.eff.org/

I wouldn't be surprised if that's how he's managing 100 servers, or something similar.

Re: Still Why No HTTPS?

#220

Because HTTPS is not as easy as HTTP. Sure there is Let's Encrypt and if you are facing Internet you are probably good to go. If you are on an internal network, then good luck. You need to build a PKI, and then put into your devices the right certificate so that it is trusted. If it was simpler, Apache would sing out its "It works!" in HTTPS and not HTTP.

So here's how I do it for internal network devices. I have a RaspberryPi running on 192.168.100.1 on my local network. On https://www.duckdns.org/ or whatever your favorite DNS provider is, I signed up for a free account and created myRaspberryPi.duckdns.org and pointed it to 192.168.100.1. While you're logged in, grab the DuckDNS API key. Next you need to use ACME or Caddy (I use the latter) and tell it to do the Le…

Wouldn't this be subject to Let's Encrypt's rate limit of 50 certs per week for duckdns.org? Do they have an exception or are not enough people using this trick for it be a problem (yet)?
Post reply on HN