Op 01/10/17 om 08:17 schreef Theo de Raadt:
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.
Just in case there is a misunderstanding, the tls_client and kex helper are two additional processes per connection. They're not long lived. There actually is a long lived process, tls_socketd, that executes these programs but it's not involved in the actual TLS handling.
(I'm not sure I should elaborate on that)
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.
Though difficult to compare, it looks a lot like with I did, with the big difference that the TLS parts runs in two additional processes. I experimented with pledge in tls_client some time ago. To the best of my knowledge, as soon as the application data exchange begins it can run pledged with "stdio". I haven't thought about re-keying half way, this might change the pledge.
