Hacker News new | past | comments | ask | show | jobs | submit login

I wrote that in anger, and almost right away removed it when I calmed down. Please see my current comment.



It's rather bad form to do so without noting what you edited in the comment itself, especially as your parent poster replied to it.


But why did it make you so angry? My guess is because my viewpoint is completely unfathomable to you. You can't even believe that someone would advocate for it. In situations like that, I always try and put myself in the shoes of that person. Sometimes they are wrong, and sometimes they have a point. But it's always a useful exercise.

To your parent comment -

No, I don't think it's a cabal of "grumpy old men" - I think it's a cabal of morally righteous security-minded people who have never worked for small companies or realize that most dev teams don't have the time to deal with all this forced entropy.

You care about security, I care about making valuable software. Security can be a roadblock to releasing valuable software on time and within budget. If my software doesn't transmit sensitive data, I surely do not want to pay the SSL tax if I'm on a deadline and it's cutting in to my margins.


What the gently caress does encrypting an HTTP connection have to do with morals or age? You are way outside the realm of making sense, man, and offer commentary that is openly harmful to securing the Internet. Please step back and revisit your woefully misinformed opinion on this.

Most people who advocate for security, including myself, have worked on small teams and understand the resources involved. Putting a TLS certificate on your shit with LE takes minutes. Doing it through another CA is minutes, in a lot of cases. You spent more time downloading, installing, and configuring Apache, then configuring whatever backend you want to run, and writing your product or blog post or whatever it is you’re complaining about securing.

Honestly, in the time you’ve been commenting here, you could have gotten TLS working on several sites. Managing TLS for an operations person is like knowing git for a software developer. It’s a basic skill and is not difficult. If it’s truly that difficult for your team, (a) God help you when someone hacks you, they probably already have and (b) there are services available that will front you with a TLS certificate in even less time than it takes to install one. Cloudflare and done.

> Security can be a roadblock to releasing valuable software on time and within budget.

Great, you've pinpointed it. Step two is washing it off. Ignoring security directly impacts value, and I'm mystified that you don't see this.

But I guess I'm a zealot ¯\_(ツ)_/¯


> Putting a TLS certificate on your shit with LE takes minutes. Doing it through another CA is minutes

if you have one server, yes. else it's the other way around, because if you have multiple servers you need to do a lot of fancy stuff. And LE also does not work in your internal network if you do not have some stuff publicy accessible. And it also does not work against different ports.

Oh and it's extremly hard to have a proxy tls <-> tls server that talks to tls backends, useful behind NAT if you only have one IP, but multiple services behind multiple domains.

IPv6 fixes a lot of these issues.


You can use Let's Encrypt certificates for non-publicly reachable hosts by using the dns-01 challenge type. That, of course, means that you need some way of properly automating your DNS infrastructure to add the necessary TXT records which, admittely, is sadly not the case in many organizations. It's a solvable problem, though.

I don't understand your last point. Where do you see the problem with letting a reverse proxy talk to a TLS backend? You get the requested server name from the SNI extension and can use that to multiplex multiple names onto a single IP address. The big bunch of NATty failure cases apply to plaintext HTTP just as well, no?


Well the last point means that I need to rollout the cert to multiple servers (as the poster below writes)


In the most common setups, the reverse proxy usually terminates the TLS session and uses a different connection to make requests to the backend servers (e.g. nginx proxy_pass directive).

This means the backend server certificates are only ever exposed to your reverse proxy. There's no need to use publicly-trusted certificates for that. Just generate your own ones and make them known to the proxy (either by private CA cert or by explicitly trusting the public keys).


This new version issues wildcard certificates. Get one certificate. Use Puppet, Chef, Ansible, Salt, Bolt, multissh, or GNU parallel to put it on multiple servers for that domain.

If you need lots of different domains, use one of the auto certificate tools.

If you can't use one of those yourself, consider hosting on a platform that can automatically do this for you for all your sites, like cPanel (disclaimer: I work for cPanel, Inc).

If your stuff is never publicly accessible because you're in a fully private network, just run your own CA and add it to the trust root of your clients.

If you need an SNI proxy, search for 'sniproxy' which does exist.

If you're so small that you can't afford an infrastructure person, a consultant, or a few hours to set such things up yourself, then maybe you should shorten the HN thread bemoaning doing it and use the time to learn how.


> offer commentary that is openly harmful to securing the Internet

Funny you mention this.

With this new functionality, I can register valid certs for any domain in the world if their DNS is insecure, or if I can spoof it.

Have we gotten any headway yet on that whole "anyone can hijack BGP from a mom and pop ISP" thing ?

How many CAs are still trusted by browsers, again? How many of those run in countries run by dictators?

HTTPS doesn't secure the Internet. It's security theater for e-commerce.


> I think it's a cabal of morally righteous security-minded people who have never worked for small companies or realize that most dev teams don't have the time to deal with all this forced entropy.

This is just one anecdote, but I worked at a company small enough that I was the only developer/ops person. Time spent managing HTTPS infrastructure couldn't have been more than a handful of hours a year.

What is so painful to you about running your website(s) on HTTPS?


Honestly, from not ever using nginx to having an auto-renewing "A+" HTTPS site took no longer than 3 hours.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: