Selfie: reflections on TLS 1.3 with PSK

Abstract

TLS 1.3 allows two parties to establish a shared session key from an out-of-band agreed pre-shared key (PSK). The PSK is used to mutually authenticate the parties, under the assumption that it is not shared with others. This allows the parties to skip the certificate verification steps, saving bandwidth, communication rounds, and latency. In this paper, we identify a vulnerability in this specific TLS 1.3 option by showing a new “reflection attack” that we call “Selfie.” This attack uses the fact that TLS does not mandate explicit authentication of the server and the client, and leverages it to break the protocol’s mutual authentication property. We explain the root cause of this TLS 1.3 vulnerability, provide a fully detailed demonstration of a Selfie attack using the TLS implementation of OpenSSL, and propose mitigation. The Selfie attack is the first attack on TLS 1.3 after its official release in 2018. It is surprising because it uncovers an interesting gap in the existing TLS 1.3 models that the security proofs rely on. We explain the gap in these model assumptions and show how it affects the proofs in this case.

A Demonstrating the Selfie Attack

Fig. 3

Network configuration. a Normal configuration; both hosts communicate with each other (as intended); b the Selfie attack configuration: all packets sent to port P1 are reflected back to the sender, where the MAC and IP addresses are swapped

This section describes a demonstration of the Selfie attack in a way that it can be repeated by the reader. For completeness we also describe the system that we use for the experiments: a Linux (Ubuntu 16.04.3 LTS) OS running on a platform equipped with the latest $7^{th}$ Generation Intel$^{\textregistered }$ Core$Y^{TM}$ processor (“Kaby Lake”)—Intel$^{\textregistered }$ Xeon$^{\textregistered }$ Platinum 8124M CPU at 3.00 GHz Core$^{\textregistered }$ i$5-750$.

The smallest network configuration for the Selfie attack requires at least one node that acts as a server and as a client (Alice) and a switch that acts as the Selfie mirror (Mallory). Our experiment was executed on a single desktop machine as follows. We emulated a virtual network using Mininet [31]. To run its virtual machine image, we used VirtualBox [33]. Inside the virtual machine, we installed the latest version of OpenSSL [32] configured to enable TLS 1.3.

We started the virtual network inside the virtual machine by executing

This generates a network with two nodes (Host 1 is Alice and Host 2 is Bob) and an ovsk switch (Mallory) as illustrated in Fig. 3. We used two configurations for the switch in order to simulate the normal intended operation (Fig. 3, panel a) and the Selfie attack scenario (panel b). The associated command lines for the normal configuration, where packets from port 1 (P1) are forwarded to port 2 (P2) and vice versa are

For the Selfie attack configuration. We use the commands

and

The first command reflects every packet that arrives to P1 back to its origin (which is Host 1). However, note that the source and destination (IP and MAC address) are flipped. The second command tells the switch how to handle Address Resolution Protocol (ARP) requests. It is important (for this experiment) to set the priority of the second command to be higher than the priority of the first command. This allows ARP replies (otherwise, the second host is unidentified and will not receive any ARP messages).

In both hosts, we set the PSK to have the (arbitrary) value

Now we opened a TLS 1.3 server (with OpenSSL) on both hosts that are configured to listen to port 1443 as follows

Subsequently, we opened a client on Host 1 with the command

Remark 2

We comment about the specific TLS 1.3 implementation of OpenSSL. Here, the client always offers the psk_dhe_ke KE mode to the server. The server prefers the psk_dhe_ke mode over the psk_ke mode (because it provides FS). Therefore, our demonstration shows an attack on TLS 1.3 with external PSK in the psk_dhe_ke KE mode. Clearly, the Selfie attack is also possible in the psk_ke mode (see details in Sect. 3.1).

1.1 The Outcome

In the normal mode, the operation was as intended: Host 1 is communicating with Host 2 and the TLS 1.3 with PSK session was established correctly. By contrast, under the Selfie attack, Host 1 ended up communicating with itself consuming exactly the same messages that it delivered. The implications were discussed above.

It is interesting to note that this experiment cannot be repeated with BoringSSL (and not OpenSSL) as the underlying cryptographic library. While BoringSSL enables TLS 1.3 by default, in the client and server, it does not support (implement) the option of using PSK without certificates.

1.2 Demonstrating the Attack on a TLS 1.3 Without Ephemeral Keys

The Selfie attack can also be mounted without using ephemeral keys, i.e., for TLS 1.3 with PSKs in psk_ke mode (without FS). We verified this by an experiment. To this end, we prepared a patched version of OpenSSL that disables the psk_dhe_ke mode for the TLS client. Subsequently, we ran the above demonstration with the patched OpenSSL and added the -allow_no_dhe_kex flag to the client and server commands.

Remark 3

We comment on OpenSSL’s implementation of TLS. The TLS 1.3 server application (s_server) of OpenSSL provides two flags -no_dhe and -allow_no_dhe_kex with the following documented description “Disable ephemeral DH” and “In TLS v1.3 allow non-(ec)dhe based key exchange on resumption,” respectively. Therefore, we expect that using these flags will cause the server to operate only in the psk_ke mode. However, this did not give the expected results because the client always offers the psk_dhe_ke mode. We could not find a (intuitive) way to run the client in psk_ke mode. Therefore, we patched the client code to disable the psk_dhe_ke mode. This allows us to demonstrate that the Selfie attack is valid also in the psk_ke mode and not only in the psk_dhe_ke mode as above. Note that the attack relies on a property of TLS and not on a specific implementation of OpenSSL.