PolarSSL is now part of ARM Official announcement and rebranded as mbed TLS.

PolarSSL 1.3.8 released

Description

PolarSSL 1.3.8 has been released!

On the security front this release fixes a potential Denial of Service attack on PolarSSL entities using GCM (Security Advisory 2014-02) that was found with the Codenomicon Defensics toolkit.

For the rest, this release primarily adds support for the CCM cipher mode and RSASSA-PSS signatures in X.509 structures, in addition to RAM / usage optimizations for specific configurations.

Features and changes

On the feature-front this release introduces:

  • CCM cipher mode support and thus the CCM and CCM_8 ciphersuites
  • Parsing and verification support for RSASSA-PSS signatures in X.509 certificates, CRLs and CSRs
  • Variable key length support for the cipher layer, e.g. for Blowfish
  • Ability to configure server-side enforcement of renegotiation requests
  • RAM optimizations

Other important changes include:

  • Improved usage pattern of contexts
  • Migration to a single, safer, zeroization function

And more.. In addition outstanding bugs were fixed.

CCM cipher mode support

The cipher layer now fully supports AES and Camellia in CCM cipher mode. This naturally results in the fact that we now support the following 20 ciphersuites as well:

  • TLS-ECDHE-ECDSA-WITH-AES-256-CCM
  • TLS-ECDHE-ECDSA-WITH-AES-256-CCM-8
  • TLS-ECDHE-ECDSA-WITH-AES-128-CCM
  • TLS-ECDHE-ECDSA-WITH-AES-128-CCM-8
  • TLS-DHE-RSA-WITH-AES-256-CCM
  • TLS-DHE-RSA-WITH-AES-256-CCM-8
  • TLS-DHE-RSA-WITH-AES-128-CCM
  • TLS-DHE-RSA-WITH-AES-128-CCM-8
  • TLS-RSA-WITH-AES-256-CCM
  • TLS-RSA-WITH-AES-256-CCM-8
  • TLS-RSA-WITH-AES-128-CCM
  • TLS-RSA-WITH-AES-128-CCM-8
  • TLS-PSK-WITH-AES-256-CCM
  • TLS-PSK-WITH-AES-256-CCM-8
  • TLS-PSK-WITH-AES-128-CCM
  • TLS-PSK-WITH-AES-128-CCM-8
  • TLS-DHE-PSK-WITH-AES-256-CCM
  • TLS-DHE-PSK-WITH-AES-256-CCM-8
  • TLS-DHE-PSK-WITH-AES-128-CCM
  • TLS-DHE-PSK-WITH-AES-128-CCM-8

These are of course added to our list of supported ciphersuites.

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.

Bug fixes

Fixes include:

  • Stricter check on SSL ClientHello internal sizes compared to actual packet size (found by TrustInSoft)
  • Fix WSAStartup() return value check (found by Peter Vaskovic)
  • Fix symlink command for cross compiling with CMake (found by Andre Heinecke)
  • Fix DER output of gen_key app (found by Gergely Budai)
  • Very small records were incorrectly rejected when truncated HMAC was in use with some ciphersuites and versions (RC4 in all versions, CBC with versions < TLS 1.1).
  • Very large records using more than 224 bytes of padding were incorrectly rejected with CBC-based ciphersuites and TLS >= 1.1
  • Very large records using less padding could cause a buffer overread of up to 32 bytes with CBC-based ciphersuites and TLS >= 1.1
  • Restore ability to use a v1 cert as a CA if trusted locally. (This had been removed in 1.3.6.)
  • Restore ability to locally trust a self-signed cert that is not a proper CA for use as an end entity certificate. (This had been removed in 1.3.6.)
  • Fix preprocessor checks for bn_mul PPC asm (found by Barry K. Nathan).
  • Use \n\t rather than semicolons for bn_mul asm, since some assemblers interpret semicolons as comment delimiters (found by Barry K. Nathan).
  • Fix off-by-one error in parsing Supported Point Format extension that caused some handshakes to fail.
  • Fix possible miscomputation of the premaster secret with DHE-PSK key exchange that caused some handshakes to fail with other implementations. (Failure rate <= 1/255 with common DHM moduli.)
  • Disable broken Sparc64 bn_mul assembly (found by Florian Obser).
  • Fix base64_decode() to return and check length correctly (in case of tight buffers)
  • Fix mpi_write_string() to write "00" as hex output for empty MPI (found by Hui Dong)

More details can be found in the ChangeLog.

Who should update

We advise users of PolarSSL to update if they:

  • enabled the use of GCM ciphersuites
  • want to use one of the new features

Download links

Get your copy here: polarssl-1.3.8-gpl.tgz

Hashes

The hashes for polarssl-1.3.8-gpl.tgz are:

SHA-1  : 82ed8ebcf3dd53621da5395b796fc0917083691d
SHA-256: 318171db41335cacbb5b0047c94f1faf91442ab70a223b5223436703c9406ff1

Like this?

Section:
Releases

Author:


Published:


Last updated:
Jul 11, 2014

Sharing:


Want to stay up to date?