TLS Flashcards

Question

TLS and PKI: when is it needed?

Answer 1

TLS uses X.509 certficates surely for the server and optionally for the client. This means that certificates (and the chains) have to be validated. This meands that a PKI is used.

Answer 2

CRL: long look-up, big size OCSP: privacy problem

Answer 3

* TLS * OCSP

Answer 4

Some browsers already include the list of some revoked certificates of intermediated compromised CAs.

Answer 5

It is a good solution to use the OCSP framework in order to validate certificates without having privacy problems because the OCSP response is stapled with the certificate. **TLS** provides the **Certificate Status Request extension** and the client may use it to request that the erver certificate is sent with the relative OCSP response. The server, seeing it, may respon with the OCSP response too, but it could also ignore it. There is a strongest version of OCSP Stapling that is the OCSP Must Stapling: - the server certificate is issued with the indication that it will always have to provide the OCSP response - the **server that receives a CSR MUST respond with the OCSP response** too - the client that uses the CSR extension and that receives a certificate without eh OCSP response should reject the certificate

Answer 6

The `TLSFeatures` certificate extension (for OCSP Must Stapling) prevents the following attack: * Server S sends to the client C, along with X.509+ certificate, the OCSP response; * An attacker compromises the private key and then sets up a (fake) server S’, forces C to connect to S’ (e.g., with DNS cache poisoning) and sends to C an X.509+ certificate signed with the compromised key; ∗ the attacker doesn’t send any OCSP response since that would tell the client that the private key of S has been compromised; ∗ OCSP responses cannot be faked because they’re digitally signed by the OCSP server (unless the attacker compromises the OCSP server’s private key too...); * However...**the attack can still be successful if the client doesn’t support OCSP Must Staple, since it will ignore the X.509 extension (because it’s unable to understand it);**

Answer 7

It exploits the TLS/DTLS heartbeat extension. Since the handshake process is time-consuming (even when a session is reused) due to frequent channel closures and re-openings, this extension was introduced to keep the channel alive for optimal performance, even if there is no data to exchange. Heartbeat messages are periodically sent to avoid closing the channel. These messages are also useful for Path-MTU discovery, which is especially important in IPv6. The related vulnerability is an OpenSSL bug known as a buffer over-read. Through this vulnerability, the TLS server sends back more data (up to 64KB) than specified in the heartbeat request, allowing an attacker to retrieve sensitive data stored in RAM, such as usernames, passwords, or the server’s private key (if not using HSM). This occurs because an attacker can send a specially crafted heartbeat message with a fake length field, claiming to send more data than is actually provided. Despite the discrepancy between the actual data size and the claimed size, the server trusts the length specified in the message, **responding with a block of data equal to the claimed size**. This response includes adjacent memory content beyond the intended data, exposing potentially sensitive information.

Answer 8

Bleichenbacher performed the "million-message attack", discovering a vulnerability in the way RSA encryption was implemented in TLS, particularly when encrypting the pre-master secret with the server’s public key. The attacker can exploit this vulnerability by sending a large number of specially crafted messages, typically around a million, and observing the **differences in error codes returned by the server**. This allows the attacker to perform a **private key operation without knowing the private key** itself, effectively **enabling the decryption of the pre-master secret and the ability to sniff traffic**. Over the years, this attack has been refined and, in some cases, now requires only thousands of messages. In 2017, a variant of Bleichenbacher’s attack, known as ROBOT (Return of Bleichenbacher’s Oracle Threat), was found to affect major websites, including Facebook. This vulnerability persists even when a hardware security module (HSM) is used, because the issue does not stem from the ability to read the private key, but rather from the possibility of performing computations without knowledge of the key.

Answer 9

An attack in which the **attacker injects chosen plaintext into user requests and measures the size of the resulting encrypted traffic**. By doing so, **the attacker can recover specific parts of the plaintext by exploiting information leaked through compression**. This shows the importance of disabling **compression in SSL/TLS protocols**. **Compression works by replacing similar segments with a common element, and an attacker can inject additional text before TLS encryption and observe the traffic to guess secrets like passwords based on the message size.**

Answer 10

This attack exploits HTTP compression in responses provided by servers. It targets secrets, such as CSRF tokens, tickets, or cookies, embedded within HTTP responses. By inserting user input into the response, the attacker can **deduce the secret by observing changes in the compressed data size**.

Answer 11

Targeted SSL channels using CBC (Cipher Block Chaining) with IV concatenation. A man-in-the-middle (MITM) attacker could exploit a **blockwise-adaptive chosen-plaintext attack** to **decrypt HTTP headers**, potentially stealing **session cookies** and other sensitive data.

Answer 12

A MITM attack that exploits SSL-3 fallback mechanisms to decrypt data. In December 2014, a variant of POODLE was discovered that targeted CBC errors in TLS-1.0 and TLS-1.1, making it possible to exploit even when SSL-3 is disabled.

Answer 13

With the FREAK (Factoring RSA Export Keys) an attacker can downgrade the RSA keys to export-level (512-bit), enabling the factorization of the key and channel decryption. Alternatively, the attacker can downgrade to export-level symmetric keys (40-bit) and use brute force to crack the key. As a result of these vulnerabilities, SSL-3 has been disabled on most browsers (e.g., since Firefox ver- sion 34) or can be disabled by configuration. This attack is performed by an **active MITM**: 1. The client sends the “client hello” message with the client random, the list of supported ciphers and the list of supported curves (for elliptic curves criptography); 2. The MITM modifies the list of supported ciphers by **leaving the export cipher as the only supported cipher**; 3. If the server is configured to still support the export cipher, it will agree to use it and it will reply with a “server hello” message that contains the export cipher; 4. The client, even if it supports stronger algorithms, thinks that the server only supports the export cipher and so it generates a **weak shared key (pre-master secret) of 40 bit only**; 5. At the end of the handshake, the client sends the “finished” message, i.e., the HMAC of all previous messages computed with the weak shared key; 6. The MITM must be really fast to **brute force the key in order to modify the “finished” message sent by the client**, because such message contains the whole list of supported ciphers but the server received a list with only the export cipher! If the MITM succeeds in recomputing the HMAC with the modified “client hello” message (with just the export cipher), there won’t be a mismatch between the HMAC computed by the server and the (modified) HMAC sent by the client; The weak key brute force consists in trying all **240 possible pre-master secrets**. Each “tested” pre-master secret is used to **compute the corresponding master secret** (because the attacker is assumed to know client and server randoms) which is then **used to derive the key for MAC computation**. 7. Since the MITM has never modified any message sent from the server to the client, the HMAC computed by the client on the messages received from the server will simply match the HMAC sent by the server in the “finished” message; 8. From now on, all traffic is encrypted with the weak shared keys and the MITM can read or modify all messages between client and server;

TLS Flashcards

(37 cards)