For 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.
That’s likely just the side effect of supporting mtls. Mutual TLS came around at the same time as Microsoft did implicit network auth. Seemed magical at the time and so hare brained for eons of problems. The user side tls never caught on in most circles and still has the ancient sharp edges
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.
It's a little suspicious. Why are they doing something that no other website in the world does? I was curious about zero-whatever but not enough to do whatever this is.
That's because the client certificate interface in browsers is supremely dumb. It always just lists all certificates you have, with very little context in the UI, and hopes that's good enough. I believe that's part of the reason client certificates are not poplar; having actual users deal with that is terrible, and the browsers (in practice, Chrome because of its overwhelming market share) isn't incentivized to fix it.
Servers can communicate their preference in terms of CAs they want. But the UX in browsers is unbelievably horrible for no good reason.
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.
Yes, I agree it would be very nice to have a way to integrate ACME into zeroserve. I'm not sure if zeroserve's plugin system might allow one to add a plugin to support it?
I looked into writing an http server based on iouring myself, but all the resources I could find said iouring is less safe from a cybersecurity perspective.
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?
Why? It's one of the most optimized HTTP servers ever. Anything that claims beating nginx in benchmarks should be treated with high suspicion. I think these zeroserve numbers are likely accurate but it doesn't have the features and module ecosystem of nginx so the margins aren't worth it for me.
> But hey, I didn’t code a Webserver so far - so what do I know
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.
I mean, nginx dang well should? This is just an incredibly synthetic http(s)/1.1 test for what its worth.
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.
I still think of eBPF as not being Turing-complete. There is still a complexity limit in the verifier. Even if someone did implement Game of Life by having the program set a timer to run itself. https://isovalent.com/blog/post/ebpf-yes-its-turing-complete...
zeroserve doesn't use the Linux kernel's eBPF runtime to run the eBPF it uses, so the constraints of the Linux kernel's eBPF runtime (chosen because of how the Linux kernel thinks about protecting the Linux kernel from user space) don't apply to zeroserve (or other tools that use the eBPF instruction set but don't use the Linux kernel's particular implementation)
From a technical standpoint, these are always impressive projects, but I've always wondered: has anyone ever encountered a use case where the Caddy was the bottleneck?
For most apps the backend is slower than the proxy by a wide margin, so Caddy is nowhere near the bottleneck. Where it flips is high connection churn, since TLS handshakes are the expensive part and a flood of short lived connections without session resumption burns proxy CPU well before steady state proxying does. Very high RPS of tiny responses is the other case, where allocation and header parsing start to show.
Nginx was developed to scale a lot of Russian sites, starting with Rambler. As a second point, Envoy was made by Lyft. A lot of web server OSS goes back to big (at the time) corps.
The idea of jit compilation of a web server in a small project is pretty terrifying to me. The attack surface here is enormous.
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.
Very bizarre, never seen that before.
Thumbprints:
For 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.
https://www.passkeyprf.com/
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.
> that no other website in the world does
That you know of. Anywhere with stringent security it's everywhere.
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.
As someone who is about to deal with exactly this, what kind of trouble am I in for?
https://github.com/losfair/zeroserve/blob/main/CADDY_COMPAT....
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?
AFAIK eBPF can be hardware offloaded. If you have the use case.
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.
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 usual 3400 lines lock file and AGENTS.md raise some questions about the aforementioned security, though.
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.