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

Nico Williams <> Wed, 27 November 2013 23:54 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 797161ADFD7 for <>; Wed, 27 Nov 2013 15:54:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id VwRxVegLEm3L for <>; Wed, 27 Nov 2013 15:54:56 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 32F281ADF7C for <>; Wed, 27 Nov 2013 15:54:56 -0800 (PST)
Received: from (localhost []) by (Postfix) with ESMTP id 9C70BB8058; Wed, 27 Nov 2013 15:54:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to;; bh=2LsVkCHudUjwLS v4RG9xLytiku8=; b=d7KQgw2NGf0sVtWvCk+8ukYvgXVq9FE/3u0EslvXeAoPT0 anmrtNiTJTBu6XEsABEm0mtrSOtPiB38oV15KJ05dir1iGK2t0XZMFpp9d1JyFr2 Nig4uUz8IP2GfsALLvvFtapf0qNKURevnuj9KrhUySlkgxgIduCpRJT4epaUM=
Received: from localhost ( []) (Authenticated sender: by (Postfix) with ESMTPA id 37C2EB8057; Wed, 27 Nov 2013 15:54:55 -0800 (PST)
Date: Wed, 27 Nov 2013 17:54:54 -0600
From: Nico Williams <>
To: Andy Lutomirski <>
Message-ID: <20131127235451.GW21240@localhost>
References: <> <> <> <> <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Patrick Pelletier <>, "" <>, GnuTLS development list <>
Subject: Re: [TLS] multiple clients in one process (was: Re: Deployment ... Re: This working group has failed)
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 27 Nov 2013 23:54:57 -0000

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