Extended Brain Storage

# Currently Known Vulnerabilities of the Transport Layer Security

Posted on January 26, 2020

An attempt to provide a comprehensive overview of known vulnerabilities and recommended parameters for deployment of Secure Sockets Layer (SSL) and Transport Layer Security (TLS) respectively…

Disclaimer: The author tried to provide as many references as possible. However, the Internet was used as the only source.

The principles of operation of the SSL/TLS were discussed in Transport Layer Security Deep Dive including a little bit of cryptography theory.

### A List of Currently Known SSL/TLS Vulnerabilities

Proven by history, the usage of SSL or TLS has never assured 100% confidentiality of the transmitted data.

#### 1998: Oracle Attacks

A cryptographic algorithm attack which explores response of an encryption system based on different PT and response of a decryption system based on different CT. The aim is to acquire useful information which would help disclose secret information (also called an oracle), such as keys. The same as the Pythia (the Oracle of Delphi), it provides an indication to tell an attacker whether their goal was reached. The oracle attacks are also called side-channel attack and there exist the following types:

• Padding oracle attacks
• 1998: Bleichenbacher padding oracle attack
• Also called (full) adaptive chosen-ciphertext attack (CCA2), where Bleichenbacher (Bell Laboratories) demonstrated that an attacker can continue to query a system with further requests to receive PT-CT combinations.
• It was experimentally proved that message encrypted using the RSA and encoded using the PKCS #1 (RSA Laboratories) can be decrypted even without knowledge of the key using a huge amount of messages to an SSL server:
• As part of the RSA, a client randomly selects a session key before establishing a connection. Before sending, the key is encrypted using the public key of the server.
• The server decrypts the message and stores a session key copy, based on which is the client later identified.
• Due to the fact that the RSA is a block algorithm, it completes all incomplete data blocks with appropriate padding as per the PKCS #1.
• It was proved that the client could send a huge amount of random keys to the server and received replies in all cases (valid/invalid).
• 2002: Vaudenay padding oracle attack
• Also called chosen-ciphertext attack (CCA), where Vaudenay demonstrated that the correct format of protocol messages is usually disclosed using a feedback carried out by sending acknowledgements or error messages.
• It was experimentally proved that there exist vulnerabilities caused by block algorithms using CBC (CBC-PAD) in applications such as the SSL, IPsec, WTLS, SSH2 etc.
• The paper defines a bomb oracle (section 3.4), which either returns a response or explodes (attack failed) based on the received input value.
• Compression oracle attack
• Also called chosen-plaintext attack (CPA), when an attacker can prompt a server for further PT-CT combinations even after having acquired a corresponding CTs based on several PTs.
• Using traffic monitoring, it is possible to measure PT entropy based on the knowledge of “size of PT” and the “size of compressed corresponding PT”.
• In the aforementioned case, the oracle (weakness), which discloses the indications, is the compression.

#### 2006: Bleichenbacher’s e=3 RSA Attack

Vulnerability: CVE-2006-4339

• A Bleichenbacher variant of the original attack, which is based on the possibility to spoof message digests if a small exponent, such as e = 3, was used to generate the public RSA key.
• An obsolete version of OpenSSL removed the PKCS-1 padding before generating the hash, based on which, the remote attackers were able to spoof the PKCS #1 v1.5 digest, which was signed using the appropriate RSA key and consequently, prevented correct verification of X.509 or other certificates in the PKCS #1 format.

Solution:

• OpenSSL upgrade to 0.9.7k and 0.9.8c or newer.

#### 2008: Protocol Dance

A downgrade attack, which is a gradual decrease of supported protocol version between the client and the server (i.e. a fallback from the TLS to the SSL), has always resembled an imaginary devil’s dance. More or less, the protocol dance takes place as follows:

• A client (e.g. a web browser) connects to a server using TLS 1.2.
• The server does not respond not understanding the request.
• Client tries TLS 1.1.
• By gradual decrease of protocol version, the worst possible version can be negotiated, i.e. the SSL (3.0 or even 2.0).

This attack is a way to arbitrarily depreciate a client-server communication in order to ensure that the specific version of SSL or TLS, which is a prerequisite for another attacker, is utilised.

On the other hand, decreasing the protocol version could occur also as a result of increased error rate between the client and server. A fall back down to the SSL resulted in an inability to access services (e.g. domain names) which shared the same IP address on a single server due to the fact that SSL 3.0 does not support the Server Name Indication (SNI). The SSL 2.0 does not support it at all.

Solution:

• The only way to deal with the downgrade attack is to support on both sides only modern and up-to-date SW versions and security cryptographic suites and protocols.
• Unfortunately, it was not a simple task at the time of revealing the vulnerability, as the trend was to provide the most possible backward compatibility. Obviously, such request rendered totally inappropriate in the future.

#### 2008: MD5 CA

Practical exploitation of the Message-Digest (MD5) hashing algorithm, see RFC 1321 for more details to find out that since 1992, it has been known that the MD5 was weak, as methods to successfully generate collisions had already been known (i.e. a situation, in which for two or more different inputs, the hashing function produces the same output – digest.)

• For the purpose of a practical demonstration, a counterfeited Certificate Authority (CA) was designed and installed as signed by one of the trusted CAs, which are installed by default in web browsers and operating systems. As a consequence, the web browsers trust any certificate which is signed by the counterfeited CA.
• The vulnerability exploits the fact that it was possible to generate the certificate of the forged CA to deliberately produce an MD5 collision with one of the trusted CA certificates.
• Since the digests of both certificates (trusted and forged) are the same, the trusted CA digest can be simply copied into the certificate of the counterfeited CA.

Solution:

• Not using the MD5 algorithm and utilise the Secure Hash Algorithm (SHA) only (ideally, the SHA-2 and newer).
• At the time of disclosing the vulnerability, no secure mechanisms, such as the HTTP Public Key Pinning (HPKP) extension (see RFC 7469 for more details) were available. On the other hand, the HKPK is not a silver bullet, as a result of which Google, Microsoft and others decided not to implement it into their products anymore.

#### 2009: Client-/Server-initiated Secure Renegotiation

Vulnerability: CVE-2009-3555 (two issues)

1. Renegotiation:
• The TLS and SSL 3.0 protocols (and most probably also the earlier SSL versions) incorrectly associate renegotiation handshakes with an existing connection.
• Using a man-in-the-middle (MitM) attack, attackers are able to insert unauthenticated data into existing HTTPS and other SSL/TLS protected sessions in an attempt to get processed retroactively by a server in a post-renegotiation context.
2. Denial of Service (DoS):
• The renegotiation attack can be combined with a brute-force attempt to trigger hundreds of TLS/SSL handshakes in parallel within the same TCP session.
• This attack can render a powerful server connected using a 30Gbps link unresponsive only using an average home laptop with a DSL connection.

Solution (upgrade of the used SSL/TLS libraries):

• OpenSSL upgrade to 0.9.8m or newer.
• GnuTLS upgrade to 2.8.6 or newer, etc.

Verification:

• Can be performed using the openssl command using the R key (renegotiation) after the session is established.
• The output will naturally differ according to the OpenSSL version used by client and server, but looks similar to the following (output reduced):
$openssl s_client -connect <target>:<port> -msg ... Secure Renegotiation IS supported ... R RENEGOTIATING ... <<< TLS 1.2, Alert [length 0002], fatal no_renegotiation ...  #### 2011: Browser Exploit Against SSL/TLS (BEAST) Vulnerability: CVE-2011-3389 • The problem known since 2002, when discovered by Phillip Rogaway. • The first vulnerability to be named after a deliberate abbreviation was created (a backcronym). • Requires a successful MitM attack on network traffic and injection of malicious code such as JavaScript to violate the same-origin policy (SOP) constraints (more details in the RFC 6454. • The SSL 3.0 and TLS 1.0 protocols encrypt data using block ciphers in CBC mode with chained IVs, which can be exploited when combined with JavaScript code that uses the HTML5 WebSocket API, the Java URLConnection API or the Silverlight WebClient API. • Due to the fact that the IVs can be guessed (foreseen), it is possible to obtain the HTTP header unencrypted (in PT) by the MitM attack in conjunction with the subsequent known-plaintext attack or blockwise chosen-boundary attack (BCBA) to be more precise. Solution: • Set up of browser cookies to HTTPOnly, based on which the browser denies scripts and applets to access their values. • Set up the SOP to Rich Internet Applications (RIAs), e.g. Java applets, Flash or Silverlight, to prevent malicious source code injection into an existing webpage using Cross-Site Scripting (XSS). • Set up appropriate web server configuration, i.e. deny TLS 1.0 cipher suites and enforce these on the clients as well. Modern and up-to-date web browsers are no longer vulnerable. • In a nutshell, using TLS 1.2 and newer is the best way to go. Verification: • Trying to connect to a server using the TLS 1.0, the server returns the fatal protocol_version error, if not supported, e.g.: $ openssl s_client -tls1 -connect <target>:<port> -msg
...
<<< TLS 1.0, Alert [length 0002], fatal protocol_version
...

• Should a server support the TLS 1.0, it is necessary to prevent the weak cipher suites from being negotiated (by denying them in service configuration), such as the following:
ValueDescription (IANA)OpenSSL
0x00, 0x35TLS_RSA_WITH_AES_256_CBC_SHAAES256-SHA
0x00, 0x2fTLS_RSA_WITH_AES_128_CBC_SHAAES128-SHA

#### 2012: Compression Ratio Info-leak Made Easy (CRIME)

Vulnerability: CVE-2012-4929

• The TLS 1.2 and older enable encryption of compressed data without properly obfuscating the length of the unencrypted data.
• As a result, MitM attackers can obtain HTTP headers in plaintext (i.e. unencrypted) by observing length differences during a series of guesses, in which a string in an HTTP request potentially matches an unknown string in an HTTP header.
• The vulnerability is based on side-channel attack, a compression oracle attack to be more precise, where the cookies can be exploited for identity theft using XSS, Cross Domain Requests etc.

Solution:

• Deny TLS compression (which is different from HTTP compression!) on servers as well as clients.
• Patch and update all SW products (e.g. web servers and web browsers).

Verification:

• Trying to connect to a properly configured server, the response is as follows:
$openssl s_client -connect <target>:<port> -msg ... Compression: NONE Expansion: NONE ...  • Otherwise, the server returns the name of the library used for compression algorithms, e.g. zlib compression: Practical exploitation (for demonstration purposes only!) using an arbitrary scripting program, which can be easily modified for particular server/application purposes: 1. Analysis of obtained “HTTP Cookies” and selection of one. 2. Trying the first character of the selected “HTTP Cookie”, waiting for server reply and comparison of both. 3. Most probably, the length of replies to correct characters will differ from those to incorrect characters (longer replies). 4. Progressively, the whole “HTTP Cookie” value can be acquired. #### 2012: Timing Info-leak Made Easy (TIME) Vulnerability: No registered CVE available • Another side-channel attack which addresses the two major practical drawbacks of the CRIME attack, i.e.: 1. Sole aim at HTTP requests. 2. Requirement to control the PT and to be able to intercept the encrypted messages using MitM attack. • Attackers only needs to control the PT, theoretically allowing any malicious site to launch a TIME attack against its innocent visitors, i.e. to break the SSL/TLS encryption or the SOP. Solution: • Same to the CRIME vulnerability, deny the SSL/TLS compression on all servers and clients. • HTTP-based web apps, which prevent the Cross-Site Request Forgery (CSRF) attacks using tokens, should ensure perfect randomness of the tokens. • Adding random delays to decryption seems to be a nice method to decrease the overall success of this attack. However, it is not 100% perfect. Applications should take care about feedback taken from user responses. • Unfortunately, the best practices as well as the recommendations provided by the RFC 7525 are not sufficient. Verification (two phases to detect the): 1. SSL/TLS compression enabled (the same as with CRIME). 2. Instead of comparison of returned values (as with CRIME), the server response times are analysed by the client. In order to minimise the influence of the Round Trip Time (RTT), i.e. the delay it takes a message to travel back and forth from a client to a server and back, it is useful to retry the attempt approximately 10x followed by an appropriate statistical analysis. #### 2013: Lucky Thirteen (Lucky 13) Vulnerability: CVE-2013-0169: • Focussed on the TLS 1.1 and 1.2, which are not designed and protected against side-channel attacks (the same as with TIME). • Using specially crafted requests and statistical analysis of received data, the attackers can obtain unauthorised access to the message PT. • It is based on deliberate modification of CBC padding, since the time needed for MAC verification is a bit longer for modified padding than the correct one. • Performing this attack is not simple, as the results are affected by network latency. Therefore, multiple similar requests need to be executed and statistically analysed. Solution: • Usage of Authenticated Encryption modes (i.e. not using the CBC). However, these modes were not widely adopted at the time this vulnerability was disclosed. • Generally, adding a random delay into the responses decreases the success of statistical analysis. However, it was later shown that using the uniform distribution is also inefficient (see Lucky Microseconds). • At the time of disclosing the vulnerability, it was recommended to use the RC4 instead of the CBC. However, this recommendation rendered wrong very soon (see ARCFOUR). Verification: • It is possible to verify the vulnerability using the testssl.sh script. #### 2013: Rivest Cipher (ARCFOUR, RC4) Vulnerability: CVE-2013-2566 and CVE-2015-2808 • The RC4 is a stream cipher designed in 1987 and whose co-author is Ron Rivest. • Ron Rivest is also a co-author of the RSA, RCx, MDx and other algorithms and did not win the AES selection process (to replace the DES) with the RC6 algorithm (Rijndael won). • The RC4 was very popular for its simplicity and efficiency. Therefore, it was used as a secure mechanism used in wireless networks known as Wired Equivalent Privacy (WEP). • In 2001, several vulnerabilities were found and disclosed: • The first is based on the usage of huge amount of weak keys during the Key Scheduling Algorithm (KSA) denoted as Invariance Weakness. • Another vulnerability is derived from the first one, where the weak keys are used as an input for a Pseudo-random generation algorithm (PRGA). • The second vulnerability is based on usage of weak IVs, denoted as the IV weakness. • CVE-2013-2566 • The RC4 (the same as the CBC) susceptible to statistical analysis. • As a result, a plaintext-recovery attack of CT is possible in a large number of sessions, which use the same PT. • CVE-2015-2808 • Also denoted as the Bar Mitzvah, since the Invariance Weakness had been known for 13 years at the time of disclosure (the same as the known Jewish ritual for boys). • The principle is very similar to the one used in BEAST. • During the initial phase, the state and key data is not properly combined. Therefore, it is possible to conduct a plaintext-recovery attack against the initial 100B of a stream (requires a MitM attack possibility). Solution: • Not to support RC4-based cipher suites and algorithms. • See RFC 7465 for more details. Verification: • If a server and client do not agree upon using an RC4-based cipher suite, the similar error occurs (depends on the operating system used): $ openssl s_client -cipher RC4 -connect <target>:<port> -msg
...
140355035514528:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:s23_clnt.c:770:
...

• A securely configured client returns the following error:
$openssl s_client -cipher RC4 -connect <target>:<port> -msg Error with command: "-cipher RC4" 108509023008000:error:1410D0B9:SSL routines:SSL_CTX_set_cipher_list:no cipher match:ssl/ssl_lib.c:2558:  • Otherwise, the following details can be observed (an example): • The negotiated cipher suite: New, TLSv1/SSLv3, Cipher is ECDHE-RSA-RC4-SHA • The selected cipher: Cipher : ECDHE-RSA-RC4-SHA. #### 2013: Browser Reconnaissance & Exfiltration via Adaptive Compression of Hypertext (BREACH) Vulnerability: CVE-2013-3587 • Exploits HTTP compression (not the TLS compression as with CRIME). • However, it is a variant of the CRIME vulnerability, which works regardless of negotiated cipher suite. • Using the compression oracle attack, an initial brute-force search is performed to guess the first couple of bytes, which is followed by the divide & conquer search (multi-branched recursion) to expand a correct guess to an arbitrarily large amount of content. • In order to succeed, the target server has to support HTTP compression and respond with user inputs with secret keys (e.g. a CSRF token). Solution: • Deny the usage of HTTP compression on a server. Yet in the time of vulnerability disclosure, it may have affected server performance (and thus business). • Module ban (In current configurations, the affected modules are disabled by default): • In Apache configuration, the mod_deflate. • In Nginx configuration, the gzip module, etc. • Other methods are very complex, despite the fact that it is possible to perform a token based CSRF defense, HTTP referer checks, HTTP header field obfuscation (using random padding added into responses), separation of user input from passwords, limiting the server response time etc. Verification • It is possible using the following script, which is based on bash and the curl program. • The script does not return anything, if the target server does not support HTTP compression (desirable and correct setup): $ target=URL-OF-TARGET\
$for compression in compress deflate exi gzip identity pack200-gzip br bzip2 lzma peerdist sdch xpress xz; do\ curl -ksI -H "Accept-Encoding:${compression}" https://${target} | grep -i${compression}\
done


#### 2014: Heartbleed

Vulnerability: CVE-2014-0160

• Obsolete and deprecated versions of SSL/TLS libraries incorrectly implement TLS extensions denoted as the Heartbeat (see the RFC 6520 for more details), which provides a keepalive function without the need of renegotiation. In a nutshell, one of the two communicating parties sends a message to the other and once replied, the mutual availability is confirmed.
• The impact was on both the TLS and the DTLS, i.e. d1_both.c (replaced) and t1_lib.c (corrected).
• The Heartbeat Extension packets can be exploited as follows:
• Remote attackers can obtain sensitive information from process memory via crafted packets that trigger a buffer over-read attack.
• The attack is enhanced, as the sensitive information can be associated with a different process running on the same server.
• The affected software libraries did not verify the real message length. They trusted the information shared within the client request instead. A 20kB message, which stated it was 40kB long, resulted into 40kB of memory allocated. The reply contained not only 20kB, but also the additional 20kB of allocated memory.
• AS a result of this vulnerability, several alternatives to the OpenSSL library emerged, such as:
• LibreSSL was designed by the OpenBSD developers in April 2014 as a fork of OpenSSL 1.0.1g. More than 90000 rows of obsolete source code were removed during the first week of development.
• BoringSSL was designed by Google developers in May 2014.
• A comprehensive comparison can be found, for instance, on Wikipedia.org.

Solution:

• SSL/TLS library upgrade to OpenSSL 1.0.1g or newer.
• Usage of an alternative, such as LibreSSL, BoringSSL etc. if and only if the operating system and application supports it.
• The older versions of OpenSSL needs to be patched by recompilation with the Heartbeat support switched off (-DOPENSSL_NO_HEARTBEATS).

Verification:

• For instance, using the nmap command as follows (example of a vulnerable service):
$nmap --script ssl-heartbleed <target> -p <port> ... PORT STATE SERVICE 443/tcp open https | ssl-heartbleed: | VULNERABLE: | The Heartbleed Bug is a serious vulnerability ... | State: VULNERABLE | Risk factor: High ...  • Or for a “healthy” target as follows: $ nmap --script ssl-heartbleed <target> -p <port>
...
PORT STATE SERVICE
443/tcp open https

Nmap done: 1 IP address (1 host up) scanned in 0.87 seconds


#### 2014: BERserk

Vulnerability: CVE-2014-1568

• The Network Security Services (NSS) library designed by Mozilla, which was used by Firefox, Seamonkey, Thunderbird, Google Chrome etc. became an attack target, which was only a variant of Bleichenbacher’s attack from 2006 and which exploits ASN.1 coding error to obfuscate a spoofed information.
• A website with links is only available via web archive today.
• The principle is as follows:
• The attacker can spoof RSA digests using a MitM attack without knowledge of the corresponding private key.
• The attack exploits a signature verification error, which occurs during processing of messages encoded in the ASN.1 abstract language.
• Following the ITU-T X.690, some ASN.1 message parts (objects), e.g. DigestInfo, are encoded using the Basic Encoding Rules (BER) or Distinguished Encoding Rules (DER) – the reason to name this vulnerability (and play on words).
• The signing (hash) process requires each message block to be completed using an appropriate amount of 0xFF padding bytes (a block operation), which are followed by the 0x00 separator byte. The vulnerable versions only searched for the 0xFF 0x00 sequence without proper verification of the padding length.
• As a result, it was possible to inject additional information (garbage) into the messages in a way to contain the correct RSA signature.

Solution:

• Upgrade (or patch if possible) the client’s software.

#### 2014: (Early) CCS Injection

Vulnerability: CVE-2014-0224

• The vulnerable OpenSSL versions incorrectly processed the ChangeCipherSpec (CCS) messages and thereby, enabled a MitM attack using which it was possible to set up the Master Secret with a null length and consequently, steal the session or obtain sensitive information.
• The whole TLS Handshake can be compromised by injecting specially crafted CCS messages, which are sent in both directions (to a server and to a client) in order to use a zero length premaster secret key based on which, all other Session Keys are derived.

Solution:

• Upgrade to an appropriate SSL/TLS library, e.g. OpenSSL 1.0.1h and newer.

Verification

$nmap --script ssl-ccs-injection <target> -p <port> ... PORT STATE SERVICE VERSION 443/tcp open ssl/http ... | ssl-ccs-injection: | VULNERABLE: | SSL/TLS MITM vulnerability (CCS Injection) | State: VULNERABLE | Risk factor: High ...  • A vulnerable server accepts the message in silence. Otherwise, it replies with an UNEXPECTED_MESSAGE error, and that is what the script waits for. #### 2014: Padding Oracle On Downgraded Legacy Encryption (POODLE) Vulnerability: CVE-2014-3566 • The vulnerable OpenSSL versions incorrectly utilised non-deterministic CBC padding with the SSL 3.0, which enabled MitM attacks and obtaining PT using the padding oracle attack, since the protocol signalised padding errors differently from the MAC errors. • When combined with an appropriate downgrade protocol attack (e.g. from the TLS to the SSL), the weakness is in the CBC padding. Solution: • Completely disable support of SSL 3.0, which was critical at the time of vulnerability disclosure, as TLS 1.0 was not widely adopted by the clients. • In order to prevent the downgrade attack, a Signaling Cipher Suite was designed and its TLS Fallback Signaling Cipher Suite Value (SCSV) or TLS_FALLBACK_SCSV (see the RFC 7507), which is sent on the Client Hello message in cases where the client requests the protocol downgrade due to interoperability problems. • It is suggested to revise a possible affect on the TLS as well (see TLS-POODLE). • Upgrade to an appropriate SSL/TLS library, e.g. OpenSSL 1.0.1i and newer. Verification: $ nmap -sV --version-light --script ssl-poodle <target> -p <port>
...
PORT    STATE SERVICE  VERSION
443/tcp open  ssl/http ...
| ssl-poodle:
|   VULNERABLE:
|   SSL POODLE information leak
|     State: VULNERABLE
|     IDs: ...
...

• Or for a “healthy” target as follows:
$nmap --script ssl-heartbleed <target> -p <port> ... PORT STATE SERVICE VERSION 443/tcp open ssl/http ... Service detection performed. Please report any incorrect results at https://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 12.81 seconds  • It is also possible to detect the SSL 3.0 support using the openssl command (returns an unknown option error if not supported): $ openssl s_client -ssl3 -connect <target>:<port> -msg
s_client: Option unknown option -ssl3
s_client: Use -help for summary.

• Or using the following command, which tests the TLS_FALLBACK_SCSV availability (returns a fatal protocol_version error if TLS 1.0 is not supported):
$openssl s_client -tls1 -fallback_scsv -connect <target>:<port> -msg ... <<< TLS 1.0, Alert [length 0002], fatal protocol_version ...  #### 2014: Padding Oracle On Downgraded Legacy Encryption (POODLE attack against TLS) Vulnerability: CVE-2014-8730 • A POODLE variant (the same padding issue) but this time, for the TLS protocol (versions 1.0 to 1.2). • At the time the vulnerability was disclosed, some of the TLS libraries (e.g. F5, Cisco Systems etc.) failed to verify the padding length the same way as with previous SSL 3.0 issues. • Simply disabling the SSL was not an option. Solution: • Upgrade to an appropriate SSL/TLS library, e.g. OpenSSL 1.0.1j and newer. Verification: $ nmap -sV --version-light --script ssl-poodle <target> -p <port>


#### 2015: Factoring RSA Export Keys (FREAK)

Vulnerability: CVE-2015-0204

• A problem when a vulnerable client (e.g. a web browser) connects to an improperly set up server, which accepts the export-grade encryption algorithms. From the USA perspective, these are algorithms that the NSA can easily break (as part of the SIGINT), as the cipher suites are deliberately weakened. Several examples are as follows:
ValueDescription (IANA)OpenSSL
0x00, 0x03TLS_RSA_EXPORT_WITH_RC4_40_MD5EXP-RC4-MD5
0x00, 0x06TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5EXP-RC2-CBC-MD5
0x00, 0x08TLS_RSA_EXPORT_WITH_DES40_CBC_SHAEXP-DES-CBC-SHA
0x00, 0x14TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHAEXP-EDH-RSA-DES-CBC-SHA
• In an obsolete OpenSSL version, the problem is specifically with the ssl3_get_key_exchange function (as part of a today-removed s3_clnt.c file), which enabled RSA-to-EXPORT_RSA (a downgrade attack) followed by a brute-force attack, based on which it was possible to obtain the PT.

Vulnerability: CVE-2015-1637 (Microsoft SChannel)

Vulnerability: CVE-2015-1067 (Apple Secure Transport)

• Solutions provided for iOS 8 as well as OS X, which was current at that time.

Solution:

• Disabling support of export-grade encryption algorithms.
• Enforcing support of perfect forward secrecy (PFS), which protects past sessions against future compromises of secret keys or passwords by generating unique session keys for every session users initiate (and vice versa).
• During the Diffie-Hellman (DH) key exchange, an ephemeral session key is typically exchanged and valid only for the sole purpose of the DH.
• Within the TLS, the following cipher suites are involved: DHE-RSA, DHE-DSA and ECDHE-RSA, ECDHE-ECDSA. Within the TLS 1.3, the PFS is provided by the usage of ciphers suites based on the DH.
• Upgrade to an appropriate SSL/TLS library, e.g. OpenSSL 1.0.1k and newer.
• Upgrade of client SW (web browser, operating system etc.)

Verification

• For instance, it is possible to use the following openessl command.
$openssl s_client -cipher EXPORT -connect <target>:<port> -msg  • A vulnerable server accepts the message in silence. Otherwise, responds with an error message. • A securely configured client returns the following error: $ openssl s_client -cipher EXPORT -connect <target>:<port> -msg
Error with command: "-cipher EXPORT"
109528135714048:error:1410D0B9:SSL routines:SSL_CTX_set_cipher_list:no cipher match:ssl/ssl_lib.c:2558:


#### 2015: #OprahSSL

Vulnerability: CVE-2015-1793

• The vulnerable OpenSSL versions (1.0.1n, 1.0.1o, 1.0.2b & 1.0.2c) incorrectly processed the X.509 certificates (see the RFC 5280 for more details).
• The X509_verify_cert function in the crypto/x509/x509_vfy.c file incorrectly processed the cA values of the X.509 Basic Constraints extension during identification of alternative certificate chains. As a result, it was possible to forge the CA role and inadvertently verify a spoofed certificate via a valid leaf certificate.
• In other words, if the first verification attempt failed, the vulnerable library tried to find an alternative trust chain for verification. Attackers could cause certain checks on untrusted certificates to be bypassed (such as the CA flag).
• It was the first vulnerability to have its own social media account.
• The BoringSSL developers (Google) were the first to disclose the vulnerability as well as the first to provide a patch.

Solution:

• Upgrade to an appropriate SSL/TLS library, e.g. OpenSSL 1.0.1p, 1.0.2d and newer.

Verification:

• For instance, the following shell command (bash) can be run directly on a server (only version checking):
$if [[ openssl version|cut -d' ' -f2 =~ ^1.0.1(n|o)|1.0.2(b|c)$ ]]; then\
echo "VULNERABLE";\
else\
echo "NOT vulnerable";\
fi


#### 2015: Logjam (WeakDH)

Vulnerability: CVE-2015-4000

• If the vulnerable version of TLS 1.2 and older is used and if the export-grade cipher suites are enabled (same as with the FREAK vulnerability), a MitM attacker can exploit the incorrectly implemented DHE_EXPORT option and perform a downgrade attack on a selected cipher suite.
• During the TLS Handshake, the value of the selected algorithm can be rewritten by an attacker from DHE to DHE_EXPORT value and back to the DHE value in the ServerHello message.

Solution:

• Strictly disable support of export-grade encryption (on a server).
• On the client side (e.g. web browser): requirement of minimal length of 2048 bits for DH exchange, i.e. usage of 2048-bit MODP group (Group 14) at minimum.
• On the server side: OpenSSL can be used to generate (2048-, 3072- or 4096-bit keys) as follows (the longer the key, the longer the time to generate):
$openssl dhparam -out dhparams.pem <key-length>  Verification: • For instance, it is possible as follows: $ openssl s_client -cipher DHE:EXPORT -connect <target>:<port> -msg
...
<<< TLS 1.3, Alert [length 0002], fatal handshake_failure
...


#### 2015: Lucky Microseconds

Vulnerability: “A Timing Attack on Amazon’s s2n Implementation of TLS

• The s2n is a new open source TLS implementation designed by Amazon in 2015, which was designed as a reaction to the previous OpenSSL errors and which contains approximately 6000 lines of code (when compared the the 70000 lines related to the TLS in the OpenSSL). In an attempt to address the timing attacks (such as the TIME, Lucky 13 etc.), a wrong design of authenticated CBC-mode cipher suites was used, i.e.MAC-then-Encrypt, which does not provide CT integrity and consequently, it is possible to forge the PT, its MAC and encrypt it.
• As a result, CBC-mode cipher suites are vulnerable to timing attacks (similar to those used in Lucky 13). Moreover, it is possible to efficiently deal with random generated delays used for exactly this purpose in Lucky 13.
• The authors demonstrated that the randomised delays that were put in place in s2n as an additional countermeasure to Lucky 13 can be dealt with, and highlighted the challenges of protecting implementations against sophisticated timing attacks.

Solution:

• Not using the s2n. Impossible to enforce this requirement on Amazon.
• Disabling the CBC-mode cipher suites.

Verification:

#### 2016: Decrypting RSA with Obsolete and Weakened eNcryption (DROWN)

Vulnerability: CVE-2016-0800CVE-2016-0703, CVE-2016-0704 and others

• The first problem was that the SSL 2.0, which was supported by an obsolete version of OpenSSL (and other products), requested that a server replied with a ServerVerify message to check that the client possesses specific RSA data in PT, which simplified the attackers work to decrypt the CT using Bleichenbacher’s padding oracle attack.
• The second problem was in the get_client_master_key function in the today’s non-exiting s2_srvr.c file, which accepted a non-zero value of CLIENT_MASTER_KEY CLEAR-KEY-LENGTH, which resulted in the possibility of a MitM attack, determination of the MASTER-KEY value and obtaining the PT using Bleichenbacher’s attack.
• Protection applied against the previous vulnerability rendered useless, as in case of usage of export-grade encryption, only the MASTER-KEY got overwritten and the problem was not solved at all.
• In an attempt to prevent this brute-force attack, a series of patches was issued instead of banning the RSA as a key exchange algorithm completely.
• It is very likely that the total amount of variants of this attack will continue to increase. The last known vulnerabilities are as follows: CVE-2018-12404, CVE-2018-19608, CVE-2018-16868, CVE-2018-16869 and CVE-2018-16870.

Solution:

• Upgrade to an appropriate SSL/TLS library, e.g. OpenSSL 1.0.1s and 1.0.2g or newer.
• Strictly disable SSL 2.0 support.
• Strictly disable support for RSA as key exchange algorithm.

Verification:

• For instance, it is possible as follows (returns an error if the SSL 2.0 is not supported):
$openssl s_client -ssl2 -connect <target>:<port> -msg  • A securely configured client returns the following error: $ openssl s_client -ssl2 -connect <target>:<port> -msg
s_client: Option unknown option -ssl2
s_client: Use -help for summary.

$nmap -sV --script=sslv2-drown <target> -p <port> ... PORT STATE SERVICE VERSION 443/tcp open ssl/http ... |_sslv2-drown: ...  #### 2016: Sweet32 Vulnerability: CVE-2016-2183 and CVE-2016-6329 • Lucifer and encryption designed by the IBM and later selected as the Data Encryption Standard (DES) is based on block cipher (including the Triple DES), which is in obsolete versions of the TLS, SSH, IPsec and OpenVPN used in the CBC-mode that is vulnerable to the birthday attack. • It was shown that after capturing data of sufficiently long sessions, secure HTTP cookies can be obtained. • From the complexity perspective, the attack is very similar to the RC4 attack. Solution: • Upgrade to an appropriate SSL/TLS library, e.g. OpenSSL 1.0.1u and 1.0.2i or newer. • Strictly disable support of DES, 3DES (64-bit blocks) and Blowfish (32-bit blocks). In other words, disable using obsolete and weak 64-bit block algorithms (min. acceptable key length is 128 bits). • Alternatively, changing session keys very often (such as with OpenVPN, using the reneg-bytes 64000000 parameter). Verification: • For instance, it is possible as follows using the openssl command (returns an error if the DES, 3DES or Blowfish are not supported): $ openssl s_client -cipher DES -connect <target>:<port> -msg
$openssl s_client -cipher 3DES -connect <target>:<port> -msg$ openssl s_client -cipher Blowfish -connect <target>:<port> -msg

• A securely configured client returns the following error (e.g. for the DES and the same counts for the other ciphers):
$openssl s_client -cipher DES -connect <target>:<port> -msg Error with command: "-cipher DES" 105822496478464:error:1410D0B9:SSL routines:SSL_CTX_set_cipher_list:no cipher match:ssl/ssl_lib.c:2558:  #### 2016: Don’t Use Hard-coded Key (DUHK) Vulnerability: CVE-2016-8492: • Devices, which use the NIST-approved ANSI X9.31 Random Number Generator (RNG) in combination with hard-coded seed key, are vulnerable, as the attacker can disclose the key and get access to the PT. • The problem is based on an obsolete method to generate random numbers, which is based on a timestamp and a combination of a block cipher with hardwired key. • If attacker have access to the source code or a compiled binary, they can reveal and exploit the keys (e.g. in FortiGate). • The authors of the vulnerability discovered that additionally, FortiOS used a linux kernel version 2.4.37, which was updated in 2008 for the last time and since 2011, has been denoted as End-of-Life. • The problem is not related to the TLS protocol only, but also IPsec. Furthermore, it is not only related to Fortinet appliances, but Cisco, Techguard and others who used the original FIPS-approved RNG methods, which were retired and replaced by new algorithms not sooner than in January 2016. Solution: • Upgrade of the affected SW equipment that lacks the hardwired keys. • According to the NIST SP 800-90, the RNG needs to be replaced by Deterministic Random Bit Generators (DRBG) either CTR_DRBG or Dual_EC_DRBG. The second option, which is based on on elliptic curves, is controversial as suspected of integrated NSA backdoor, as it contains a bunch of constants and has been championed by the NSA since 2006. Verification: • Theoretically possible only using reverse engineering of the appropriate firmware and finding another hardwired values. #### 2017: Return Of Bleichenbacher’s Oracle Threat (ROBOT) Vulnerability: CVE-2017-6168, but there are more (according to the affected manufacturer or service provider). • Another variant of several years old known Bleichenbacher attack (see CCA2 or DROWN), using which can attackers obtain access to PT if a server performs encryption/decryption methods using a private RSA key. • It can be partially mitigated using the PFS (see FREAK). However, MitM attackers can dump the whole client-server communication and decrypt it later (PKCS #1 v1.5 padding issue). • During the RSA key exchange (as part of the TLS Handshake), a server reveals information whether the information was sent in an appropriate format by the client, which enables the attacker to either decrypt the previous TLS session or impersonate the server alone. • At the time of disclosure, vulnerable implementations were identified from vendors, such as Cisco, Citrix, F5, Fortinet, IBM, Radware, Symantec and others. Solution: • Strictly disable support for RSA as key exchange algorithm, i.e. all cipher suites starting with TLS_RSA (according to IANA). Several examples are as follows: ValueDescription (IANA)OpenSSL 0x00, 0x2FTLS_RSA_WITH_AES_128_CBC_SHAAES128-SHA 0x00, 0x35TLS_RSA_WITH_AES_256_CBC_SHAAES256-SHA 0x00, 0x3CTLS_RSA_WITH_AES_128_CBC_SHA256AES128-SHA256 0x00, 0x3DTLS_RSA_WITH_AES_256_CBC_SHA256AES256-SHA256 0x00, 0x9CTLS_RSA_WITH_AES_128_GCM_SHA256AES128-GCM-SHA256 0x00, 0x9DTLS_RSA_WITH_AES_256_GCM_SHA384AES256-GCM-SHA384 • Algorithms, which utilise the RSA digests in combination with the DHE and ECDHE, are unaffected by the ROBOT attack (i.e. those that starts with TLS_DHE_RSA or TLS_ECDHE_RSA). • It is exclusively a server side problem. Clients (web browsers etc.) cannot do anything to prevent it. Verification: • Using manual attempts and trying to negotiate a TLS session using selected cipher suites, e.g. using: openssl s_client -cipher <SELECTED-CIPHER>. • Using an automated Python script. • Alternatively, using an online test provided by Qualys. #### 2017: The Return of Coppersmith’s Attack (ROCA) Vulnerability: CVE-2017-15361 • This vulnerability enables attackers to acquire private key from public key if and only if the pair was generated using an affected device, which uses an obsolete RSALib (Infineon Technologies AG) to generate RSA key-pairs. • The Coppersmith’s attack exploits an inappropriate exponent value (insufficiently large number), which accelerates and makes the whole generation process efficient on one side, but enables the attackers to solve the prime decomposition (or integer factorization) problem on the other side to get the possibility to derive the private key from the corresponding public key. • For primality test, the affected RSALib used a formula, which generated biased results (fingerprint) and which could be revealed. • The following are examples of the affected technologies: BitLocker with TPM 1.2, YubiKey (prior 4.3.5) and Cached User Data encryption functions in Chrome OS. • Qualified digital certificates issued for private keys used on Slovak electronic identity cards had to be revoked in 2017 due to this vulnerability, and similar issues had to be solve in Spain and Estonia. Solution: • Avoidance of usage of the cheapest random number generators “at all costs” (such as in case of smart cards). • Avoidance of attempts of increasing the efficiency and optimisation of the key-pair generation process “at all costs”. • Generation of the RSA moduli truly randomly, in order to prevent successful guesses and derivatives of the next prime (it is insufficient to only generate “strong” primes). Verification: $ nmap -sV --script rsa-vuln-roca <target> -p <port>
...


#### 2018: ARM mbed TLS

Vulnerability: CVE-2018-0488

• A vulnerability of an obsolete mbed TLS library (originally PolarSSL), which is used in embedded devices.
• The activated extension called the truncated HMAC can be exploited when combined with CBC mode, which enabled remote attackers to execute arbitrary code using crafted TLS and DTLS messages.
• Remarkably, the mbed TLS is not used in embedded devices using the ARM architecture. However, it is used by OpenVPN, Nginx, commercial products from Linksys, Gemalto, PowerDNS etc.

Solution:

• Upgrade to an up-to-date SSL/TLS library version of the appropriate development branch, i.e.: 1.3.22, 2.1.10, 2.7.0 and newer.
• If the compilation did not use the MBEDTLS_SSL_TRUNCATED_HMAC flag, it is unaffected by this vulnerability.

#### 2018: Jenkins vSphere Plugin

Vulnerability: CVE-2018-1000151

• An MitM vulnerability in Jenkins vSphere Plugin (VSphere.java) SW, which enables to disable SSL/TLS certificate verification.
• When combined with CVE-2018-1000152 and CVE-2018-1000153, the attacke can be enhanced with a CSRF and obtain login information or cause a DoS attack.

Solution:

• Upgrade to an up-to-date SSL/TLS library version 2.16 and newer.

#### 2019: Further Attacks on TLS

The recent TLS Padding Oracles study reveals that the SSL/TLS protocols and all of their technical aspects will be tested in various ways. In relationship to the CBC mode, the following variants were presented in 2019:

• Zombie POODLE – incorrect padding with a valid MAC.
• GOLDENDOODLE – correct padding with an incorrect MAC.
• 0-Length OpenSSL – correct padding with and invalid MAC, with the Length field equal to zero.
• Sleeping POODLE – incorrect padding with correct MAC.

Published CVE:

Solutions:

• The authors suggest to avoid usage of the CBC completely and fully adopt and deploy TLS 1.3.

Verification:

### Testing Tools

Generally speaking, the testing of the particular vulnerabilities and supported cipher suites can be performed as follows:

• Manually, e.g.:
• Using the openssl command.
• Using the nmap command.
• Automatically, e.g.:

The Internet is full of manuals and hints, such as the Doing your own SSL/TLS testing.

### Protecting the Client

Generally speaking, an updated web browser is a best practice to provide adequate protection to the user, as it does not allow the usage of obsolete algorithms by default. However, particular browsers can be additionally configured to further fine-tune the setup provided by the manufacturers.

Considering the Bar Mitzvah attack, modern and up-to-date browser will protect users by not providing the RC4-based cipher suites support. Considering an outdated browser as an example, the attack can be prevented manually by disabling all RC4-based cipher suites as follows.

#### Google Chrome and Opera

It is possible to execute the browser with a parameter to disable support of specific cipher suites as follows (e.g. the RC4):

\$ chrome -cipher-suite-blacklist=0x0005,0x0004,0x002f,0xc012,0xc011,0x003c,0xc011,0x0032,0xc007,0xc00c


#### Mozilla Firefox

In a running browser instance, the following steps need to be followed in order to disable a particular cipher suite:

• Opening the: about:config in the address bar.
• Searching for a particular cipher suite, e.g. RC4 (for some reason, the latest version denotes the algorithms with the following prefix regardless the protocol: security.ssl3).
• The selected option can be disabled.

#### Microsoft Internet Explorer

Naturally for the Microsoft-based environment, the configuration of the Internet Explorer can be found in the Windows Registry. Considering the RC4, it can be disabled using the option Enabled (type REG_DWORD) by setting it to 00000000 in the following locations:

• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4128/128
• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC440/128
• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC456/128
• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC464/128

### Conclusion

Support of obsolete algorithms and protocols provides maximum variability and interoperability. However, it also increases attack surface and security risk. From the configuration perspective, the most easiest and safest is to strictly support the TLS 1.3 only. However, it also increases operational and business risks, which are strongly tight with possible incompatibility with communicating parties that have not adopted this version yet. Therefore, as an optimal solution, it seems to use a compromise of supporting also the TLS 1.2 with carefully selected cipher suites to increase compatibility (see Transport Layer Security Hardening).

Either strict or optimal cipher suite setup does not solve all TLS-related issues which are bound to the public key infrastructure (PKI). For the purpose of TLS certificate revocation, the following methods are designed:

• Certificate Revocation Lists (CRL), see the RFC 5280.
• Online Certificate Status Protocol (OCSP), see the RFC 6960.

Browsers usually implement the “soft-fail” approach to OCSP checks, where a revoked certificate will be regarded as valid if the OCSP request fails. A “hard-fail” approach would not allow paid WiFi hotspots or hotel captive portals to work, as the OCSP responder used by the site’s certificate could not be used before the user was authenticated. OCSP stapling combined with the must-staple extension (see the RFC 6066 and the RFC 6961) is one of the methods to deal with the aforementioned chicken-egg problem. Although the principle is simple, i.e. browsers have to request OCSP responses in the TLS handshake and provide the complete certificate chain, which eliminates the need of clients to contact the CA directly. However, it is unlikely to be adopted quickly. More info on blog.apnic.net or scotthelme.co.uk.