Security of fleaTLS

As a cryptographic and TLS library, fleaTLS has to realize robust security for its functions on a number of different layers. Three layers can be identified: At the lowest level we have the cryptographic implementations, i.e. the symmetric and asymmetric algorithms. The next level is the X.509 certificate and CRL processing. On top of it builds the TLS protocol, with its protocol logic. In the following we describe our implementation and testing approaches to achieve security on all of these layers.

Security on the Cryptographic Layer

On the cryptographic layer, the two main challenges are bug-free implementations of the algorithms and resistance to side channel attacks. fleaTLS addresses the first point by a solid set of test vectors and random tests for all the algorithms.

Regarding the side channel security, fleaTLS realizes a number of measures to achieve security against side channel attacks targeting the public-key algorithms such as timing and power analysis attacks. For RSA and ECC, fleaTLS implements the measures "Square and Multiply Always" and "Add and Double Always", respectively. Furthermore, it realizes a measure which inserts both random and pseudorandom delays within the execution of the private RSA or ECC operation. The pseudorandom delays are derived from the public input to the operation together with a secret value, and thus are always the same if an operation is carried out repeatedly, but are always unknown to the attacker. This has a clear advantage over purely random delays: With only random delays, an attacker is capable of use a large number of measurements for the same input and "average" out the random delays and thus indirectly retrieve a measurement for the undistorted operation. With fleaTLS' method using additionally the pseudorandom delays, this is not possible: Repeated measurements of the same operation yield the same unknown pattern of pseudorandom delays (additionally to a pattern of random delays), and thus an attacker never retrieves indirectly an undistorted measurement.

The pseudorandom delays also include the execution of fake iterations of the RSA or ECC exponentiation.

We address a number of further side-channel related issues that are specific to TLS in the TLS section further down.

Security on the X.509 Layer

The validation of X.509 certificates builds on the ASN.1/DER tag-length-value encoding and the processing rules for certificates and revocation lists specified in RFC 5280. In order to achieve trust into an implementation of the X.509 certificate and CRL processing as robust and secure, extensive tests are necessary. fleaTLS features both a standalone certification path validation as well as the certificate validation within TLS. The testing approach of the X.509-related functionality taken by us is based on a number of different tools respectively test suites. First we address the test suites covering the logical aspects of certificate and CRL validation that we are using:

  • Certification Path Validation Test Tool (CPT). This is a tool released in March 2018, in the development of which we also participated. It allows for the generation of positive and negative test cases of the X.509 certification path validation including revocation checking based on CRLs. For the testing of fleaTLS we use the default test suite shipped with the CPT as well as a number of additional self-defined tests. The latter especially address elliptic curve certificates, which are not featured by the CPT's default test suite.
  • NIST's PKITS test suite. This is a set of static test data in the form of X.509 certificates and CRLs to realize positive and negative test cases of the X.509 validation and is considered a standard for the testing of this functionality. The coverage of these tests is very broad. Our internal test suite applied to fleaTLS contains the subset of the PKITS tests relevant to X.509 functionality realized by fleaTLS (i.e. based on the set of supported certificate extensions).

The X.509 certificate test suites are applied both to fleaTLS' standalone certification path validation as well as to its TLS client and server implementations.

As in the past numerous cryptographic libraries have suffered from memory access errors, i.e. buffer over-reads or over-writes, within their X.509 parsing code, the known answer tests realized by the X.509 test suites explained above is not sufficient to achieve trust into an implementation. To address memory access errors, fuzz-testing is the method of choice. Specifically, we use the tool Certificate Fuzzer, which creates a set of certificates with various encoding errors such as missing or malformed fields and invalid ASN.1/DER encodings.

Furthermore, we use American Fuzzy Lop (AFL), a security-oriented intelligent fuzzer. It dynamically generates new mutations of the input data in order to reach a large number of code paths. For this purpose it supports instrumentation of the binary during compilation. While the fuzzer is responsible for the generation of mutated input data, the detection of potential memory errors while processing the input data is ensured by AdressSanitizer (ASAN). The AFL/ASAN fuzz-testing approach is applied to the certificate and CRL validation routines, both the standalone certification path validation as well as that of TLS, since, as explained in the TLS section, AFL/ASAN-based fuzzing is also applied to the TLS handshake messages.

Security on the TLS Layer

The implementation of the TLS protocol itself involves the invocation of the cryptographic and X.509-related functions as well as all the TLS protocol logic. At the heart of the TLS protocol lies the handshake protocol, being by far its most complex feature. In TLS, handshakes occur in three different contexts: initial handshakes, renegotiation handshakes and session resumption handshakes. The first two are equal with the exception of some details, while the session resumption handshake has an entirely different control flow. Numerous TLS extensions introduce further control flows variants in the handshake. Furthermore, the TLS protocol supports the sending of application data after the initial handshake and the TLS alert protocol to indicate warnings or fatal errors.

In order to test the TLS protocol logic of fleaTLS, we chose to implement our own test tool. Numerous TLS test tools are already available but we did not find any one which covers all the protocol aspects we wanted to test. Based on the Botan library, we developed a new tool, we refer to as "TLS-Dragon", which supports a wide range of tests on TLS layer. It executes tests covering aspects such as:

  • iterating through all the supported cipher suites and check that handshakes can be executed properly,
  • accepted and denied renegotiation handshakes as well as variations of invalid control flows for the renegotiation indication extension,
  • session resumption,
  • cipher suite negotiation including negotiation of signature algorithm and elliptic curves,
  • variations of the record size within and outside the allowed range,
  • iteration through all allowed padding lengths for the CBC cipher suites,
  • running into connection time-outs, that means for instance receiving a record fragmented over multiple TCP packets and thus multiple calls to the socket read function,
  • receipt of alerts at different points within the protocol,
  • skipping of handshake messages leading to invalid control flows,
  • positive and negative test cases for certificate and CRL validations for server and client authentication based on the CPT and PKITS test suites mentioned above as well as further self-defined test cases.

One of the most important features of TLS-Dragon is that it supports execution of the test subject for all test cases under ASAN as well as Valgrind. The former tool has already been explained above. Valgrind serves similar purposes, but is more feature rich in some aspects. It offers also detection of memory errors like ASAN does, but in addition to that it also detects memory leaks. Moreover, we also use the multi-threading debugging tool Helgrind included within Valgrind. This tool finds potential data races and thread locking problems. The two main drawbacks of Valgrind compared with ASAN are the dramatic slow-down it introduces and that due to lack of access to the compilation process it cannot detect all classes of memory access errors. This is why we chose to support both tools to achieve the maximum of memory error detection capability.

In addition to these logical tests for TLS we also perform fuzz-testing based on AFL similarly to the way we apply it to test the X.509 processing described above. For this purpose, we recorded a valid TLS handshake, which we replay to the fleaTLS client or server. In a sequence of tests, we select one after another one handshake message within that handshake which is subjected to modification by AFL, while the remaining ones are left intact. AFL then applies its code-path-coverage algorithm to reach all possible code paths within the handshake TLS message parsing code by introducing modifications to the originally recorded handshake message. With this test, memory access errors contained in the TLS handshake message parsing code would be detected with a high probability.

Furthermore, we use tlsfuzzer for additional fuzz-testing and TLS-Attacker for tests for cryptographic vulnerabilities. Some of the cryptographic algorithms that are used within TLS pose challenges, since they are specified in the standard in such ways that it is difficult for implementers to avoid introducing subtle errors, as many recent research reports show. This applies to Bleichenbacher's Padding Oracle Attack as well as the "Lucky 13" vulnerability. These points are addressed in the next section, where we explain how fleaTLS achieves security against known historical attacks.

Resistance to Known Attacks on TLS

In this section we address how fleaTLS achieves security against known attacks.

Bleichenbacher's Padding Oracle Attack / ROBOT

Bleichenbacher's padding oracle attack is a historical attack that aims at the vulnerable PKCS#1 v1.5 decryption operation. It can lead to the recovery of the premaster secret and thus the session keys in a TLS implementation which does not feature appropriate countermeasures. The ROBOT attack from 2017 is a refinement of the historical attack.

fleaTLS implements solid countermeasures in form of a constant-time PKCS#1 v1.5 decoding and reveals no information about the decryption result. This was experimentally verified using the tools TLS Attacker and, both of which implement the refined ROBOT attack as part of their test suite.

Bleichenbacher's Low Exponent Attack and BERserk

Bleichenbacher's low exponent attack and its variants have as their precondition an erroneous implementation of the parsing of the PKCS#1 v1.5 signature padding for RSA. fleaTLS implements the validation of the padding by comparing the correctly encoded message representative to the one output by the RSA operation and is thus secure against this attack. This is also confirmed by one test from the CPT test suite we are using. The BERserk attack variant is defeated for the same reason.

CBC Padding Oracle Attacks, Lucky 13, and POODLE

The CBC mode as specified in TLS 1.2 is prone to exhibit implementation vulnerabilities if it is not carefully implemented. One threat is to be vulnerable against the historical CBC padding oracle attacks. fleaTLS implements appropriate countermeasures within the CBC mode decryption and was verified using TLS-Attacker to be immune against these attacks.

POODLE is a variant specific only to SSL 3.0 and prior versions and thus does not affect fleaTLS which only supports TLS versions from 1.2 onward.

Another more recent attack variant is referred to as Lucky 13, which is based on the analysis of response times. fleaTLS implements a novel countermeasure against this attack that is in our opinion more reliable than previously proposed ones. Specifically, we reach completely constant timing for the removal of the padding and the MAC verification in case of an attack, as far as this can asserted on the source code level. In an upcoming blog article we will discuss this matter in some more detail.


fleaTLS is not affected by BEAST, since it does not implement the affected TLS protocol versions TLS 1.0 and lower.


fleaTLS is not affected by CRIME, since it does not offer TLS compression. BREACH is related to HTTP compression that is beyond the control of a TLS implementation.


SMACK refers to attacks on the state machine that realizes the message flow in the TLS handshake. Our own tool TLS-Dragon executes systematic message skipping tests to ensure that fleaTLS is safe against this type of attack. FREAK is a variant of SMACK referring to a vulnerability where the use of weak ephemeral keys can be enforced by a man in the middle attack during the handshake due to errors in the state machine logic. fleaTLS does not at all support the export grade cipher suites which are exploited in this attack.


Logjam targets weak classic Diffie-Hellmann groups. Since fleaTLS only supports the elliptic curve variant of Diffie-Hellmann (ECDH), it is immune to this type of attack.


The SLOTH attack exploits the usage of signature algorithms featuring a weak hash algorithm during the handshake. The attack has been proven to be practical only when MD5 is used. fleaTLS does not at all support MD5 as a signature hash algorithm, and thus is immune to the attack.

fleaTLS does, however, support SHA-1 as a signature hash algorithm during the TLS handshake. Even though practical attacks against SHA-1 during the TLS handshake have not been presented yet, it is recommended not to configure the SHA-1-based signature algorithms.

Renegotiation Attack

In the Renegotiation Attack, an attacker can connect anonymously to a server, exchange data with it and then connect a client that is connecting to himself to that server in a renegotiation handshake. This happens in a such way that the server believes to be connected to the same client all the time, and the client sees the handshake as an initial handshake. fleaTLS implements the renegotiation indication extension, which specifies a secure renegotiation procedure and prevents the attack. The library can be configured to accept no renegotiation handshakes at all or only secure renegotiations.


The triple handshake or 3SHAKE attack allows a malicious server to forward a client connecting to it via TLS secretly to another server after having injected malicious content into the connection. However, the attack relies on the client to accept a server certificate in a renegotiation handshake which features a wrong hostname. Since fleaTLS verifies the hostname of the server even in a renegotiation handshake, if hostname verification is specified in the initial handshake, a fleaTLS client is not vulnerable to the 3SHAKE attack. For a TLS server, there is no practical and reliable way to prevent the attack. The only way would be to enforce the usage of the Extended Master Secret Extension. This, however, would break compatibility with many clients. fleaTLS does not yet support this extension.


The RC4 algorithm is rated as insecure. fleaTLS does not support RC4.