Parsing support for RSASSA-PSS signatures

A long time ago, the RSA standard or more specifically the PKCS#1 standard, got an upgrade from version 1.5 to version 2.1. PKCS#1 version 2.1 introduced some nice features such as a probabilistic signature scheme. And although a lot of certificates are signed with RSA, most use the old signatures and not the new RSASSA-PSS signatures. We are now seeing an uptake in RSASSA-PSS signature in some standards and thus integrated support for parsing and verifying these signatures in the standard structures, like X.509 certificates, CSRs and CRLs.

Variable key length support in cipher layer

The cipher layer now has direct support for variable key lengths for ciphers, such as Blowfish. Meaning that you can now use non-standard keysizes without having to hack your way around the old limit.

So for ciphers that have the POLARSSL_CIPHER_VARIABLE_KEY_LEN flag (like Blowfish), you can use cipher_setkey() with any key length.

Server-side enforcement of renegotiation requests

This release provides more flexibility on the server side on how to handle clients that do or do not respond to a renegotiation request.

If a server sends a HelloRequest message to the client in order to let the client initiate renegotiation, the server now allows the client to send up to renego_max_records of data packets before it will will forcefully break the connection for non-compliance. This is especially important when there might be data packets in transit when the HelloRequest is sent.

This behaviour is controlled by ssl_set_renegotiation_enforced().

RAM optimizations

A number of smaller RAM optimizations are introduced to further help low-RAM environments.

We now provide a number of standard configurations (located in configs) to show low-memory-usage scenarios (such as *configs/config-ccm-psk-tls1_2.h).

Further optimizations can be done based on specific needs and platform options.

The new CCM-PSK configuration results in a 51K binary with 12.5K RAM usage for a client-side handshake. (This is with a non-optimized libc implementation).

Usage pattern: _init() / _free()

Simple usage patterns improve security and prevent mistakes. In order to further improve PolarSSL usage, the _init() / _free() pattern is now omnipresent. All useable contexts within PolarSSL now have a _init() and _free() function.

That means that in principle you can now put all _init() calls at the start of your function, and all _free() calls at the end, and there is no risk in memory loss or unexpected data when goto exit; is called.

In the 1.3 branch this does not hold for all contexts. Specifically not for contexts that have an _init() function that can 'fail'. For example contexts like ssl_context and ctr_drbg_context still require a memset() initialization at the start, because there initialization functions (ssl_init() and ctr_drbg_init()) can result in an error.

In the next major release, we will enforce that _init() functions cannot fail (void return type), and further initialization such as allocating internal memory structures (which can fail), requires another function call. So the behaviour of functions like ssl_init() will be split in a true ssl_init() to initialize the structure, and another function to do the fault-sensitive initialization parts.

We feel that the increased security and clarity from the new usage pattern weighs up to the introduction of an extra initialization function for some contexts.

Single zeroization function

In this version PolarSSL introduces a single polarssl_zeroize() function that is used in all modules instead of memset() to clear sensitive information from memory. In some cases, a simple call to memset() could be optimized away by the compiler, while polarssl_zeroize() is designed to avoid that. Another advantage is that it is now clear in code if a statement is meant to just initialize (memset()) a buffer, or clear potentially sensitive data (polarssl_zeroize()).

All _free() functions for contexts use polarssl_zeroize() to clear context data from memory.