dridi at varni.sh
Mon Sep 23 07:37:01 UTC 2019
On Wed, Sep 4, 2019 at 7:57 AM Nils Goroll <slink at 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
> 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.
More information about the varnish-dev