Not sure the trade off line has been drawn in the correct place here. TLS should be implemented as a filter; the world isn't limited to files and (blocking) sockets. What about integration with event loops, for example? How does one test this API?
Please correct me if I'm wrong, but I believe that the OpenSSL API allows one to implement the actual transport of the TLS protected data however one chooses, although it provides convenient socket/fd transports. Is this a possibility with this new API? Regardless of whether OpenSSL can do it today, I consider this a very valuable feature and allows for more flexible composition of the TLS implementation and the rest of the system.<p>Edit: Grammar.
This isn't a standalone implementation (yet [1]). It's a sane wrapper around OpenSSL's less sane libssl API.<p>[1] <a href="https://marc.info/?l=openbsd-tech&m=141524972826918&w=2" rel="nofollow">https://marc.info/?l=openbsd-tech&m=141524972826918&w=2</a>
To better understand the basic reasoning behind this API, I recommend to read the last section ("ressl") of:<p>"LibreSSL: More Than 30 Days Later"<p><a href="http://www.openbsd.org/papers/eurobsdcon2014-libressl.html" rel="nofollow">http://www.openbsd.org/papers/eurobsdcon2014-libressl.html</a>
It's probably still early to be using this, unless it's of particular interest (interest is encouraged, of course!). There's a reason the server API isn't documented, for example.
How does one poll for socket activity using this API, given that a read on a socket doesn't necessarily mean that decrypted data is available, and yet that socket writes may be required?
Other TLS libraries tend to have an OpenSSL compatibility layer. Now here’s yet <i>another</i> API for them to write compatibility layers for. This is a bad trend.<p>I’m thinking that there ought to be an API defined by an IETF working group and specified in an RFC (like the IPv6 API C interface is), with obvious room for expansion for library-specific features. Then all TLS libraries could implement <i>that</i> API and end the madness.<p>INB4 xkcd 927: <a href="https://xkcd.com/927/" rel="nofollow">https://xkcd.com/927/</a>
Do the defaults strike the best balance between security, PFS and compatibility? Because I think that's really the problem with the TLS libraries I've used, and introducing a new API is a good opportunity to fix that. What happens, for example, if I don't call
tls_config_set_ciphers()?
Host and cert verification by default is good. You can use tls_config_set_ciphers to set a cipher string, but I don't see if they disable unsafe ciphers by default.