Hacker News Reader

Comment by harshreality | Hacker News Reader

> why do you even want a load balancer/reverse proxy, unless your application language sucks?

Most load balancer/reverse proxy applications also handle TLS. Security-conscious web application developers don't want TLS keys in their application processes. Even the varnish authors (varnish is a load balancer/caching reverse proxy) refused to integrate TLS support because of security concerns; despite being reverse-proxy authors, they didn't trust themselves to get it right.

An application can't load-balance itself very well. Either you roll your own load balancer as a separate layer of the application, which is reinventing the wheel, or you use an existing load balancer/reverse proxy.

Easier failover with fewer (ideally zero) dropped requests.

If the app language isn't compiled, having it serve static resources is almost certainly much slower than having a reverse proxy do it.

View on HN

> Security-conscious web application developers don't want TLS keys in their application processes.

If your application is in a non-memory-safe language, sure (but why would you do that?). Otherwise I would think the risk is outweighed by the value of having your connections encrypted end-to-end. If your application process gets fully compromised then an attacker already controls it, by definition, so (given that modern TLS has perfect forward secrecy) I don't think you really gain anything by keeping the keys confidential at that point.

I write application servers for a living, mostly for Python but previously for other languages.

Nobody, nobody, writes application servers with the intent of having them exposed to the public internet. Even if they're completely memory safe, we don't do DOS protections like checking for reasonable header lengths, rewriting invalid header fields, dropping malicious requests, etc. Most application servers will still die to slowloris attacks. [1]

We don't do this because it's a performance hog and we assume you're already reverse proxying behind any responsible front-end server, which all implement these protections. We don't want to double up on that work. We implement the HTTP spec with as low overhead as possible, because we expect to have pipelined HTTP/1.1 connections from a load balancer or other reverse proxy.

Your application server, Gunicorn, Twisted, Uvicorn, whatever, does not want to be exposed to the public internet. Do not expose it to the public internet.

[1]: https://en.wikipedia.org/wiki/Slowloris_(cyber_attack)

As someone who designs load-balancer solutions for a living I cannot agree with this more.

I likewise assume that all servers are insecure, always, and we do not want them exposed without a sane load balancer layer.

Your server was probably not made to be exposed to the public internet. Do not expose it to the public internet.

> We don't do this because it's a performance hog and we assume you're already reverse proxying behind any responsible front-end server

What application servers have you written? I have never seen an application server readme say DON'T EXPOSE DIRECTLY TO THE INTERNET, WE ASSUME YOU USE REVERSE PROXY.

Most of them have a disclaimer in their deployment or tutorial docs, some with more strong language than others. Again, nothing bad happens if you don't, we don't write memory vulnerabilities into these servers. You are just far more vulnerable to DOS attacks.

* "We strongly recommend using Guincorn behind a proxy server" [1]

* "As a general rule, you probably want to: ... run behind Nginx for self-hosted deployments." [2]

* "A reverse proxy such as nginx or Apache httpd should be used in front of Waitress." [3]

For some, like uWSGI, they don't even want to talk HTTP (uWSGI supports its own protocol) and it's just assumed you're using a dedicated webserver to talk to public traffic. [4]

[1]: https://docs.gunicorn.org/en/latest/deploy.html

[2]: https://www.uvicorn.org/deployment/

[3]: https://flask.palletsprojects.com/en/stable/deploying/waitre...

[4]: https://uwsgi-docs.readthedocs.io/en/latest/tutorials/Django...

> Nobody, nobody, writes application servers with the intent of having them exposed to the public internet

For rust, go, lua (via nginx openresty) and a few others this is a viable path. I probably wouldn't do it with node (or bun or deno), python, or similar but there are languages where in certain circumstances it is reasonable and might be better.

For Go, net/http is not something you should expose to the public internet, there's no secret sauce in there. It will just die to the first person to hit it with a slowloris or other DOS attack. Same with the common C++ options like boost.beast unless you're writing the logic yourself (but why bother? Just reverse proxy).

I'm unfamiliar with the common rust frameworks for http, but find it unlikely the situation is very different.

boost.beast also only talks HTTP/1.1 AFAIK, so if you want HTTP/2 or /3 on your frontend then you must put it behind a reverse proxy anyway.

Of course, don't expose to the public Internet.

Also don't expose plain text traffic to the internal corpnet where most attack originate from.

Speculative execution cpu bugs. Or whatever the next class of problems is that can expose bits of process memory without software memory bugs.

That's already a fringe case. Do you really think everyone's writing web applications in a language like rust without any unsafe (or equivalent)?

You use a reverse proxy because whenever you "deploy to prod", you'll be using one anyway, thus by not having TLS in your app, you had not built something you don't actually need.

Reply on news.ycombinator.com