Re: [TLS] multiple clients in one process (was: Re: Deployment ... Re: This working group has failed)

[Nico Williams <[e-mail]>]

All of this is off-topic for this list.  I'll post a reply anyways, and
I apologize to the list.

On Tue, Nov 19, 2013 at 10:24:03PM -0800, Andy Lutomirski wrote:
>                     [...].  gnutls_global_init is documented as being
> unsafe if called from multiple threads, which seems silly.

Initialization is not thread-safe in OpenSSL either.  This is a terrible
thing.  It *can* be made thread-safe, so there's no excuse for it not
being thread-safe.

> GnuTLS has gnutls_pkcs11_init, which is rather impolite -- it
> manipulates global state, and it sometimes causes things to
> malfunction after forking.  [...]

PKCS#11 is by definition fork-unsafe (see the PKCS#11 docs).

Any API dealing with "tokens" (in the PKCS#11 sense) is bound to be
fork-unsafe for at least open sessions/objects on tokens that require
authentication (PIN).  That's because any library using file descriptors
where offset is not a relevant concept will necessarily be fork-unsafe
by default.  And: any stateful cryptography library (e.g., an
implementation of TLS) will tend to be fork-unsafe (imagine a process
trying to use a TLS connection on both sides of a fork()!).

Of course, that's all rather POSIX-specific, but the problem is inherent
to any fork()-like interface.  Use posix_spawn() or similar, then you
won't have to worry about fork-safety at all.  Long ago I used to think
fork+exec superior to spawn since spawn was easy to implement in terms
of fork+exec, but in truth fork() is a dangerous and difficult-to-use
interface -- the only safe things to do on the child side of fork() are:
async-signal-safe things, culminating in _exit() or exec*() ASAP.

> (As an even more off-topic aside, how is there nothing better than
> pkcs11 for interfacing with abstract keys?)

Not really, not portably, not to my knowledge :(  Something better is
badly needed, yes.

In particular we need: a) decent APIs for software crypto (even if it
uses specialized HW under the covers), b) decent APIs for talking to
smartcards (tokens), including softtokens, c) decent APIs for
cryptographic protocols, d) decent APIs for PKIX naming, ...

Nico
--