On Oct 16, 2015, at 1:01 PM, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
On Oct 16, 2015, at 11:15 AM, Mathieu Simon (Lists) <matsimon.lists@simweb.ch> wrote:
Hi
Am 16.10.2015 um 16:31 schrieb Alan DeKok:
On Oct 16, 2015, at 10:29 AM, A.L.M.Buxey@lboro.ac.uk wrote:
We use them because everything else is worse. :(
LibreSSL ? :-)
It's API compatible with OpenSSL, and it doesn't add new / better APIs.
Concerning a new / better API in LibreSSL: The OpenBSD folks have the same / similar concerns bout the OpenSSL API. True, they have libssl for backwards-compatibility but have added a new libtls library trying to address these concerns.
Their goal is to provide more simple API where an application can ask for a secure channel and libtls will do the reset - no need for the application to know and handle the gory details about TLS version etc. - that's their actual motivation. OpenBSD has started using libtls in tools of their base system for what I know and LibreSSL has become portable for quite some time.
We can't use it. All the functions it provides assume I/O over a file descriptor. We don't use file descriptors for EAP, we use record buffers.
It also makes the protocol progression completely opaque, there's no way to see what state the TLS session is in, which I believe is needed for the EAP-TLS code to function (i'm still working through that mess). It would also break all the session caching code we added, because again, no visibility into that, and no session serialization/deserialization functions. I would *LOVE* a better TLS library, but libtls isn't it, it's a lobotomized (though admittedly, slightly more consistent) version of the OpenSSL API. Great if you want to write a web server, useless if you need anything more complicated. -Arran