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

[flagged]



> You can't possibly understand...

Oh, I get it. I've worked with lots of people like you.

You're lazy.

As an infosec practitioner, I'm the one that cleans up after the people who claim good current infosec practices are "too hard" or "impractical" or "not cost-effective", which all boil down to sysadmins and developers like you creating negative externalities for people like me. I have heard all of these arguments before. "Oh, we can't risk patching our servers because something might break." "Oh, the millisecond overhead of TLS connection setup is too long and might drive users away." "Oh, this public-facing service doesn't do anything important, so it's no big deal if it gets hacked."

That's irresponsible.

I'm not at all sorry that the wider IT community has raised the standards for good (not best, just good) current infsec practices. If you're going to put stuff out there, for God's sake maintain it especially if it's public-facing. If using the right HTTPS config is that difficult for you, move your stuff behind CloudFront or Cloudflare or something and let them deal with it. If you can't be bothered with some minimal standard of care, you need to exit the IT market.

And good luck finding a job in any industry, in any market, where anyone will think that doing less than the minimal standard, or never improving those minimums, is OK.


> If you can't be bothered with some minimal standard of care, you need to exit the IT market.

My goodness, you just nailed it.

The IT job market is so tight that complete incompetence is still rewarded. Incompetence and negligence that would get you fired immediately or even prosecuted in many if not most other professions.

If restaurant employees treated food safety the way most developers treat code safety, anyone who dined out would run about a 5-10% chance of a hospital visit per trip.

I was just arguing with a “senior developer” who left a wide open SQL injection in an app. “But it will only ever be behind the firewall, it’s not worth fixing.”

That’s like a chef saying “I know it’s old fish but we’ll only serve it to people with strong stomachs, I promise”.


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.


Would you be open to having a phone call, or some other more direct way of discussing this?

It may be easier to be more empathetic.




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

Search: