On Tue, Jan 10, 2017 at 2:05 PM, Remco <re...@dpub.nl> wrote: > 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)
I'm not sure that this is a meaningful distinction for that risk model. Well.. it is a distinction - there's some enforced entropy here. And, also, this does document something about how the system operates. But if the concern is a compromised tls_socketd, what prevents it from either (a) invoking a compromised instance of tls_client, or (b) invoking a compromised instance of the helper, or (c) pretending to do so while performing those activities itself (for example: use dlopen or patch in a binary blob to bring in the needed functionality)? Any of these would require some work, certainly, but that's a mere matter of time and effort. Thanks, -- Raul -- Raul >> 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.
