81–90 of 115 posts
Earlier quoted context omitted.
I was looking for a pre-hardened httpd just for serving static html files, is there one?
https://github.com/emikulic/darkhttpd darkhttpd is an option
Earlier quoted context omitted.
Caddy also does the whole Let’s Encrypt thing for you for SSL
There's a plugin for nginx that works well: $ apt-get install python3-certbot-nginx $ sudo certbot --nginx -d example.com -d www.example.com https://www.nginx.com/blog/using-free-ssltls-certificates-fr... On the other hand, caddy seems to auto renew them as well - one less cron job: > Automatic HTTPS provisions TLS certificates for all your sites and keeps them renewed. https://caddyserver.com/docs/automatic-https Ne…
Anybody still using Apache?
Earlier quoted context omitted.
Lots of companies that have been around a while and haven't replaced legacy applications still run those behind the web server they were designed to run behind. Moving to another server seems simple until you actually try to do that with a handful of 15-year-old sites with proxy rules, rewrites, custom headers, and such in one server's central config file and a bunch of per-directory access files. Technical debt is a…
That's not debt. Those are working configurations on a fully supported web server with active development. There is zero reason to change them.
Earlier quoted context omitted.
Exactly what I was thinking. You’re more likely just to have a wide open and highly/easily penetrable/vulnerable server up for grabs at that point.
Presumably you'll have less features. I wrote a web server (in the 90s, so forgivable?), and I only implemented GET and query string for the API data, and nothing fancy, no cache headers, no redirects, no multipart, no gzip, no content-encoding negotiation, etc. Some of the APIs it hosted were ultimately hacked (thru encryption of the encrypted query string via plain DES, and the key was determined), but, so far as I…
On Debian 10, "apt update && apt upgrade" says all packages are up to date. Did the fixes not land in Debian yet?
Decent privacy, questionable security vs stability if you're serious about it.
Earlier quoted context omitted.
That's not debt. Those are working configurations on a fully supported web server with active development. There is zero reason to change them.
This. There's nothing wrong with using mature technology that is still being developed. LAMP is still a perfectly fine choice if it's what you want to use.
Surely this decade they've squashed the last bugs that nginx or anything newer won't have...
Sometimes I think custom writing your own http server might not be a bad idea after all. Lots of security holes in your custom write? Yes! But the hacker needs to be dedicated to exploiting your one server specifically to find it. In exchange you are safe from of all those : vulnerabilities in the wild => script kiddies => mass exploitation => your are now hacked type of situations.
Relying on obfuscation as part of your security posture is a fantastic idea IMO. Just be prepared for what happens if a human figures out your specific puzzle box. We like exposing our private B2B web services in such a way that an attacker would be led to think the web server is totally fucked up or otherwise mis-configured if they don't understand the proprietary protocol. It's not that they could never understand…
It's the infosec equivalent of not needing to outrun the bear, just your friend.
Make your stack annoying enough to attack and attackers will move on to other targets.
Earlier quoted context omitted.
That's not debt. Those are working configurations on a fully supported web server with active development. There is zero reason to change them.
Tying that kind of business logic with http server is a technical debt. Not by 90s standards maybe.