Very bizarre, never seen that before.
Thumbprints:
- 60949a09aab8677f87a0b9eda7099a03ca510fb3
- 1b146798f0dc93773247e86312f1b730c4eeebb3For my own stuff that's not meant for a wider audience, I sometimes use mTLS in front of my apps, alongside self-signed certs (my own CA) that shouldn't show up in certificate transparency logs.
This site also seems to be requesting a certificate from the user. Normally you probably don't want that for public facing resources.
It's not attempting to "read" anything, nor is it the least bit suspicious or malicious.
Your browser was asked if it would like to present a certificate to authenticate, and you were prompted to choose one if you please. You can also hit cancel as client auth can be optional and the server will either serve you the page or a 401/403.
It's like being asked to show ID to enter a pub, you can either show one or decline, and they may or may not let you enter based on that transaction.
https://github.com/losfair/zeroserve/blob/main/CADDY_COMPAT....
That being said nginx has some terrible defaults so if you're just naively benchmarking it as a proxy out of the box, you might find Caddy to be better. For example nginx caches active request bodies (in and out) to temp files in many scenarios (to block the backend/upstream as little as possible), whereas Caddy is more of a transparent proxy.
In my experience, in terms of latency, Caddy is a lot faster, every single time. I don't know what modifications I need to do to nginx to make it comparative but Caddy easily shaves half of the connection and transfer delays on my local network.
The usual 3400 lines lock file and AGENTS.md raise some questions about the aforementioned security, though.
AFAIK eBPF can be hardware offloaded. If you have the use case.
Like you totally could turn off garbage collection for caddy especially since this is only testing incredibly short single response queries that would never need GC. Shockingly you would actually get better performance than either nginx or zeroserve, but like the uselessness of this benchmark it'd mean nothing to the real world usage of these web servers.
> The twist is that you can drop eBPF programs into the tarball and they run on every request, in userspace, as sandboxed middleware - rewriting, authenticating, and rate-limiting requests, or reverse-proxying them to a backend when you want it to act as a gateway in front of your app.
https://su3.io/posts/introducing-zeroserve https://news.ycombinator.com/item?id=48425723 (272 points, 9d ago, 66 comments)
It's such opposite audiences being targeted here. eBPF is for super nerds, Caddy for "i just want a just works http server". The headline here doesn't do much for me: I don't care about Caddy compatibility and 3x doesn't mean much to me (Caddy feels like it targets friendly and easy not performance). But eBPF scripting? Ok that's cool, that's rad.
Is there a safe way to use iouring for a webserver, or is libuv the better way to go, even though it has less performance?
At the level you'd be exposing io_uring (internals) via external http requests; it's security is perfectly fine.
zeroserve only understand eBPF at runtime. It's always the source-of-truth.
People that trully need performance are not going to use a random server that has 0 support/ track record.
And for what? My back end on a single host isn't pumping at 35k qps. If each request is 500 bytes, 35k qps is nearly 20mbps sustained with zero other io (in each direction). And this is using only two threads!
I think you'd be hard pressed to find an application where this is meaningfully useful versus just scaling horizontally. On a box that can run many threads in parallel, Caddy still vastly exceeds my ability to respond to pretty much any useful traffic. It's optimizing for a metric that wasn't a bottleneck in the first place.
Does Spring Boot terrify you, then? Or Lua scripts in nginx? Or PHP? All of these use JIT compilation to run code that handles web requests.
Attack surface is a property of the JIT implementation, not of JIT itself. And eBPF is specifically designed to be very simple to implement and audit.
Would you compile your daily driver kernel with someone else's hobby C compiler that essentially nobody else uses?
It should.
Unfortunately, browsers don't invest into making a good UI for mTLS. If browsers simply put their foot down and said "we will not permit websites to ask for a certificate if the request does not contain the proper requirements" like they do in passkeys, mTLS would be just as easy to use (and even easier to manage and rotate!).
When I ran mTLS auth on my intranet, I discovered that a lot of sites will use mTLS support to do fingerprinting, which means a lot of pages will open a blocking popup (sometimes multiple times) when I just want to read an article.
Not only is it difficult for an user to make a proper selection, it's also hard to fix a wrong one. The error pages are also terrible. There's no way for the site owner to request that when the navigation to the (auth) page fails, redirect back. Nope, no way to do error handling without some really clever iframe stuff and even then it's way too opaque.
God forbid you have to deal with CORS + mTLS.
Clearly other sites do since the user who shared the anecdote has certificates already configured in their browser? It's uncommon but pretty easy to understand how this happened.
Bear in mind, this is public/private key crypto so it's not like the site is asking for your facebook password or something. The site owner has no way to reuse a certificate to imitate the user.
> that no other website in the world does
That you know of. Anywhere with stringent security it's everywhere.
If you limit the scope, its worth doing and might not take as much effort as you might think. You could possibly find some enjoyment and learn a few things doing so.
Mine was something like 70 lines, and would just listen on 8080 and fork when it got a connection before checking for the requested file and sending it or a 404. I was immediately tempted to try adding something like CGI support but didn't have the time that semester.