Edit: Grammar.
Yes. Through the terrible BIO_* API.
It's imperfect, but it lets you treat TLS as a "black box" that you shove encrypted/cleartext data into, and get cleartext/encrypted data out.
This API is good for socket communication. Nothing more.
This API could be extended by adding "underlying" read and write functions. Off of the top of my head:
typedef int (tls_underlying_io)(struct tls ctx, void u_ctx, const void in, size_t inlen, void out, size_t outlen);
int tls_set_io(struct tls ctx, void u_ctx, tls_underlying_io u_read, tls_underlying_io u_write)
Where "u_read" is used by libtls() instead of calling read(fd,...), and u_write() is called by libtls instead of write(fd, ..)
* tls_connect() connects a client context to the server named by host. The port may be numeric or a service name. If it is NULL then a host of the format "hostname:port" is permitted.
* tls_connect_fds() connects a client context to a pair of existing file descriptors.
* tls_connect_socket() connects a client context to an already established socket connection.
Yes. Which makes it useless for protocols that carry TLS. e.g. EAP. So I can't use it in my pet project: http://freeradius.org/
The new API is useful if you want to do TLS over sockets. It's completely unhelpful for everyone else.
They just added a new API that answers the most common use cases in a simple, straightforward, and internally consistent way.
That sounds strange, as I believe we're in disagreement. I believe the flexibility should exist, and choosing the transport medium of already encrypted data should be an option for the developer. This is completely unrelated to the security critical configuration of the TLS protocol, i.e. certs, keys, ciphersuites, etc.