This was an interesting security patch that marked the first time in my memory that updating Apache led to an immediate regression. A few hours after taking this upgrade many systems experienced such strange timeout errors. Connections were low and couldn't pinpoint the misleading behavior that looked like a slowloris attack, with no connections. Half a day later with no resolution in research a new patch [1] was ava…
Those who can't program, go to security research.
Developers fix multitude of vulnerabilities in Apache HTTP Server
51–60 of 115 posts
Re: Developers fix multitude of vulnerabilities in Apache HTTP Server
#52Re: Developers fix multitude of vulnerabilities in Apache HTTP Server
#53Anybody still using Apache?
Note: several folks have pointed out that I was totally wrong about Caddy. Sorry! I should look at it again before I spout off any more opinions about it. Unlike nginx or Caddy^H^H^H^H^H, the Apache design and community encouraged writing modules (roughly akin to "middleware" in the modern server-side web stack) that hooked directly into the web server, rather than just using it as a static host + L7 proxy. Furthermo…
Re: Developers fix multitude of vulnerabilities in Apache HTTP Server
#54Anybody still using Apache?
Note: several folks have pointed out that I was totally wrong about Caddy. Sorry! I should look at it again before I spout off any more opinions about it. Unlike nginx or Caddy^H^H^H^H^H, the Apache design and community encouraged writing modules (roughly akin to "middleware" in the modern server-side web stack) that hooked directly into the web server, rather than just using it as a static host + L7 proxy. Furthermo…
Huh? I must be misunderstanding, because everything in Caddy is a module, even its HTTP server, and all its middleware handlers are equally modules that you can plug in as much as any other module you could write and publish.
Some Caddy modules also expose dynamic scripting / language interpretation capabilities as well. Caddy is used for well more than just static files and HTTP reverse proxying.
Re: Developers fix multitude of vulnerabilities in Apache HTTP Server
#55Earlier quoted context omitted.
What's wrong with Apache? (honest question)
About a decade ago nginx stormed onto the scene with event based multi-processing, and even though mpm-event became a thing not too long after that, Apache retained mpm-prefork and then mpm-worker as defaults for a very long time, and lost a lot of market share. A lot of people still retain the notion that nginx is "just faster" or "just better" which is not necessarily the case. Apache with mpm-event is just fine fo…
Re: Developers fix multitude of vulnerabilities in Apache HTTP Server
#56Earlier quoted context omitted.
About a decade ago nginx stormed onto the scene with event based multi-processing, and even though mpm-event became a thing not too long after that, Apache retained mpm-prefork and then mpm-worker as defaults for a very long time, and lost a lot of market share. A lot of people still retain the notion that nginx is "just faster" or "just better" which is not necessarily the case. Apache with mpm-event is just fine fo…
Yeah; and unlike nginx and Apache, Caddy has a higher degree of memory safety, so it's impervious to a whole class of vulnerabilities.
Re: Developers fix multitude of vulnerabilities in Apache HTTP Server
#57Earlier quoted context omitted.
What's wrong with Apache? (honest question)
About a decade ago nginx stormed onto the scene with event based multi-processing, and even though mpm-event became a thing not too long after that, Apache retained mpm-prefork and then mpm-worker as defaults for a very long time, and lost a lot of market share. A lot of people still retain the notion that nginx is "just faster" or "just better" which is not necessarily the case. Apache with mpm-event is just fine fo…
Smaller web servers have been event based since they first showed up, it is the natural way to build them. There was no epoll() available, but a select() loop is pretty much the same thing. The super useful thttpd had been around a long time at that time.
What caused people to start using non-forking web servers for regular public web applications was probably that PHP finally got a stable FastCGI mode going about ten years ago. Because, honestly, most of the web is PHP and it was even more dominant back them.
And when people posted their web server configs in forums at that time, nginx configs were much more readable and concise. The easier config format is what caused its popularity to soar, not that it used a particular syscall half a decade earlier.
Re: Developers fix multitude of vulnerabilities in Apache HTTP Server
#58Earlier quoted context omitted.
Might be nice to disclose your involvement when commenting on caddy-related threads.
> I'm the author of the Caddy web server.
Re: Developers fix multitude of vulnerabilities in Apache HTTP Server
#59Earlier quoted context omitted.
> In exchange you are safe from of all those : vulnerabilities in the wild => script kiddies => mass exploitation => your are hacked type of situations. Not sure about that... You might commit some of the same mistakes that they did
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.
Re: Developers fix multitude of vulnerabilities in Apache HTTP Server
#60Anybody still using Apache?
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…