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?
Caddy compatibility for zeroserve: 3x throughput and 70% lower latency
41–50 of 66 posts
Re: Caddy compatibility for zeroserve: 3x throughput and 70% lower latency
#42The 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 us…
Except CDNs, where it is.
Re: Caddy compatibility for zeroserve: 3x throughput and 70% lower latency
#43Earlier quoted context omitted.
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 i…
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 with…
As someone who is about to deal with exactly this, what kind of trouble am I in for?
Re: Caddy compatibility for zeroserve: 3x throughput and 70% lower latency
#44The 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 us…
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.
Re: Caddy compatibility for zeroserve: 3x throughput and 70% lower latency
#45The 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 us…
Re: Caddy compatibility for zeroserve: 3x throughput and 70% lower latency
#46Earlier quoted context omitted.
Here it attempts to read my personal certificate that sits in the browser that I use for filling my taxes and do government stuff, suspicious indeed.
That's literally how client certificates work. 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…
Re: Caddy compatibility for zeroserve: 3x throughput and 70% lower latency
#47Earlier quoted context omitted.
That's literally how client certificates work. 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…
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 no other website in the world does
That you know of. Anywhere with stringent security it's everywhere.
Re: Caddy compatibility for zeroserve: 3x throughput and 70% lower latency
#48Earlier quoted context omitted.
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 with…
> 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?
Re: Caddy compatibility for zeroserve: 3x throughput and 70% lower latency
#49Earlier quoted context omitted.
That's literally how client certificates work. 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…
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.
Re: Caddy compatibility for zeroserve: 3x throughput and 70% lower latency
#50Earlier quoted context omitted.
That's literally how client certificates work. 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…
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.
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.