The impact of middle boxes is overhyped on HN. Games use all kind of random ports and UDP (or TCP), it still works. Them not working on shitty company networks has no impact for real networks.
You either have a box in the way intercepting traffic for policy reasons, in which case quic won’t help as it would be blocked for breaking policy, or you don’t have a box in the way, in which case quic has no benefits (in terms of middle boxes)
>Anything on top of Ethernet, and we no longer know where this host is located (because of software defined networking). Could be next rack server, or could be something in the cloud, could be third party service.
Ping it and you can at least deduce where it's not.
You can also set your password to "password" but hopefully you don't. Guidelines and technical measures can't keep everybody safe all the time, if they are determined to be unsafe, but that is never an argument against them.
Don't you have to go out of your way to do that? You can probably choose a weak RSA key as well (ie. one that's 4096 bits but not a prime), but if you have to go out of your way to do that there's little anyone can do to stop you.
Does it terminate existing connections and re-handshake when renewing the cert then? Or does it potentially hold many keys in memory for existing sessions? IIRC a TLS session can potentially last for a long time and 0-RTT depends on it being the same key, right? Couldn't find any answers in the docs: https://caddyserver.com/docs/caddyfile/directives/tls#reuse_...
The renewal of the key does not affect existing connections/sessions because they (the sessions) don't use the key directly. The private key is only used in the beginning to agree on the symmetric key, then the symmetric key is used from there onwards.
