[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150928020441.GA20842@brightrain.aerifal.cx>
Date: Sun, 27 Sep 2015 22:04:41 -0400
From: Rich Felker <dalias@...c.org>
To: tlsify@...ts.openwall.com
Subject: Introduction & summary of tlsify discussions, part 1
The basic concept of tlsify is to provide a TLS API which allows
POSIX/file-descriptor-oriented applications to make use of secure
(TLS) sockets without invasive changes to their programming model.
Normal payload data is to be transferred via send (or write) and recv
(or read) on a file descriptor just like for a non-TLS connection. For
most application usage, TLS-specific code should be possible to
isolate to connection setup/acceptance, and should be near-trivial.
The initial API boundary for tlsify is an external command to be
executed as a child process of the program making or accepting a TLS
connection; the API is defined in terms of its command line,
environment, and initial file descriptors. This makes the API
language-agnostic.
These design concepts originated within the musl libc community, where
many users have been frustrated that the need to transition to using
TLS everywhere is making it difficult to get by with simple utilities
that do not have large abstraction layers for IO. In particular,
Busybox wget does not support https.
I introduced these API ideas at the Core Infrastructure Initiative's
Madrid workshop (CII-Madrid) where we expanded on how they make sense
to a larger programming/user audience:
- Address space isolation to prevent another Heartbleed.
- And related to that, other benefits of keeping the TLS
implementation library out of the calling program's address space --
library version compatibility issues, etc.
- Swappable underling TLS implementations without costly integration
of multiple library APIs (and #ifdef) in the calling program.
- Ability to implement TLS in higher-level languages (like OCaml) and
still have the implementation be practically usable by C programs
(by having the API boundary at the external-command level).
- No need for language bindings; any language that can spawn external
programs and communicate via sockets can automatically use it.
- Possibility to automatically take advantage of TCP fastopen if
socket connection is deferred to the tlsify process.
Discussion at CII-Madrid focused on determining requirements for the
API such that it's not artificially restrictive with respect to usage
cases.
We wanted to go through an enumeration of usage cases for TLS (things
like wget-like utility, REST API client, IRC client, etc.) but did not
have the right people present so this is still an area that needs to
be reviewed.
One of the big questions is how certificate checking should work. We
determined the source for recommended practices for certificate
checking: RFC 6125. This also provided much of the language/model
needed to discuss the topic, such as concepts like "acceptable
reference identifers". Further requirements research is needed here.
Discussion of the communication channels considered different options
for how the calling application should setup data and control
channels. It was deemed most flexible, and not costly, for the tlsify
process to use both stdin and stdout as the two directions of the data
channel, and not to mandate that they be a socket. For example a
caller might prefer to use separate pipes for each direction, or even
a file on disk. No advantage was seen to forbiddign such usage. The
canonical/expected usage however is for the caller to set up an
AF_UNIX socketpair and attach one end to both stdin and stdout of the
tlsify process so that, from the application side, it behaves nearly
the same as a normal TCP socket.
In addition to the data channel, some sort of control channel is
likely needed for non-trivial usage. In the tlsify-to-application
direction, this control channel would provide access to the peer's
certificate, TLS-level errors, etc. It remains an open problem how
this control channel should be designed such that it's sufficiently
flexible to meet application needs without requiring complex library
code on the application side to interact with the control channel. It
was not yet clear whether a bidirectional control channel is needed.
One open question area was renegotiation. It was noted that
renegotiation is actually a useful feature when using client certs,
since clients will not want to disclose their identity in the clear or
to a server whose identity they have not yet confirmed, since this
would be a breach of privacy. So renegotiation probably needs to be
well-supported/efficient.
We enumerated some of the possible initial inputs needed by the tlsify
process as (list verbatim from my CII-Madrid notes):
- Server name (for SNI use)
- List of "acceptable reference identifiers" (RFC 6125 6.2.1)
- Data channel opened as stdin/stdout
- Control channel on stderr?
- Pinned certificate (is this the whole cert? or just key/fingerprint?)
- Client certificate
- Minimal acceptable security levels
Some consideration of how these inputs should be passed (concern about
leakage of command line strings) was made, but no conclusions were
reached at the time.
One of the most important API considerations is certificate checking.
It was generally agreed that certificate checking should be on/strict
by default and that the API should make it "easy to do the right
thing". The caller should easily be able to opt for checking against
system-wide CA certs, a caller-provided set of CA certs, and/or a
particular expected/pinned cert. As far as I remember (I don't have
notes on this) no conclusions were reached about whether it should be
possible to simply disable cert checking or whether the application
should have to first make a failed connection and save the cert to use
as an expected cert when retrying. Valid usage cases for disabling
checking (in development environments) were discussed to some extent.
One particular related topic discussed outside of the main session was
global state/configuration, e.g. system-wide or dotfile-level
configuration of certificate checking. While it seems inevitable that
CA certs be a sort of global, I expressed a strong desire to avoid
global state/configuration for specific behaviors of cert checking.
That's about all I have in the way of notes/recollection up through
CII-Madrid. Next I'm going to follow up with summary/quotation of some
off-list follow-up discussion that happened before the tlsify list was
setup. If I missed anything important in the above summaries please
fill it in with a reply.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
