Light wrapper for libtls in libressl which lets labview easily interface with it
The code for the wrapper dll is in lvlibtls.cpp and lvlibtls.h. These files can be compiled against a standard distribution of LibreSSL (windows builds and compilation source available from https://ftp.openbsd.org/pub/OpenBSD/LibreSSL/, link against libssl-43.lib, libcrypto-41.lib and libtls-15.lib)and National Instruments LabVIEW (/cintools directory, labviewv.lib). Its a whopping 350 lines of code and should compile without difficulty. The code is a bit nicer due to C++ but it should be portable to plain C without much of a challenge -- you just need a queue implementation.
The implementation is to use callbacks provided by libtls to feed data into or out of queues. This allows the library to convert plaintext into encrypted text and back, and labview handles sending the raw bytes around. A similar technique could be done with wolfssl (callback mechanism described https://www.wolfssl.com/wolfSSL/Docs-wolfssl-manual-17-4-wolfssl-api-callbacks.html) and botan (https://botan.randombit.net/manual/tls.html#code-example), but I could not find an example for mbed TLS. OpenSSL should be able to do something similar through bio_s_mem (https://wiki.openssl.org/index.php/Manual:BIO_s_mem(3)) but as with most openssl things it hurt my brain to read their docs. The simplest API for this implementation style was libtls, and its backed by the core of openssl and the security conscious guys at openbsd, so it feels like the safest bet.
None of the functions as provided is thread safe in any way, all the way up or down the call chain. At present it relies on dataflow for thread safety. This is because the ssl library can require a read or a write at any time due to handshaking or re-handshaking, so there is no way to split the interface up into a read half and a write half. They must be conducted in series. You could technically break up the read and write functions such that each thread unsafe part of the library has only 1 reader and 1 writer, but...
An HTTPS implementation which works with a normal browser is included, derived from my lv web tools repo but with adjustments to support TLS. Because of the non-thread-safe nature of the tls code (at least for now) the handler has been transformed from three parallel loops into a single simple state machine. This will likely increase nominal latency a tiny bit for each connection, but for multiple connections shouldn't have any real effect on performance.
vs https://github.com/smithed/lvasynctls lvasynctls was my first attempt at this using boost asio. It works, but it slowly grew to be a complete mess due to (a) my ineptitude and (b) the impedence mismatch between asio's normal usage and my desired usage. That version also works, and it has more features (read exactly what is asked for rather than "some", thread safety, and IPv6 support) but its significantly slower (for a virtual machine running my code vs openssl trying to stream as fast as possible, I get about 80 MB/s with this library and 9-10 with lvasynctls). It used to be faster but it also used to crash a lot more :/