Hi Nils, On Wed, Sep 4, 2019 at 7:57 AM Nils Goroll <sl...@schokola.de> wrote: > > That is an interesting exercise, thank you, Dridi.
Thanks for reading. > For TLS on TCP, I would hope that passing the session key and file descriptor > would work. Have you checked already to which extend this is supported by > existing library code? I haven't, I really only had a short window to think about this and give it a try, and I burned a large amount of that spare time to play with asciinema... > Yet with the H3/QUIC madness on the horizon, I am not sure if connect()ing the > SOCK_DGRAM and passing the fd would work. The way I read the QUIC draft, > connections are primarily identified by their ID and migrations need to be > supported. I have made no coding attempt on my own, but my impression was that > the natural implementation the authors had in mind was a recvfrom(2) loop > matching packets based on their connection ID with spoof detection. > > So, Dridi, have you had a closer look yet if/how your idea could work with > QUIC? Not at all. The proposed model falls short as soon as you have any kind of key renegotiation, except that being a UDS you could in theory pass the fd back and forth whenever you need private key privileges. I really really don't like the idea of a two-way channel though. > Somehow related: How about having the process owning the private keys also > handle all receives into multiple ringbuffers, somehow similar to vsm, but > with > overrun protection? No opinion, I haven't thought about this. I'm literally back today and will be away again for the rest of the week. I will reply in greater details to Poul-Henning's response. Dridi _______________________________________________ varnish-dev mailing list varnish-dev@varnish-cache.org https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev
