TLS sandboxing

[Dridi Boukelmoune]

Hi Nils,

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
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