This report analyses the security of older TLS versions by illustrating a taxonomy of attacks and explaining technical details on the BEAST and Lucky Thirteen attack. The fundamentals of TLS are based on the TLS 1.2 standard. Furthermore, the advantages of a migration to TLS 1.3 are highlighted.
The internet has become part of our daily lives. When the internet was originally designed, no one was considering the potential threats it might behold. Today, all devices connected to the internet have one thing in common - they rely on secure protocols to protect the information in transit. This is where Secure Socket Layer (SSL) and Transport Layer Security (TLS) come into play.
The Transport Layer Security protocol quickly became dominant for use in applications and servers for transferring data across the internet in a secure manner. One way to recognize a secure website is the usage of Hypertext Transfer Protocol Secure (HTTPS). The “S” in HTTPS stands for “Secure” and is an easy characteristic to identify secure website connections.
Furthermore, to highlight to a client that TLS is used to protect HTTP, the server may replace the protocol naming in the URL with https and add a lock symbol or even a coloured address bar. Besides, the Google Chrome Web browser has started flagging all unencrypted HTTP sites as "not secure" Moreover, Google is penalizing websites which are not protected.
The TLS Protocol is widely used for providing internet security. The protocol has been subject to several version upgrades over the course of its 25-year lifespan. Although TLS 1.3 is the latest version, its predecessor TLS 1.2 is most widely supported by websites. The versions minor to TLS 1.3 have several vulnerabilities which have been exploited in attacks like POODLE, BEAST etc.
TABLE OF CONTENTS
1 Introduction
1.1 Motivation
1.2 Research Objective
1.3 Structure of this report
2 Fundamentals of SSL/TLS and DTLS
2.1 Introduction
2.2 SSL/TLS
2.2.1 TLS Record Protocol
2.2.2 TLS Handshake Protocol
2.3 DTLS
2.3.1 DTLS Record Protocol
2.3.2 DTLS Handshake Protocol
2.4 Summary
3 Attacks on SSL/TLS and DTLS
3.1 Introduction
3.2 BEAST Attack
3.2.1 How the Attack Works
3.2.2 Mitigation
3.3 Lucky Thirteen Attack
3.3.1 How the Attack Works
3.3.2 Padding Oracle Attack
3.3.3 Mitigation
4 TLS 1.3
4.1 Introduction
4.2 TLS Handshake Protocol
4.3 Summary
5 Conclusions
IV. REFERENCES
ABSTRACT
The internet has become part of our daily lives. When the internet was originally designed, no one was considering the potential threats it might behold. Today, all devices connected to the internet have one thing in common - they rely on secure protocols to protect the information in transit. This is where Secure Socket Layer (SSL) and Transport Layer Security (TLS) come into play.
The TLS Protocol is widely used for providing internet security. The protocol has been subject to several version upgrades over the course of its 25-year lifespan. Although TLS
1.3 is the latest version, its predecessor TLS 1.2 is most widely supported by websites. The versions minor to TLS 1.3 have several vulnerabilities which have been exploited in attacks like POODLE, BEAST etc. This report analyses the security of those older TLS versions by illustrating a taxonomy of attacks and explaining technical details on the BEAST and Lucky Thirteen attack. The fundamentals of TLS are based on the TLS 1.2 standard. Furthermore, the advantages of a migration to TLS 1.3 are highlighted.
I. LIST OF FIGURES
Figure 1: Internet Usage by World Population in percent 45
Figure 2: Google Chrome flagging secure website with lock symbol
Figure 3: Cybercrime incidents recorded by German police from 2005 to 2019 40
Figure 4: Websites supporting the SSL/TLS Protocol in percent including release year of the protocols (status as of February 2021) 37
Figure 5: TCP/ IP Model and representation of SSL/TLS protocol in the layers 38
Figure 6: Components of SSL/TLS 43
Figure 7: TLS 1.2 Record
Figure 8: TLS 1.2 Handshake Protocol with RSA-based key transport
Figure 9: DTLS 1.2 Record
Figure 10: DTLS 1.2 Handshake Message
Figure 11: DTLS 1.2 Handshake Protocol
Figure 12: Comparison (a) TLS 1.2 Record and (b) DTLS 1.2 Record
Figure 13: Comparison (a) TLS 1.2 Handshake and (b) DTLS 1.2 Handshake Message flow
Figure 14: AES Encryption in ECB Mode
Figure 15: AES Encryption in CBC Mode
Figure 16: BEAST attack against AES with CBC mode and predictable IV
Figure 17: MAC-Then-Pad-Then-Encrypt design for TLS 1.2
Figure 18: Formatted message block to calculate MAC
Figure 19: Formatted message block for encryption
Figure 20: Application Data Packet
Figure 21: Padding Oracle Attack on CBC Decryption
Figure 22: TLS 1.3 Handshake Protocol with DH-based Key Exchange (DHE)
II. LIST OF TABLES
Table 1: Release Timeline and Security States of SSL/TLS and DTLS Versions
Table 2: Classification of SSL/TLS Attacks
Table 3: RFC 8446 29 Extract - Major Differences from TLS 1.2
Table 4: Improvements in TLS 1.3 compared to TLS 1.2 in terms of Security and Performance
III. LIST OF ABBREVATIONS
Abbildung in dieser Leseprobe nicht enthalten
1 Introduction
1.1 MOTIVATION
The internet was initially created as a research network called Advanced Research Projects Agency Network (ARPANET), as stated by Prof. Joerg Schwenk in his book 43. At that time, no one was considering the potential threats that the internet nowadays beholds.
Today, the internet has become part of our daily life in varying degrees. The drastically increasing curve in Figure 1 shows the percentage of world population using the internet 45 from 1990 to 2019. With increasing number of users, especially hackers are more and more attracted to finding vulnerabilities in existing systems and using them to their advantage. This theory is confirmed by the statistics visualized in Figure 3 which depicts the cybercrime incidents recorded by the German police 40 from 2005 to 2019. The incidents have multiplied in the last decades and further increase is expected.
Abbildung in dieser Leseprobe nicht enthalten
Figure 1: Internet Usage by World Population in percent [45]
The Transport Layer Security (TLS) protocol quickly became dominant for use in applications and servers for transferring data across the internet in a secure manner. One way to recognize a secure website is the usage of Hypertext Transfer Protocol Secure (HTTPS). The “S” in HTTPS stands for “Secure” and is an easy characteristic to identify secure website connections. Furthermore, to highlight to a client that TLS is used to protect HTTP, the server may replace the protocol naming in the URL with https 43 and add a lock symbol (cf. Figure 2) or even a coloured address bar. Besides, the Google Chrome Web browser has started flagging all unencrypted HTTP sites as "not secure" 35. Moreover, Google is penalizing websites which are not protected 36.
Abbildung in dieser Leseprobe nicht enthalten
Figure 2: Google Chrome flagging secure website with lock symbol
Security Researcher Troy Hunt launched a website called “whynohttps.com”. It lists the world's top 100 websites that load over an insecure connection without automatically redirecting to a secure, encrypted one 35. On his site he states that HTTPS is now free, easy and increasingly ubiquitous 18. “Yet still, many of the world's largest websites continue to serve content over unencrypted connections, putting users at risk even when no sensitive data is involved”, Hunt 18 emphasises.
Abbildung in dieser Leseprobe nicht enthalten
Figure 3: Cybercrime incidents recorded by German police from 2005 to 2019 [40]
Meanwhile there are free and open certificate authorities (CAs) available online, like “letsencrypt.org”. Let’s Encrypt Inc. 31 is a free, automated, and open CA run for the public’s benefit. It is a service provided by the Internet Security Research Group (ISRG). They provide websites with the digital certificates they need in order to enable HTTPS (SSL/TLS) for websites, free of costs. As of November 2020, Let’s Encrypt Inc. served 232 million websites with 144 million active certificates, as announced in their annual report.
Given the grounds of increasing number of internet users, web attacks, and the opportunity of providing state-of-the-art internet security for free, website providers are more or less forced to establish secure connections to their websites, if they want to remain attractive for their users. Therefore, most websites are using HTTPS by default regardless of whether sensitive data is exchanged or not 36. On a sidenote, HTTPS does not only provide confidentiality, but also data integrity and authenticity (cf. Section 2).
1.2 RESEARCH OBJECTIVE
Transport Layer Security (TLS) has become a de-facto standard for internet security. The protocol has been subject to a number of version upgrades over the course of its 25-year lifespan 8. Today, TLS 1.3 is the latest version of the protocol, which was published in 2018. TLS, initially developed by Netscape, was first called Secure Socket Layers (SSL). Therefore, the protocol is often referred to as SSL/TLS.
Figure 4 is a statistic from SSL Pulse by Qualsys SSL Labs [37], which shows the distributed SSL/TLS protocol support. On the SSL Pulse dashboard [37] they explain that there are six versions in the SSL/TLS family, but not all of them are secure. Furthermore, SSL Labs suggests using minimum TLS 1.2 as main protocol and TLS 1.3 if supported by the server platform. That way, clients can select TLS 1.3 if supported and if not will fall back to TLS 1.2. Additionally, SSL Labs stresses that SSL 2.0 and SSL 3.0 shall not be used since those versions are insecure.
Abbildung in dieser Leseprobe nicht enthalten
Figure 4: Websites supporting the SSL/TLS Protocol in percent including release year of the protocols (status as of February 2021) 37
As of February 2021, TLS 1.3 is supported by 42,9% of surveyed websites, while TLS 1.2 is supported by 99,3%. The protocol versions 1.1 and 1.0 are supported by around 50% of surveyed websites and SSL 2.0 and 3.0 rarely with 0,5 to 3,8%. Note that one website might support multiple protocol versions.
In conclusion, TLS 1.2 is currently most supported by websites, followed by TLS versions 1.1 and 1.0. The primary research objective is to examine the security of these TLS protocol versions minor to TLS 1.3 as they are most widely spread. Additionally, advantages of a migration to TLS 1.3 are highlighted by pointing out the improvements and major differences to prior protocol version TLS 1.2.
1.3 STRUCTURE OF THIS REPORT
This report is organised as follows. Section 2 provides fundamentals of the TLS and Datagram TLS (DTLS) protocol based on TLS 1.2 and DTLS 1.2 specifications. Section 3 introduces a taxonomy of common SSL/TLS attacks and presents a deeper look on two prominent attacks, BEAST and Lucky Thirteen. The former attack affects TLS version 1.0, and the latter affects TLS versions 1.1 and 1.2. Section 4 covers improvements in the latest TLS 1.3 version and major differences to the prior protocol version TLS 1.2. Conclusions and outlook are given in Section 5. Note that Section 2 and 4 contain a summary at the end of the section highlighting the most important facts.
2 Fundamentals of SSL/TLS and DTLS
The basic idea of SSL/TLS and DTLS is to provide a transparent, encrypted, and authenticated channel for reliably transmitting data between two hosts. This has two advantages: simple configuration and universal applicability beyond the HTTP protocol 43.
This section starts with some background to understand better where SSL/TLS and DTLS apply followed by an overview on the fundamentals of the protocols including a comparison of both, the TLS and DTLS protocol, at the end of the section.
2.1 INTRODUCTION
To understand the role of SSL and TLS in a network, the Transmission Control Protocol/ Internet Protocol (TCP/ IP) model comes in handy. The TCP/IP model helps to determine how a specific system should be connected to the internet and how data should be transmitted between them. This model was based on protocols that already existed or earlier versions of them existed 2, like TCP. Therefore, it was named after the Transmission Control Protocol and the Internet Protocol, which together create the backbone of the model 1.
Figure 5 shows the TCP/ IP model with some example protocols. Additionally, it illustrates the representation of the SSL/TLS protocol in the layers. SSL/TLS requires a reliable transport protocol, e.g., TCP, while any application protocol can be layered on top of it, e.g., HTTP. In order to use TLS for datagram-based protocols (e.g., UDP), adjustments must be made. In this case, a modified version of TLS called Datagram TLS (DTLS) shall be layered on top of the datagram-based transport protocol. Nevertheless, the SSL/TLS protocol is considered to be located between transport and application layer 43, here depicted as an additional layer called presentation layer.
Abbildung in dieser Leseprobe nicht enthalten
Figure 5: TCP/ IP Model and representation of SSL/TLS protocol in the layers 38
The advantage of the SSL/TLS protocol is that it is independent from the application protocol. Any "higher level" application protocol, such as HTTP, FTP, TELNET, etc., can layer on top of the SSL/TLS protocol transparently 23. In summary, the main idea of SSL/TLS is to provide an additional security layer between the application and transport layer. This security layer adds the aspect of security enhancements without compromising the communication. Furthermore, SSL/TLS performs assembling and disassembling actions of the messages, so that both levels can interpret the messages without compromising on security.
The history of Transport Layer Security (TLS) begins with Secure Socket Layer (SSL) Version 2.0 which was initially integrated in February 1995 in the Web browser Netscape Navigator 43. As SSL 2.0 showed several conceptual weaknesses, it was quickly replaced with Version 3.0 in 1996. After the release of SSL 3.0, the Internet Engineering Task Force (IETF), mostly known as the standards organisation that defines internet protocols, took over the development of the protocol and renamed it to Transport Layer Security (TLS). The redesign in SSL 3.0 turned out to be exceptionally robust, which is why it was used as a base for the subsequent TLS versions 43.
A little background information on the naming of SSL: SSL secures a combination of the IP address and port number, which are processed by the TCP protocol as unique identifiers on the Internet. Those combinations are also called sockets. Therefore, the protocol was named Secure Socket Layer 43.
The SSL/TLS protocol is composed of two layers, the record protocol, and the handshake protocol 23. The TLS record protocol is at the lowest level, layered on top of a reliable transport protocol, like TCP. The main idea of SSL/TLS is to provide an additional security layer above the transport protocol.
The TLS record protocol provides connection security which has two basic properties 23:
1. The connection is private.
2. The connection is reliable.
Firstly, encryption is used for all messages after an initial handshake was performed to define a secret key. Note that symmetric cryptography is used for data encryption (e.g., DES, RC4, etc.). Secondly, the server endpoint of the conversation is always authenticated, while the client endpoint is optionally authenticated. Here, asymmetric cryptography is used for authentication (e.g., DSS, RSA, etc.). And thirdly, the message transport includes a message integrity check. Cryptographic hash functions (e.g., MD5, SHA, etc.) are used for Message Authentication Code (MAC) computations.
Every TLS implementation consists of multiple logical components at client and server side. Figure 6 shows the elements of the SSL/TLS protocol in blue, while components of the transport layer (e.g., TCP) and application layer (e.g., HTTP, IMAP) are white. Alert messages are used to communicate errors or misunderstandings between communication partners. They convey the severity of the message (either warning or fatal) and a description of the alert itself. Alerts with level fatal immediately terminate the connection, invalidating the Session_ID (cf. Section 2.2.2) and deleting all cryptographic key material. The ChangeCipherSpec message is sent by both, client and server, to notify the receiving party that subsequent records will be protected under the newly negotiated CipherSpec and keys (cf. Section 2.2.2).
Abbildung in dieser Leseprobe nicht enthalten
Figure 6: Components of SSL/TLS 43
Theoretically it is possible to use any TCP/UDP-based network protocol with or without SSL/TLS or DTLS. Therefore, it is required to have a mechanism for identifying the usage of SSL/TLS between client and server. Hence, new protocol names were introduced in URLs. With the addition of the letter “s” the client and user can recognize the activation of SSL/TLS in their communication, for example: http becomes https, imap becomes imaps, and ftp becomes ftps.
The next subsections will examine the SSL/TLS record and handshake protocols. All upcoming subsections refer to TLS 1.2, if not stated differently. RFC 5246 23 by IETF and the book “Sicherheit und Kryptographie im Internet” 43 by J. Schwenk were taken as main references for the next two sections.
2.2.1 TLS Record Protocol
The TLS record layer shall encrypt and authenticate all parameters before handing them over to the transport layer. RFC 5246 23 explains that the record layer is used for encapsulation of various higher-level protocols, including the TLS handshake protocol, which is used to establish security parameters.
The TLS record layer receives uninterpreted data from higher layers (e.g., HTTP) in blocks of arbitrary size. As SSL/TLS is a layered protocol, messages may include fields for length, description, and content at each layer. The TLS record layer takes messages that are meant to be transmitted to lower layers and performs the following steps:
1. fragments data into manageable blocks
2. compresses data (optionally)
3. computes a MAC
4. adds padding (to a multiple of the block size)
5. encrypts the record
The last three steps are also known as the MAC-Then-Pad-Then-Encrypt approach (cf. Section 3.3). Inverted actions are performed with received data: data is decrypted, padding removed, verified, decompressed, reassembled, and then delivered to higher level clients.
In SSL/TLS, each record consists of two main blocks, a header, and a data block (cf. Figure 7). The header has three fields and transmits information about the type, version, and length of the record. Type describes the type of SSL message, which can be either ChangeCipherSpec (Type=20), Alert (Type=21), Handshake (Type=22) or others like HTTP messages (Type=23). Note, that the selectable types are exactly the components from Figure 6. For the versions, there are currently values 3.0 for SSL, 3.1 for TLS 1.0, 3.2 for TLS 1.1, and 3.3 for TLS 1.2 in use. At last, the length of the succeeding data block is communicated.
Abbildung in dieser Leseprobe nicht enthalten
Figure 7: TLS 1.2 Record
2.2.2 TLS Handshake Protocol
Every SSL/TLS connection begins with a handshake. The TLS handshake protocol is responsible for negotiating a session. If the client has not previously established a session with the server, the two sides will execute a full handshake in order to negotiate a SSL/TLS session 39. The client and server exchange messages until both ends send their final "Finished" message, indicating that they are satisfied with the handshake protocol conversation.
During this handshake, the client and the server will perform four main activities 39:
- Exchange capabilities and agree on desired connection parameters.
- Validate the presented certificate(s) or authenticate using other means.
- Agree on a shared master secret that will be used to protect the session.
- Verify that the handshake messages have not been modified by a third party.
Figure 8 shows all mandatory steps of the TLS 1.2 handshake with RSA-based key transport. There are additional optional messages, which will not be covered in this report. The first phase is the initial connection phase. Here, the client initiates the conversation by sending (1) ClientHello message. It contains information that the server needs to establish a SSL/TLS connection between the two parties. The ClientHello includes the supported version number, a list of the clients cryptographically supported cipher suites, and, if applicable, a Session_ID from a previously established session between server and client. The advantage of reusing a Session_ID is a shortened handshake. Additionally, the client sends a random number ClientRandom, which will later be used for key derivation.
Abbildung in dieser Leseprobe nicht enthalten
Figure 8: TLS 1.2 Handshake Protocol with RSA-based key transport
The server receives the message and processes it by responding with (2) ServerHello message. First, the server selects a cipher suite (typically the strongest) and informs the client about the decision in message (2). Further, the server sends a random number ServerRandom for later key calculation. Additionally, the server creates a new Session_ID (if none previously existed) and shares it with the client.
Afterwards, the server shares its public key in form of a certificate (3). This key shall be used by the client to encrypt the pre-master secret (see explanation message (5)). At last, the server ends the first phase by sending (4) ServerHelloDone.
Now, in case of RSA-based key transport, the client selects the pre-master secret, encrypts it with the public key of the server, and transmits it in message (5) ClientKeyExchange. Alternatively, the pre-master secret can also be negotiated between client and server using a Diffie-Hellmann based key agreement. The pre-master secret is used to derive the master secret, which is the base for the upcoming cryptographic operations.
After the derivation of the master secret, the pre-master secret is no longer required and can be deleted. Finally, the client can switch to the newly generated keys and agreed algorithms with ChangeCipherSpec and transmits his final (6) Finished message.
The server performs the same steps: derivation of master secret and updating its specification with ChangeCipherSpec; and closes the handshake with (7) Finished. Note that the Finished message contains a hash computation using the master secret over all handshake messages exchanged so far. This ensures that nobody has intercepted the handshake messages or modified them. Once the TLS handshake is complete, the encrypted and authenticated HTTPS connection begins, and all data sent and received between server and client is protected.
If a session was established between server and client once, a unique ID is stored in the server’s data base. This Session_ID can be reused for future sessions. In this case, a session resumption would take place and the handshake would only consist of messages (1), (2), (6), and (7). Here, the client would add the Session_ID to his hello message and the server would verify, if he wants to allow the reuse of the existing master secret. If yes, the server will reply with the same Session_ID in his hello message.
In conclusion, the following information (amongst others) is available to server and client after a successful handshake:
- A Session_ID as a unique identifier for their session.
- A cipher suite at both ends with a public key algorithm for the pre-master key exchange, a symmetrical encryption algorithm, and a hash algorithm.
- A mutual master secret.
- An encryption key for data transfers between server and client, respectively.
- A key for generating MACs in each transmission direction, respectively.
On a side note, TLS can also be used with pre-shared keys (PSKs). Therefore, additional cipher suites were added to the TLS protocol which are specified in RFC 4279: Pre-Shared Key (PSK) Ciphersuites for Transport Layer Security (TLS) 20. The benefits of using pre-shared secret keys are first of all performance improvements, as TLS with PSKs avoids performance-constraining public key operations and is hence faster. Secondly, key management is more convenient with PSKs than with certificates.
2.3 DTLS
The TLS protocol presented in 2.1 is layered on top of a TCP-based network protocol because of the need for supporting message reordering, message retransmission, and reliable message delivery. Nevertheless, many delay-sensitive protocols (e.g., video streaming) demand faster packet deliveries, which can be achieved by using datagram transport protocols (e.g., UDP). However, User Datagram Protocol (UDP) can neither guarantee message delivery, nor the right message order. In order to use TLS for datagram-based protocols, adjustments must be made. Additional parameters and fields allow to provide reliable message delivery.
The alterations are specified in RFC 4347 Datagram Transport Layer Security Version 1.0 22 (considers differences to TLS 1.1) and RFC 6347 Datagram Transport Layer Security Version 1.2 25 (considers differences to TLS 1.2).
In the next sections, the adjustments on the record layer and in the handshake protocol for the Datagram TLS (DTLS) protocol are highlighted. The content of these sections is mainly based on RFC 6347 25, and the book “Sicherheit und Kryptographie im Internet” 43 by J. Schwenk.
2.3.1 DTLS Record Protocol
The basic design philosophy of DTLS is to construct TLS over datagram transport. The challenge of DTLS is to overcome the unreliability that comes with datagram environments, like data loss or reordering of packets.
The TLS record layer uses implicit sequence numbers, meaning they are not transferred as part of the TLS message itself. If a record is irrecoverable or the sequence of the records is interchanged, the MAC verification will eventually fail, and the connection will be aborted with a Badrecordmac-alert. As an example, if record N is not received, then the integrity check on record N+1 will fail, as its integrity check is based on the wrong sequence number.
In summary, the requirement for the DTLS record layer can be formulated quite precisely: the DTLS record layer must provide stateless decryption.
In order to be able to decrypt records in DTLS, the record layer must most importantly save the implicit sequence numbers from the MAC calculations. The verification of these implicit sequence numbers can only work when all records are received in correct order. As this condition cannot be guaranteed over datagram transport, explicit sequence numbers must be used. For this, a new field of 48-bit is added to the record header. The sequence number increments for each packet sent between the client and server.
Secondly, (D)TLS must remember all negotiated algorithms and cryptographic keys. With the ChangeCipherSpec message the participant communicates, that the negiotations have been updated and activated. As the message order is not guaranteed with datagram environments, it might happen that the message ChangeCipherSpec is received prior to the actual KeyExchange. As a solution, an additional field of 16-bit called epoch is added to the DTLS record, which keeps incrementing whenever the encryption status is changed.
All things considered, two new fields must be added to the DTLS record Layer when using datagram transport protocol (cf. Figure 9): the sequence number (48-bit) and the epoch (16-bit).
[...]