Building yaSSL

Linux/Unix:

unzip -a yassl-(build number).zip
./configure
make

To test the build:
cd testsuite
./teststuie

Windows

unzip yassl-(build number).zip
Choose (Re)Build All

To test the build:
Run the testsuite program

Thread Safety

yaSSL is thread safe by design. Multiple threads can enter the library simultaneously without creating conflicts because yaSSL avoids global data, static data, and the sharing of objects. The user must still take care to avoid potential problems in two areas.

A client may share an SSL object across multiple threads but access must be synchronized, i.e., trying to read/write at the same time from two different threads with the same SSL pointer is not supported.

yaSSL could take a more aggressive (constrictive) stance and lock out other users when a function is entered that cannot be shared but this level of granularity seems counterintuitive, all users (even single threaded ones) will pay for the locking and multi-thread ones won't be able to re-enter the library even if they aren't sharing objects across threads. This penalty seems much too high and yaSSL leaves the responsibility of synchronizing shared objects in the hands of the user.

Besides sharing SSL pointers, users must also take care to completely initialize an SSL_CTX before passing the structure to SSL_new(). The same SSL_CTX can create multiple SSLs but the SSL_CTX is only read during SSL_new() creation and any future (or simultaneous changes) to the SSL_CTX will not be reflected once the SSL object is created.

Again, multiple threads should synchronize writing access to a SSL_CTX and it is advised that a single thread initialize the SSL_CTX to avoid the synchronization and update problem described above.

Update: See note below about Session Caching and Multiple Threads.

Session Caching

yaSSL now supports session caching which can greatly decrease the connection processing time when clients re-issue connects within a relatively short time (the default is to cache for 500 seconds). Access to the cache is internally stored in yaSSL with a Singleton and is the only part of the library which isn't thread safe. For users that aren't multi-threaded or don't plan on using session caching and don't want to pay for the locking of this cache, please define SINGLE_THREADED when compiling yaSSL.

Memory

yaSSL doesn't pre-allocate any memory up front for a connection. This allows users to create a large pool of connection objects without paying for a large memory hit. yaSSL only requests memory when it needs it, and returns it to the system when it no longer needs it. yaSSL requires about 32K of memory for a connection (this includes 6K for 3 certificates, and the total will vary depending on certificate size and number as well as the type of connection). After that, yaSSL only requires about 500 bytes of memory to send or receive an SSL message. Users wishing to pre-allocate memory, or take over the memory handling in any way, can implement their own ::operator new and delete.

Supported Cipher Suites

SSL_RSA_WITH_RC4_128_MD5
SSL_RSA_WITH_RC4_128_SHA
SSL_RSA_WITH_DES_CBC_SHA
SSL_RSA_WITH_3DES_EDE_CBC_SHA
SSL_DHE_DSS_WITH_DES_CBC_SHA
SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA
SSL_DHE_RSA_WITH_DES_CBC_SHA
SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_DSS_WITH_AES_128_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_DSS_WITH_AES_256_CBC_SHA
TLS_DHE_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_DSS_WITH_3DES_EDE_CBC_RMD160
TLS_DHE_DSS_WITH_AES_128_CBC_RMD160
TLS_DHE_DSS_WITH_AES_256_CBC_RMD160
TLS_DHE_RSA_WITH_3DES_EDE_CBC_RMD160
TLS_DHE_RSA_WITH_AES_128_CBC_RMD160
TLS_DHE_RSA_WITH_AES_256_CBC_RMD160
TLS_RSA_WITH_3DES_EDE_CBC_RMD160
TLS_RSA_WITH_AES_128_CBC_RMD160
TLS_RSA_WITH_AES_256_CBC_RMD160

No C++

yaSSL is implemented in C++. For those users wishing to use a version of yaSSL without any global C++ symbols, there is a way to achieve this using GCC. Just define YASSL_PURE_C when building yaSSL. No exceptions, RTTI, std library, or global allocators will be defined.

Home