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

mbed TLS 2.0 defaults implement best practices

One of our major goals in mbed TLS is to be not only easy to use, but more importantly easy to use securely. A part of this is providing good default values for security parameters. In mbed TLS 2.0, the defaults were updated to match the recommendations of RFC 7525, which documents the best current practices for (D)TLS deployments.

This article goes into the details how the recommendations are met by our default SSL configuration as loaded by

mbedtls_ssl_config_defaults( ..., MBEDTLS_SSL_PRESET_DEFAULT );

For the rationale behind the recommendations, see RFC 7525 itself.

Protocol versions

  • SSLv2 and SSLv3 must not be negotiated: we never implemented SSLv2, and as of mbed TLS 2.0, SSLv3 is disabled by default.
  • TLS 1.0 and TLS 1.1 should not be negotiated: TLS 1.2 is enabled by default and will always be used if the peer supports it.
  • TLS 1.2 must be implemented: we do implement TLS 1.2 since PolarSSL 1.3.0.

Fallback (that is, retrying with a lower max version) is under the control of the users, we will never do it automatically, so if you choose to do fallbacks, it's up to you not to fall back to SSLv3. (If you choose to do fallback, we do implement RFC 7507 to provide some level of protection.)

Strict TLS - not falling back to cleartext

This belongs to the application layer, there is nothing we can do about it (except making TLS as easy to use as we can).


  • Should be disabled: support for TLS compression is disabled by default at compile time and the configuration file where it can be enabled has an explicit warning about the security issues.

Session resumption with session tickets

  • Must use a strong cipher suite to protect the ticket: we currently offer a choice of AEAD ciphers to be chosen by the user; the documentation recommends AES-256-GCM and the examples use that.
  • Ticket keys must be changed regularly, at least every week: we implement automatic key rotation, with a period chosen by the user; the documentation recommends two days and the examples use that.
  • Ticket validity should be limited: it is limited to half the period of key rotation; see previous point.

TLS renegotiation

  • Secure renegotiation must be implemented: we do implement it since PolarSSL 1.2.0.
  • Certificate changes should be prohibited: we do prohibit it since PolarSSL 1.3.5
  • The same validation policy should always be applied: we always did that, and since mbed TLS 2.0 we changed the default to immediately break the handshake if validation fails.
  • The session hash draft should be implemented: we do implement it since PolarSSL 1.3.10

Note that the second and third items are each sufficient to prevent the so-called "triple handshake" attack, at least in its original form.

As an additional step not mentioned in the RFC, as of version 2.0, renegotiation is disabled by default, so that users who don't need will not be exposed to the risk that further attacks against it are found in the future. (For users who need it, it can easily be enabled at runtime. For users building with a custom configuration, all renegotiation-related code (except for the secure renegotiation extension) can be disabled for improved security and lower footprint.)

Server name indication

  • Must be supported: we do support it since PolarSSL 1.2.0.

Ciphersuites - general guidelines

  • Must not negotiate NULL ciphersuites: they are disabled by default at compile-time.
  • Must not negotiate RC4 ciphersuites: they are disabled by default. They can be enabled at runtime, but it is purposefully tedious (needs to change two independent options).
  • Must not negotiate < 112 bits ciphersuites: they are disabled by default at compile-time.
  • Should not negotiate < 128 bits ciphersuites: they are at the bottom of the priority list, so will never be selected unless the peer doesn't support anything better.
  • Should not negotiate static RSA ciphersuites: they are at the bottom of the priority list, so will never be selected unless the peer doesn't support anything better.
  • Must support and prefer ciphersuites with forward secrecy: we do support a lot of them, and always prefer them.

Recommended ciphersuites

All four of them are supported and very close to the top of our default priority lists. The only ciphersuites with higher priority have equal or better security but are not recommended by the RFC for compatibility reasons (for example, replacing ECDHE-RSA with ECDHE-ECDSA).

The recommented elliptic curve (NIST P-256) is supported and the recommended point format is the only point format we support.

Public key length

  • DH parameters of 2048 bits or more are recommended: server-side, that's the default size we use. Client-side, for now we still accept parameters down to 1024 bits for compatibility reasons: as of today, about 35% of HTTPS servers still use this size, according to SSL Pulse.
  • Curves of less than 192 bits should not be used: we do not even implement such curves.
  • RSA certificates should use keys of at least 2048 bits: by default we reject certificates with smaller keys.
  • Certificates should be signed with SHA-256 at least, not SHA-1: currently we still accept SHA-1 certificates as they represent almost 40% of the certificates used by popular HTTPS servers. However, we do indicate our support and preference for SHA-256 or higher as recommended. Also, server-side we support provisioning of multiple certificates and serving of the SHA-256 one to clients that support it.

Truncated HMAC

  • Should not be negotiated: it has always been disabled by default client-side, now it is also disabled by default server-side.

Security services

By default we provide authentication of the server as recommended. Client authentication may be enabled. Server authentication may be disabled, which is appropriate in some contexts (opportunistic security), but the documentation and examples warn against it.

Host name validation

By default we perform hostname validation according to RFC 2818, which is appropriate for HTTPS. Other kind of validations can be implemented by the user via the verify callback.

(EC)DH exponent reuse

We do not reuse (EC)DH exponents, so we are immune to the potential issues associated with exponent reuse.

Certificate revocation

We do support Certificate Revocation Lists (CRLs). Support for OCSP and associated extensions, such as OCSP stapling, is planned for future releases in the current stable branch.

Like this?




Last updated:
Jul 24, 2015


Want to stay up to date?