轻量级SSL库PolarSSL发布1.3.8.2014-07-11。上个版本2014-05-03的1.3.7。遗留产品线1.2.11 很多应用已支持PolarSSL如hiawatha,OpenVPN,Monkey 相对OpenSSL漏洞频出，这种趋势可能会更明显。

　　此版本包括了一些小的 bug 修复和改进，不会影响现有的 API。

　　完全改进：

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 usecipher_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 aHelloRequestmessage to the client in order to let the client initiate renegotiation, the server now allows the client to send up torenego_max_recordsof 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 theHelloRequestis sent.

This behaviour is controlled byssl_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 whengoto 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 likessl_contextandctr_drbg_contextstill require amemset()initialization at the start, because there initialization functions (ssl_init()andctr_drbg_init()) can result in an error.

In the next major release, we will enforce that_init()functions cannot fail (voidreturn type), and further initialization such as allocating internal memory structures (which can fail), requires another function call. So the behaviour of functions likessl_init()will be split in a truessl_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 singlepolarssl_zeroize()function that is used in all modules instead ofmemset()to clear sensitive information from memory. In some cases, a simple call tomemset()could be optimized away by the compiler, whilepolarssl_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 usepolarssl_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.

下载：https://polarssl.org/download/start/polarssl-1.3.8-gpl.tgz