Closed krizhanovsky closed 8 years ago
Here are results of benchmarks of mbed tls, wolfssl and libressl.
Modificated libressl's s_client is used to connect to stud and send 16 MB of random (from /dev/urandom) data at a time (in the 1st test). Stud doesn't resend the received data neither processes it anyhow just reading it to a buffer.
Since the difference is too large between the results, it seems the benchmarks require more observations. Probably there are communication issues (actually there are and we saw some of them) and generation of crypto-context on negotiation phase.
Also there are some licensing issues (see The OpenSSL License and The GPL and Frequently Asked Questions about Fedora Licensing) and generally speaking OpenSSL (and LibreSSL corespondingly) is GPLv2 incompatible, so we can't mix Linux kernel with OpenSSL/LibreSSL code.
The suitable libraries with licensing compatible with GPLv2 are: GnuTLS, mbed TLS and wolfSSL. The first one is 2-3 times larger than the others and contain many unnecessary things like OpenPGP, mbed TLS is bit smaller than wolfSSL and has good code organizing and coding style more close to Linux kernel.
We have to port the library to our buffer-less (i.e. all data is processed synchronously as soon as skb arrives to network interface) Synchronous Sockets IO, rework synchronization, timing, signal handling and other system dependent pieces of code. Therefore, smaller mbed TLS with more straightforward code organization is more suitable for porting to Linux kernel.
A simple benchmark, probably based on Stud, on top of tempesta/ktest framework must be implemented to compare performance of the resulting implementation against LibreSSL, GnuTLS and wolfSSL.
High-Tech Bridge provides free SSL Server Test, so we can use it for initial test of the implementation.
mbedTLS was updated to 2.3.0 (80e6d70619215017ebc2d10c942c8ce01c3fb12d)
After merging TLS implementation (92c51182d6fc6d372b714ca98ae96638e03878b2) me and @keshonok run Free SSL Server Test collecting debugging information via dmesg.
Analyzing kernel's log for TLS errors shows us the following:
$ grep mbedtls tls-test.log | grep returned | cut -d' ' -f 9 | sort | uniq -c
6 (-0x7180)
255 (-0x7280)
1 (-0x7780)
65 (-0x7880)
/* Verification of the message MAC failed. */
#define MBEDTLS_ERR_SSL_INVALID_MAC -0x7180
/* The connection indicated an EOF. */
#define MBEDTLS_ERR_SSL_CONN_EOF -0x7280
/* A fatal alert message was received from our peer. */
#define MBEDTLS_ERR_SSL_FATAL_ALERT_MESSAGE -0x7780
/*The peer notified us that the connection is going to be closed. */
#define MBEDTLS_ERR_SSL_PEER_CLOSE_NOTIFY -0x7880
$ grep TLS tls-test.log | grep ERROR | awk '{print $NF}' | sort | uniq -c
22 (6980)
14 (6e80)
4 (7180)
81 (7380)
13 (7900)
5 (7c00)
/* None of the common ciphersuites is usable. */
#define MBEDTLS_ERR_SSL_NO_USABLE_CIPHERSUITE -0x6980
/* Handshake protocol not within min/max boundaries */
#define MBEDTLS_ERR_SSL_BAD_HS_PROTOCOL_VERSION -0x6E80
/* Verification of the message MAC failed. */
#define MBEDTLS_ERR_SSL_INVALID_MAC -0x7180
/* The server has no ciphersuites in common with the client. */
#define MBEDTLS_ERR_SSL_NO_CIPHER_CHOSEN -0x7380
/* Processing of the ClientHello handshake message failed. */
#define MBEDTLS_ERR_SSL_BAD_HS_CLIENT_HELLO -0x7900
/* Processing of the ClientKeyExchange handshake message failed. */
#define MBEDTLS_ERR_SSL_BAD_HS_CLIENT_KEY_EXCHANGE -0x7C00
In my opinion, everything looks good, in spite of these errors.
Basic TLS support is implemented, move performance optimization tasks to 0.6 as #614.
Must be implemented TLS support on top of latest stable release of libressl ported to Linux kernel.