> Remco wrote: > > The idea is to run the TLS protocol in different processes (tls_client, > > kex helper) by impersonal users. > > > > All TLS/crypto code lives in those processes, the user's application > > doesn't know about TLS/crypto and does not need to be linked against it. > > This doesn't sound very different from stunnel. Or in openbsd, relayd. > > On the client side, it's not always so clear, but there is nc. > > Personally, I think TLS is too complicated, and so it's a good idea to > separate that from other operations. It is possible to hide this behind the > tls API, but many programs aren't going to want that. > > But some diffs to seperate TLS and HTTP into seperate processes in ftp could > be interesting.
I also worry about one process that does decapsulation, on behalf of others. Now all the risk is in one place, and an attack against it which can remain persistant is very worrying - it can see all future traffic. Instead, we've designed daemons which use tls in much narrower domain-specific ways. For a good example, see how ntpd has a completely privilege seperated tls speaker for the "constraint" feature. No memory sharing. Furthermore pledge allows that data flow (and interpretation, which is safe) to sit inside a single address space, with very limited system call operations. That process cannot even do fd passing once it gets going.
