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.