TLS

Question 1

Which security properties can TLS provide?

Answer 1

It provides:
- server authN wth implicit asymmetric challenge response
- client authN (optional) with explcit asymm CR
- data integrity and data authN
- protection from replay and filtering attacks thanks to TCP and implicit sequence number

Question 2

TLS architecture

Answer 2

TLS lays over TCP and uses the TLS Record Protocol to encapsulate application data.
The Record Protocol is used by:
- TLS handshake protocol: to negotiate crypto parameter
- TLS alert protocol: to send alertss about an error during the connection (ex. wrong MAC value)
- TLS change cipher spec: to start protecting the exchanged messages with the negotiated crypto parameters

Question 3

Are the finished messages and the change cipher spec protocol the same?

Answer 3

No.
The Change Cipher Spec Protocol is used to change keys or algorithms without closing the channel. This is crucial because, after transferring a significant amount of data with the same algorithm and key (e.g., for encryption), the attacker has more opportunities to perform cryptanalysis. The more data that is encrypted with the same cipher-key pair, the higher the probability of determining the key. This protocol allows the system manager to change the keys after a certain amount of time or data exchanged, without closing the channel. It is also used at the beginning to transition the channel from unprotected to protected.

• finished: to authN the handshake -> the finished message is a MAC computed using the master secret and it is computed over all the messages exchanged before -> the finisched of the client and of the server will be different cause the server computes it considering also the client’s finished. It does not consider the change cipher spec.

Question 4

How does the alert protocol work?

Answer 4

The Alert Protocol is used whenever there is an issue. When an alert record is sent then the connection is closed.

Question 5

Sessions and connections in TLS

Answer 5

Session
It is a logical association between a client and a server which is created during the TLS Handshake.
Multiple connections can be associated to the same session and use the cryptographic parameters negotiated during the handshake.

Connection
It is a transient channel which is part of a session and it is between a server and a client.

Question 6

TLS data protection

Answer 6

Application data are encapsulated with the TLS Record Protocol.
It mandatorily computes the MAC for integrity and optionally encrypts the obtained structure for confidentiality with symmetric enc algos and using an authN-then-encrypt schema.

The flows is the following:
- a TLS record is created with an empty MAC field (fixed sixe based on the chosen function) and random padding
- the MAC is computed over the data (that can be compressed or not) and inserted in the field. The directional MAC key is used
- the Enc key is used (with IV if needed) to encrypt the record

MAC = message_digest (key, seq_number || type || version || length || fragment)

Question 7

TLS keys

Answer 7

They are 4 directional keys, 2 for MAC and 2 for Encryption.

During the handshake the client generates a pre-master secret that, only for the first connection, is combined with the random numbers to generate the master secret. Pre-master and master secrets will be used during the whole session.

The keys derive from the combination of master and random numbers and are re-generated at each connection.

Question 8

TLS sequence number

Answer 8

Implicit, 2^64 values, then the session is closed.
It helps in avoiding replay and filtering attacks.

Question 9

PFS in TLS

Answer 9

If a server has a certificate valid for both signature and encryption, then such a certificate can be used both for authentication (via a signature) and key exchange (asymmetric encryption of the session key).
But if an attacker copies all the encrypted traffic and later discovers the long-term private key, then
they can decrypt all the traffic…past, present, and future!

For this reason, the concept of perfect forward secrecy has been introduced. It ensures that:
* The compromise of the secret key used in the KE (Key Exchange) compromises only the current (and potentially future) traffic, but not the past traffic.
* It can be implemented using techniques such as ephemeral key exchange mechanisms (e.g., Diffie- Hellman Ephemeral (DHE) or Elliptic Curve Diffie-Hellman Ephemeral (ECDHE)).

Perfect forward secrecy is optional in TLS 1.2 but compulsory in TLS 1.3.

Question 10

Ephemeral keys

Answer 10

A technique to reach PFS is to use ephemeral keys, that are key pair generated on-the-fly and signed with the long provate key (in this case of the server).
- if E keys are used this can be considered server authN
- the on the fly key pair won’t actually have a X.509 certificate
- the long term private key will only be used to sign data (keyUsage = digitalSignature) while the E key will be used to perform encryption

Question 11

TLS1.2 handshake

Answer 11

ClientHello
TLS version + ciphersuite list + compression method lists + 28B ClientRandom + sessionID

Each ciphersuite is in the from:
SSL_KeyExchangeAlgorithm_WITH_SymmetricEncryptionAlgorithm_HashAlgorithm(for MAC) ;

ServerHello
chosen TLS version + chosen ciphersuite list + chosen compression method lists + 28B ServerRandom + chosen sessionID

Certificate
Server X.509 certificate with the certificate chain to verify it.

[ServerKeyExchange]
Only if Ephemeral keys are used, here the server sends to the client the ephemeral public key encrypted with its long term secret key.
This is the only message explicitly signed by the server

[CertificateRequest]
The server asks the client for its certificate and shares the list of its trusted CAs.

[Client Certificate]
The client shares its X.509 certificate.

Client Key Exchange
The client encrypts the pre-master secret with the received pub key.

[Certificate Verify]
The client performs a signature over the digest computed over all the messages before this one. The server will compute the digest and verify the signature with the claimed client public key.

C: ChangeCipherSpec
Allows to pass from the previous unprotected messages to the protection of the next messages with the negotiated algorithms and keys

C: Finished
The client computes and hash with the master secret over the exchanged messaged but the changecipherSpec.
It prevents rollback man-in-the-middle attacks (version downgrade or cipher suite downgrade)

S: ChangeCipherSpec

S: Finished
The server computes and hash with the master secret over the exchanged messaged but the changecipherSpec

Question 12

TLS resumed session

Answer 12

The client sends a session ID ≠ 0 in the ClientHello and the session is resumed if the server responds with the same sessionID in the ServerHello.

If the session is resumed then the new keys are generated with the new randoms and the master secret of the session.

Question 13

TLS link teardown

Answer 13

If the client wants to close a connection it uses the Alert protocol:
- the client sends the alert close_notify that is protected by the MAC
- it waits for the ACK from the server: alert close_notify that is protected by a MAC too.
- they both check the MAC value and effectively close the connection if the value is the expected one.

The acknowledgment is needed to avoid closing a connectin if a fake request to do so is received.

Question 14

TLS setup time

Answer 14

TLS1.2
It takes 2RTT, 1 if False Start is used

• (C→S) SYN
  – (S→C) SYN-ACK
• (C→S) ACK + ClientHello
  – (S→C) ServerHello + Certificate
• (C→S) ClientKeyExchange + ChangeCipherSpec + Finished
  – (S→C) ChangeCipherSpec + Finished

TLS1.3
Basically, it’s a 1-RTT handshake that can be reduced to 0-RTT upon resumption of a previous session (or by using Pre-Shared Key, which is rare).

Question 15

TLS versions

Question 16

TLS algorithms evolution

Question 17

ALPN extension

Answer 17

Application Layer Protocol Negotiation
It is a TLS extension needed to negotiate the apllication level protocol that will run over TLS while performing the TLS handshake. This is useful to avoid setting up a TLS connection that will be closed because no common application level protocol is found.

• During the (ClientHello) ALPN=true + list of supported application protocols:
  the client indicates that ALPN is supported and provides a list of supported application protocols.
• During the (ServerHello) ALPN=true + selected application protocol: the server responds by indicating that ALPN is supported and selects one of the application protocols from the client’s list.

Question 18

TLS downgrade problem and solution

Answer 18

During the TLS handshake, with ClientHello and ServerHello, the two parties agree on the TLS version to be used. The client proposes the supported versions and the server should choose the highest one it has in common among the ones present in the list.
The problem is that when the server doesn’t find a supported version, the connection is closed. In this case the client re-tries with a new connection and proposes some lower versions.

This mechanism can be exploited by a MITM attacker that sends to the client fake server responses making it believe that it has to retry to connect with lower protocol versions.
This process is iterated till the client asks for a vulnerable TLS. version that the attacker can exploit to run suitable attacks.

• The process starts when the client tries to reconnect to a specific server with an older protocol version.
• The client SHOULD send TLS_FALLBACK_SCSV when re-opening a downgraded connection in the clientHello. This cipher suite should be listed last in the cipher suite list.
• If the server supports a newer protocol version than the protocol version already sent by the client in the last clientHello message, a new fatal alert value, inappropriate_fallback, MUST be sent by the server to the client. When this alert is sent, the channel is closed, and the client should retry with its highest protocol version.

Question 19

TLS virtual servers problem and solution

Answer 19

There are scanarios where multiple servers with different logical names have the same IP address. When HTTPS is used it is difficult to understand which certificate to request.

Solutions:
* wildcard certificates: one cert for multiple servers with the same domain. Problems: key shared among the servers
* Use the Subject Alternate Name extension of the X.509 certificate: this means that the key has to be shared and that every time a server is added or delate the certifcate has to be reissued
* SNI (Server Name Indication) extension: allows the client to specify the server name in the ClientHello message. However, support for SNI is limited among browsers and servers.

Question 20

TLS attacks (list)

Answer 20

• Heartbleed
• Bleichenbacher
• CRIME
• BREACH
• BEAST
• POODLE
• FREAK

Question 21

TLS False Start

Answer 21

TLS False Start, defined in RFC-7918, is a technique that allows the client to send application data together with the ChangeCipherSpec and Finished messages in a single TCP segment, without waiting for the corresponding server messages. This approach reduces latency to 1-RTT, making the connection establishment faster.

Question 22

TLS session tickets

Answer 22

They are data structures sent from the server to the client, ecnrypted with the SECRET key of the server and containing the crypto parameters of a TLS session.
This allows to move the cache on the client without the sever having to cache all the parameters of all the. negotiated sessions.

Question 23

TLS1.3 features and modifications

Answer 23

• handshake speed up, shorter latency -> reduced RTT
• encrypt more of the handshake -> key share is immediately done and other messages can be encrypted
• imporving resiliency to cross protocols
• KDF is redesigned
• only AEAD modes, so no more MAC keys
• 5 orthogonal cryptosuites that only specify encryption algorithm and mac algorithm
• signature is only performed using the RSA-PSS schema
• ephemeral keys are compulsory

Question 24

TLS1.3 handshake

Answer 24

ClientHello:
* Client random
* Highest supported protocol version
* Supported ciphersuites and compression methods (TLS1.2)
* Session ID
* extensions

The extensions in the Client Hello can be:
* key_share which is the portion of the client of (EC)DHE
* signature_algorithms which contains the list of supported algorithms
* psk_key_exchange_modes that contains the list of supported modes for key exchange
* pre_shared_key that is the list of pre-shared keys offered, if any (could be missing if there’s no pre- shared key)

ServerHello:
* the selected ciphersuite
* selected compression method
* session ID
* Server Random
* extensions

Among the server extensions:
* key_share is the portion of the key generated by the server using (EC)DHE
* pre_shared_key = selected PSK, if any

After this exchange, the certification and both client-server finished messages are encrypted: after the server sends the “key share” message, the client and server are able to create the pre-master secret and derive all necessary keys from it.

The next handshake messages that can be sent are of type:
* EncryptedExtensions
* CertificateRequest
* Certificate
* CertificateVerify
* Finished
* NewSessionTicket
* KeyUpdate
* EndOfEarlyData: If the server sent an “early_data” extension in EncryptedExtensions,
the client MUST send an EndOfEarlyData message after receiving the server Finished. If the server does not send an “early_data” extension in EncryptedExtensions, then the client MUST NOT send an EndOfEarlyData message. This message indicates that all 0-RTT application_data messages, if any, have been transmitted and that the

For backward compatibility, TLS 1.2 messages are also sent and most of TLS 1.3 features are in message extensions. This way, if the client is capable of using TLS 1.3, it will understand the extensions and fully use TLS 1.3; otherwise, it will use TLS 1.2.

Question 25

TLS and PKI: when is it needed?

Answer 25

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.

Question 26

TLS options to check certificates revocation + their problems

Answer 26

CRL: long look-up, big size

OCSP: privacy problem

Question 27

TLS solutions for revoked certificates (list)

Answer 27

• TLS
• OCSP

Question 28

pushed CRLs

Answer 28

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

Question 29

OCSP stapling

Answer 29

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

Question 30

Which attack does OCSP Must Stapling avoid?

Answer 30

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);

Question 31

HeartBleed attack

Answer 31

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.

Question 32

Bleichenbacher Attack (and ROBOT)

Answer 32

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.

Question 33

CRIME

Answer 33

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.

Question 34

BREACH

Answer 34

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.

Question 35

BEAST

Answer 35

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.

Question 36

POODLE

Answer 36

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.

Question 37

FREAK

Answer 37

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;