Institutionen för datavetenskap Department of Computer and Information Science

Transcription

1 Institutionen för datavetenskap Department of Computer and Information Science Examensarbete On the security of TLS and IPsec - Mitigation through physical constraints av Erik Reimers LIU-IDA/LITH-EX-G--15/050--SE Linköpings universitet SE Linköping, Sweden Linköpings universitet Linköping

2 Linköpings universitet Institutionen för datavetenskap Examensarbete On the security of TLS and IPsec - Mitigation through physical constraints av Erik Reimers LIU-IDA/LITH-EX-G--15/050--SE Handledare: Marcus Bendtsen Examinator: Nahid Shahmehri

3 Students in the 5 year Information Technology program complete a semesterlong software development project during their sixth semester (third year). The project is completed in mid-sized groups, and the students implement a mobile application intended to be used in a multi-actor setting, currently a search and rescue scenario. In parallel they study several topics relevant to the technical and ethical considerations in the project. The project culminates by demonstrating a working product and a written report documenting the results of the practical development process including requirements elicitation. During the final stage of the semester, students form small groups and specialise in one topic, resulting in a bachelor thesis. The current report represents the results obtained during this specialization work. Hence, the thesis should be viewed as part of a larger body of work required to pass the semester, including the conditions and requirements for a bachelor thesis.

4 Abstract TLS and IPsec are two protocols that provide secure communication on the Internet. They provide similar services but operate on different levels. This report compiles some of the current known vulnerabilities that exist in those two protocols. It also describes attacks that exploit those vulnerabilities. Based on the vulnerabilities this paper gives guidelines on how to avoid them when implementing TLS and IPsec. This paper also demonstrates a proof-of-concept that shows how IPsec can be configured to avoid some of the vulnerabilities. The proof-of-concept also shows how IPsec can be used to setup a secure connection between two peers, using Near Field Communication, on an ad hoc network.

5 Contents 1 Introduction Objectives Delimitations Theory Confidentiality, integrity and availability Terminology TLS - Transport Layer Security IPsec - Internet Protocol Security Attacks Method Systematic literature review Proof-of-concept Results TLS vulnerabilities Attacks IPsec vulnerabilities Attacks Proof-of-concept requirements ESP-only Authenticated encryption Face-to-face key exchange Proof-of-concept Simulated run Discussion Method Results A broader perspective Conclusion 24 References 25

6 List of Tables 1 TLS Handshake Protocol Search process documentation SPD and SAD Bypassed packet containing Hello Protected packet containing Hello List of Figures 1 TLS in the TCP/IP stack IPsec in the TCP/IP stack The IPsec modes IPsec processing KandidatBox communication KandidatBox environment Protected packet

7 1 Introduction On the Internet today secure communication is very important. Since the communication often takes place over long distances, passing several intermediary nodes on the way, the possibility that a third party can intercept and take advantage of the communication exists. Two of the most well known technologies that provide secure communications on the Internet today are Transport Layer Security (TLS) and Internet Protocol Security (IPsec). Both provide secure communication but they operate on different levels in the TCP/IP stack, TLS in the application layer and IPsec in the network layer. This means that they are not interchangeable, each of them is better suited for certain situations. TLS is often used on the web and is easier to use but has to be implemented in every application that wants to use it. Since IPsec works on a lower level it can provide security in an application independent manner. It is commonly used to create Virtual Private Networks (VPNs) but it can also provide host-to-host security. Both TLS and IPsec provide cryptographic flexibility but the implementation of the two protocols is not trivial. It requires some cryptographic knowledge and up-to-date information concerning known vulnerabilities in order to avoid insecure implementations. Even though both of them are designed to be secure, vulnerabilites are continually discovered. Some vulnerabilities are inherent in the mechanisms of the protocols while others depend on the algorithms used. The question is, what are the vulnerabilites in TLS and IPsec and who do they affect? What are the conditions necessary for an implementation to be considered secure? Can some of the vulnerabilities be mitigated? 1.1 Objectives The primary aim of this report is to draw conclusions on how to set up both IPsec and TLS securely. In order to do this the following two questions are answered by a systematic literature review. What are the known vulnerabilities of these protocols? What is the feasibility of them being exploited? The secondary aim is to create a proof-of-concept that will be a sandbox environment which allows applications that are run inside it to communicate securely. This means that developers do not need to include these features in their applications. The proof-of-concept will show that IPsec can be set up ad-hoc between two peers in a way that addresses some of the vulnerabilties found during the primary investigation and mitigates the associated risks. 1

8 1.2 Delimitations This report limits the TLS versions considered to SSL 3.0 and higher. SSL 2.0 does not provide enough security anymore and is prohibited by the IETF [1]. 2

9 2 Theory This section describes what constitutes information security, it gives a high level view of TLS and IPsec and explains some cryptographic terminology and the types of attacks examined in Section 4.1 and Confidentiality, integrity and availability Confidentiality, integrity and availability, also known as the CIA triad, are the corner stones of information security. These three concepts can be used to evaluate the security of a system. Confidentiality Confidentiality refers to the secrecy of information or resources. It also refers to the knowledge of the existence of them. This is often accomplished by limiting access to a resource or by limiting the visibility of a resource with cryptography [2]. Integrity Integrity refers to the trustworthiness of information or resources. It is comprised of the two concepts data integrity - data has not been changed in an improper way - and origin integrity - the source of the data affects its credibility. Integrity can be maintained by blocking changes of the data made by unauthorized users or blocking unauthorized ways of changing the data [2]. Availability Availability refers to the ability to access or use a piece of information or a resource. If a resource is unavailable its value is clearly affected. When creating mechanisms for confidentiality and integrity it is important to evaluate how they also affect availability [2]. 2.2 Terminology This section explains a few terms used in the report. Plaintext Plaintext is unencrypted information such as a text message in a form readable by a human. 3

10 Ciphertext Plaintext can be input into an encryption algorithm which then outputs the corresponding ciphertext. Initialization Vector An Initialization Vector (IV) is a random number that is used during some modes of encryption. It is used to guarantee that different ciphertexts are created when the same plaintext is encrypted with the same key multiple times [3]. Cipher Block Chaining (CBC) Cipher Block Chaining encrypts data in blocks. The first block is XORed with an IV before being encrypted. The subsequent blocks are XORed with the previously encrypted block before encryption. A message must be padded to a multiple of the block size. Message Authentication Code (MAC) A Message Authentication Code is the hash of a message together with secret data. It is used in order to detect if the message has been altered. Data compression Compression makes it possible to store and transmit the same amount of data in fewer bits. The more similar the data, the more it can be compressed. Internet Control Messaging Protocol (ICMP) ICMP is used for diagnostic messages, control messages or error messages related to IP operations [4]. Maximum Transmission Unit (MTU) The size of the largest packet that can be sent on a network. 2.3 TLS - Transport Layer Security TLS is a protocol providing application-to-application security on the Internet. It is an Internet Engineering Task Force (IETF) standards track protocol and the successor to the more well known Secure Sockets Layer (SSL) protocol, even though the two terms are often used interchangeably or in conjunction. The current version number is 1.2 [5]. TLS operates at the bottom of the Internet Protocol Suites (TCP/IP) application layer and often relies on TCP to handle retransmission and reliable delivery. It is often used together with HTTP for secure web access and with SMTP for secure transfer. 4

11 Figure 1: TLS in the TCP/IP stack. A TLS link exists between two peers and is identified by a session that contains information regarding the security mechanisms used. A single session can have multiple connections. TLS provides authentication integrity and confidentiality by supporting several cipher suites but can also support minimal or no security. A cipher suite defines what combination of authentication, encryption and integrity alogrithms to be used. Some of the encryption algorithms supported are AES, 3DES and RC4 and some of the integrity algorithms supported are MD5, SHA1 and SHA-256 [5]. TLS provide authentication by using certificates signed by a trusted Certificate Authority (CA). TLS has two main components, the Handshake Protocol and the Record Layer Protocol. The Handshake Protocol sets up the security parameters for a certain session. The Record Layer Protocol takes blocks from an application layer protocol and applies the required cryptographic operations of the current session [6]. Table 1: TLS Handshake Protocol Client ClientHello (Certificate) ClientKeyExchange (CertificateVerify) ChangeCipherSpec Finished Server ServerHello (Certificate) (ServerKeyExchange) (CertificateRequest) ServerHelloDone ChangeCipherSpec Finished 5

12 The steps of the Handshake Protocol represented in Table 1 will be briefly explained. First, the client sends a ClientHello message to which the server responds with a ServerHello. The two messages each contain a random value and establish the following session attributes: protocol version, session ID, cipher suite, and compression method. Next, the server sends its certificate if it is to be authenticated. After that a ServerKeyExchange can be sent if required. When the server is authenticated it may send a CertificateRequest to the client if the cipher suite specifies it. The ServerHelloDone indicates that the hello-phase is complete. The client responds with its certificate if requested. It then sends a ClientKeyExchange which contents depend on the selected cipher suite. A CertificateVerify may be sent in order to verify that the client possesses the private key of it s certificate. In the final steps of the protocol the client sends a ChangeChipherSpec which indicates that all subsequent messages will be sent using the negotiated cipher suite. It then sends a Finished message which is tied to the session by hashing the previous messages. Finally the server responds in the same way and the handshake is complete. TLS supports three ways of authentication: authentication of both peers, authentication of only the server and no authentication. An anonymous key exchange can use Diffie-Hellman (a method for exchanging cryptographic keys over a public channel), however this only protects against passive eavesdroppers. Diffie-Hellman can also be used with authentication. The necessary parameters for key exchange are set up either by using fixed parameters in the servers certificate or by using the ServerKeyExchange message. A user that wants forward secrecy should use a cipher suite that uses ephemeral Diffie-Hellman [5]. TLS can also use RSA which combines both key exchange and server authentication. The public key is located in the server s certificate. The Record Layer protocol uses a connection state that specifies a compression algorithm, an encryption algorithm (providing confidentiality) and a MAC algorithm (providing integrity). When the record layer sends a message it fragments it (and optionally compresses it), applies a MAC and encrypts it according to connection state. When a message is received it is also procesed by the Record Layer. The message is decrypted, the MAC is verified and lastly reassembled to be delivered to the appropriate application. 2.4 IPsec - Internet Protocol Security IPsec is a protocol suite that provides security to Internet Protocol (IP) communication. It operates in the network layer and provides transparent security upper layer protocols, meaning that they do not have to be aware that they are protected. But due to the layered structure this means that it cannot adapt the type of protection to different applications. IPsec does not provide user-touser or application-to-application security, only host-to-host. IPsec violates the TCP/IP model since it requires a shared state of the secure channel [6]. 6

13 Figure 2: IPsec in the TCP/IP stack. IPsec has two protocols that provide the secure services: Authentication Header (AH) and Encapsulation Security Payload (ESP). ESP support must be implemented but AH support is optional. AH provides origin and integrity authentication as well as replay attack protection. ESP provide the same services as AH but also confidentiality [7]. AH and ESP can be used individually or in combination but the IETF recommends that ESP should always be used [8]. IPsec can be used in two modes: transport and tunnel. In transport mode both AH and ESP only protect the protocols from the above layer. In tunnel mode AH and ESP are applied to the entire IP packet. The tunnel mode can be used when communicating with a host behind an IPsec-enabled gateway. Figure 3: The IPsec modes. How an IP packet is to be processed is determined by a Security Policy (SP) stored in a Security Policy Database (SPD). An SPD entry contains a number of fields such as destination address, source address and Security Parameters Index (SPI). It also contains one of three actions: Protect, Bypass or Discard. If an outgoing packet is to be protected, IPsec looks for a matching Security Association (SA), using for example the SPI, in the Security Assication Database (SAD). An SA contains information regarding which security parameters (algorithms, keys) that is used when sending packets in one direction. SAs can also be combined for nested IPsec tunnels. If there is no matching SA a new one can be created or the packet is discarded. After the packet is protected it is either processed further or sent to the link layer. When an IP packet is received it is examined and put into one of two categories. If the packet is not protected the 7

14 SPD is searched for an appropriate action, Bypass or Discard. If it is protected the SAD is searched instead, using the SPI and additional optional information, for a matching entry. The packet is processed according to the SA and then either further processed or sent to the transport layer. (a) Outbound traffic (b) Inbound traffic Figure 4: IPsec processing IPsec can use the Internet Key Exchange (IKE) protocol to automatically set up an SA [9]. It can do mutual authentication and uses Diffie-Hellman as the key establishing method. IKE sets up an IKE SA which can be used to create SAs for both ESP and AH. As explained previously, AH offers integrity and ESP offers both integrity and confidentiality. IPsec supports a wide range of cryptographic algorithms. The following algorithms presented are based on the guidelines by the IETF [10]. The authenticated encryption algorithm providing both security and integrity is AES-GCM. The encryption algorithms providing confidentiality that can be used by ESP (in order of recommendation) are AES-CBC, AES-CTR, TripleDES- CBC and DES-CBC. However the use of DES-CBC and TripleDES is not recommended since the first one is considered easy to break and the second one is not safe due to its small block size when encrypting large amounts of data [10]. The authentication algorithms providing integrity that can be used by both ESP and AH are (in order of recommendation) HMAC-SHA1-96, AES-GMAC wiht AES-128 and AES-XBC-MAC-96. Both confidentiality and integrity are optional in ESP but IPsec without any of them serves no purpose. In order to achieve the best security either authenticated encryption or a combination of an encryption and an authentication algorithm must be used. 8

15 2.5 Attacks This section describes the attack models that relates to sections 4.1 and 4.2. Man-in-the-middle attack An attacker captures and reads messages from the sender, possibly modifies them and then sends them to the receiver. The sender and receiver are unaware of the attacker in the middle [2]. Replay attack Valid data is captured by a malicious entity that then retransmits it in order to trick the receiver. Authentication data can be captured allowing the attacker to masquerade as someone else [11]. Downgrade attack An attacker tries to downgrade a higher quality encrypted connection to a lower one in order to exploit its weaknesses. This often exists due to backwards compatibility [11]. Oracle attack An oracle is a vulnerability inside a system that gives an indication of an attackers sucess. An oracle attack could be directed for example at the padding of a cryptographic message and where the oracle tells whether or not the padding is correct [12]. Denial of Service attack A denial of Service (DoS) attack is an attempt to block the availability of a resource or service. The effect of a DoS can be either temporary or permanent [2]. Known plaintext attack The attacker has at least one sample of both the plaintext and the corresponding ciphertext. They can be analyzed in order to reveal information about the cipher key [2]. This kind of attack was used the break the enigma code during the second world war. Ciphertext-only attack The attacker has only ciphertexts and the goal is to find the corresponding plaintexts. Often the attacker has information regarding the plaintexts such as language or occurrence of certain characters. The attacker might also want to find the cipher key [2]. Chosen Plaintext attack The attacker can obtain the ciphertexts for certain known plaintexts. The attackers goal is to analyze the ciphertexts in order to find the cipher key. This attack is more powerful than known plaintext attack because the attacker can obtain and analyze multiple pairs of plaintexts and ciphertexts [2]. 9

16 3 Method In order to achieve the primary objective of this report a systematic literature review was used. The review process is described in detail in section 3.1. The method used to create the secondary objective (proof-of-concept) is described in section Systematic literature review The literature review process followed the guidelines provided by Kitchenham [13]. It is used in order to summarise the existing information about the benefits and vulnerabilities concerning the subject. First of all Wikipedia was used in order to get an overview of the subject and to aquire initial search terms. The aquired search terms were then used to search in the databases listed in Table 2. This was repeated for any additional search terms found in the process. These search terms were used for searching in all databases: Transport Layer Security TLS IPsec IKE (Internet Key Exchange) Vulnerability(ies) Attack(s) POODLE Oracle BEAST CRIME TIME BREACH FREAK Table 2: Search process documentation Data Source Electronic database Other sources Documentation IEEE Xplore Searched using the search terms Accessed: to Years covered: Scopus Searched using the search terms Accessed: to Years covered: ACM Digital Library Searched using the search terms Accessed: to Years covered: RFC Editor Searching for RFCs associated with IPsec and TLS Only the most updated RFCs Accessed: to Wikipedia Accessed: to Getting an overview and useful search terms 10

17 References in the papers found in the search process were also used in this review. 3.2 Proof-of-concept A proof-of-concept is an actualization of an idea in order to demonstrate its feasibility. The proof-of-concept was created as a dummy IPsec implementation in Java. The first step was to identity which IPsec vulnerabilities found in the review could be mitigated. That information was then used to create requirements for the proof-of-concept. A simple messaging application was used to send data via the Java IPsec between two Android phones. The traffic was sniffed at an intermediate node in order to show that the data was properly encrypted. 11

18 4 Results The first part of this section presents the vulnerabilties found in the systematic literature review. The second part lists the requirements for the proof-ofconcept, and the third part describes the proof-of-concept with simulated runs. 4.1 TLS vulnerabilities Some of the vulnerabilities in TLS exist due to the many ways to configure it and its multiple implementations. If a TLS connection uses no authentication of either parties, the channel is not protected against man-in-the-middle attacks. Anonymous Diffie-Hellman is therefore discouraged by the IETF because it cannot prevent man-in-the-middle attacks. If TLS is used without Diffie-Hellman key exchange it is often only necessary to aquire a server s private key in order to decrypt any messages sent to that server. Stolen keys have been used in combination with large-scale monitoring of servers. This can be mitigated by improved protection of the private key or by using forward secrecy [14]. A survey done in 2012 [15] showed that many implementations of SSL/TLS often performed certificate validation either incorrectly or not at all. This problem is likely still prevalent today Attacks This section describes a number of attacks that can target either specific TLS versions or all of them. Renegotiation attack This is a man-in-the-middle attack where the attacker creates a connection with a server and sends any traffic of choice. The attacker then hijacks a clients connection negotiations with the server and sends them over his already existing connection. The traffic sent on the new connection is encrypted and cannot be read by the attacker, but it makes the server believe that the initial traffic was also sent from the client. This opens up the possiblity for a range of attacks where the attacker masquerades as the client. This vulnerability exists in all versions of SSL and TLS but was fixed by an extension that cryptographically binds the renegotiaions [16]. This allows a server to separate an initial negotiation from a renegotiation. Many TLS libraries has implemented the extension. BEAST BEAST stands for Browser Exploit Against SSL/TLS and is directed against TLS 1.0. It exploits a weakness in CBC that makes it possible to predict the IV. When a TLS 1.0 session sends multiple packets the subsequent packets uses the last ciphertext block of the previous packet as an IV. This means that an attacker can for example find the IV for the session cookie (due to its predictable 12

19 location) [14]. This attack is not feasible and was mitigated in TSL 1.1 and in several browsers as well but if a server still support TLS 1.0 or even SSL 3.0 this attack can be made after a downgrade attack. POODLE POODLE (Padding Oracle On Downgraded Legacy Encryption) is a man-inthe-middle attack that targets the CBC padding in SSL 3.0. The vulnerability exists because the padding does not have to have a particular format and is not covered by the MAC. This means that the padding integrity cannot be verified during decryption. If a message contains for example a whole block of padding (where the last byte specifies the amount of padding) the attacker can replace that block with another and then send it to the server. The server first decrypts the message, then removes the padding and lastly checks the MAC. If the last byte of the replacement block matches the last byte of the padding block the message will be accepted, otherwise it will probably be rejected. This type of behaviour creates a padding oracle. If the message is accepted the attacker knows the last byte of the replacement block and can continue in a similar way to extract more bytes. The attack requires only 256 tries (the number of variations of a single byte) on average in order to extract one byte of encrypted data. This vulnerability can be mitigated by disabling SSL 3.0 support [17]. The POODLE attack can also affect subsequent TLS versions that does not implement proper padding checks. Lucky 13 This is a padding oracle and timing attack that allows a man-in-the-middle to extract plaintext when CBC encryption is used. TLS uses a MAC to authenticate and provide integrity. The best way to use this is to encrypt first and then apply the MAC. However TLS applies the MAC first and adds padding before the encryption. Upon decryption the padding is validated and removed and then the integrity of the data is checked with the MAC. In TLS 1.2, if the padding is invalid it checks the whole message (including padding) against the MAC. This means that the MAC calculation takes a tiny bit longer, which can be detected. The attacker can then use the timing information as a padding oracle. This attack is sensitive to network jitter and likely requires several days which makes it less feasible. The Lucky 13 attack was mitigated by an extension to TLS that uses encrypt-then-mac instead [18]. It can also be prevented by using authenticated encryption. RC4 biases RC4 is a stream cipher that is supported by TLS and it is often used by servers. Because it is a stream cipher it is immune to BEAST and was considered a cure. However this cipher has been shown to have several weaknesses which are on the way to being easily exploited. It has been shown that the RC4 keystream contains biases for the first 256 bytes that make it possible to extract the plaintext 13

20 of about the first 200 bytes of an encrypted message [19]. This is accomplished by first encrypting the same plaintext (approximately 2 28 to 2 32 times) using different keys. The attacker then tries the 256 different plaintext options for each byte and XORs them with the ciphertexts in order to gather statistics concerning the keystream biases. The statistics are then used to recover plaintext by assuming that the correct one most closely matches the known biases. This is not a practical attack due to the large number of connections needed but future improvements can make them feasible. Another attack has been created that uses biases that appear at regular intervals in the keystream. This attack can use a plaintext that is encrypted by the same key and can be used to extract the plaintext at any position. Because of these vulnerabilities the cipher suites using RC4 is prohibited by the IETF [20]. CRIME CRIME (Compression Ratio Info-leak Made Easy) exploits TLS encryption in order to discover secret information such as session tokens. The attacker has to be able to intercept the victims network traffic and to make the victims browser send requests. A request contains a guess of the secret information (present in the same request) the attacker wishes to reveal. Due to the properties of compression the requests that contain the best guess will have a smaller size. By performing repeatedly improved guesses the attacker can uncover the secret information. This attack is feasible on all browsers and servers that support TLS compression. It can be mitigated by disabling TLS compression and that has been done in most browser and server software. TIME TIME (Timing Info-leak Made Easy) is a chosen plaintext attack that uses the same model as CRIME to target HTTP responses. It uses the characteristics of HTTP compression together with information about the time it takes to send different packages. The attacker has to be able to make the victim s browser send requests that fill the entire TCP window and to send messages that contain a guess of the secret information that the attacker wishes to reveal. If a guess is wrong it will create a package that does not fit in the window which adds a Round Trip Time delay. This delay can be measured and used in order to make better guesses. This attack does not rely on any vulnerability in TLS but can still be used to break it. TIME can be mitigated by not allowing sensitive user information to be reflected in the responses or by using anti-automation techniques like CAPTCHA [21]. BREACH BREACH (Browser Reconnaissance and Exfiltration via Adaptive Compression of Hypertext) also targets HTTP compression and uses the same approach as CRIME. This attack also uses the victims browser to send requests containing a guess of the secret information but relies on that the responses reflect the users 14

21 input as well as containing the secret information in the body. As with CRIME the smallest response contains the best guess. Since BREACH targets HTTP compression all versions of TLS are vulnerable and it does not matter which cipher suite is used. The BREACH attack can even be executed with only a few thousand request in under a minute. There are currently no known TLS mitigations towards this attack [22]. FREAK FREAK (Factoring RSA Export Keys) is a recently discovered vulnerability in TLS. It makes it possible for a man-in-the-middle to make TLS session use weak encryption (512 bit or smaller RSA keys). These keys are called export-grade and were introduced due to pressure from the US government in order to ensure that they could decrypt foreign encrypted communication. These weak ciphers can easily be broken by an attacker. As of March 2015 vendors are currently working on patches that fixes this vulnerability [23]. DoS TLS is vulnerable to a number of DoS attacks. An attacker can create a large number of TCP connections to server causing it to perform many simultaneous decryptions. This uses a lot of CPU and can overload the system. Because TLS uses TCP it is also susceptible to DoS attacks that target TCP. The IETF recommends that someone who is concerned about these attacks should use IPsec instead [5]. 4.2 IPsec vulnerabilities Most of the vulnerabilites explained in this section exists because of IPsecs flexibility. This flexibility makes it possible for users to create insecure implementations Attacks This section describes four different attacks that can target IPsec. three attacks take advantage of ICMP in order to attack IPsec. The first Packet too big - Packet too small This attack exploits ICMP in combination with IPsec in tunnel mode in order to create a DoS attack against an IPsec gateway. The attacker first forges an ICMP Package Too Big-message (based on eavesdropped traffic) that contains a very small MTU. This packet makes the gateway lower its MTU size which forces fragmention of larger packets. Depending on the implementation of Path MTU Discovery (a technique for finding the MTU on a network path) in a host 15

22 behind the gateway the attacker can either completely block certain connections such as TCP (because of IPsec tunnel headers) or severily reduce the gateway s overall throughput. This attack exists because of two issues: It is impossible for IPsec to determine if the ICMP message is legitimate or not if the attacker is on the path of the IPsec tunnel. The software that determines the MTU on the host does not take into consideration the additional headers applied in tunnel mode [24]. MAC-then-encrypt In this scenario IPsec is used between two gateways and is configured to use AES-CBC and first apply AH in transport mode and then ESP in tunnel mode. This makes it possible for an attacker to launch an ESP Trailer Oracle attack. The oracle tells whether or not the ESP trailer field of a packet is correctly formatted. The attacker also needs a packet which is used to produce the necessary responses from the oracle. This is called a carrier packet. The attacker splices ciphertext bytes (protected by the same key as the packet) together with some random bytes onto the end of the carrier packet and sends it to the oracle. The attacker varies the random bytes until the oracle responds positively. The attacker can then extract the plaintext bytes. This attack can be performed in several ways with and without AH replay protection: 1: A known-plaintext attack using and IMCP echo request as the carrier packet. 2: Because the Time To Live (TTL) and checksum fields are not protected by the AH they can be manipulated. By reducing the TTL to 0 and correcting the associated checksum of an intercepted packet an ICMP response can be produced. This packet is used as the carrier packet. 3: By spoofing a packet fragment, upon reception the AH protocol will wait for additional fragments leading to a time-out. This error message can then be detected and the fragment that caused the error can be used as carrier packet. If the implementation of IPsec uses an MAC-then-encrypt configuration this attack is feasible. By using only ESP with integrity protection this attack can be totally avoided [25]. Encryption-only It has been shown that an implementation of ESP using only encryption is vulnerable to several kinds of attacks. This is backed up by the IETF guidelines [10]. It has been shown by Bellovin [26] that IPsec with incorrect checks of encryption padding are vulnerable to chosen-plaintext attacks. The attacks presented by Degabriele and Paterson [27] rely on that the IPsec implementation follows the IPsec RFC guidelines and uses a full padding check. The attacks are ciphertext-only and the attacker only needs to be able to eavesdrop on the encrypted channel and inject packets. The attacks target the fields (Option and Protocol) in an IP packet. By manipulating the fields ICMP messages will be triggered with a high probability. These messages can be used in a padding oracle attack. These attacks can target ESP using encryption-only in both 16

23 tunnel mode and transport mode. They are, according to the authors both realistic and efficient. These attacks exist because the standards do not prevent users from creating a weak IPsec configuration. A second research group has created similar attacks that target the Next Header field and the Hop Limit field [28]. IKE If an implementation of IPsec is using IKE it is affected by additional vulnerabilities associated with the IKE protocol. If the Diffie-Hellman secret values are being reused they can be targeted by a timing attack. By analyzing how much time it takes to perform the key operations an attacker can deduce what the secret values are. This can be mitigated by introducing a blinding factor that masks the computation time [29]. The first exchanges in IKE (IKE SA INIT and IKE AUTH) are executed before the initiator is authenticated. This can be used in order to perform a DoS attack. If IKE messages are large enough to cause IP fragmentation it is possible for an attacker to mount a DoS attack by filling the IP reassembly buffers with only partial fragments. Several ways that this can be mitigated are discussed in [30]. If IPsec is used in combination with the Extensible Authentication Protocol (an authentication framework used in wireless networks and point-to-point connections) but without the use of a protected tunnel, man-in-the-middle attacks are possible. They can be prevented by cryptographically binding the tunneling protocol with the authentication protocol or by using a protected tunnel [9]. 4.3 Proof-of-concept requirements From the found IPsec vulnerabilities three requirements for the proof-of-concept were identified, the first concerning ESP and AH, the second concerning the cryptographic algorithm used and the third concerning the key exchange ESP-only The MAC-then-encrypt vulnerability can be avoided by either always applying AH after ESP or by using only ESP. The first requirement was that the proofof-concept should be configured as ESP-only Authenticated encryption AES-GCM provides both confidentiality and data origin authentication [31]. By using this algorithm in combination with ESP the proof-of-concept is immune to the Encryption-only attacks. The second requirement was that the proof-ofconcept should use AES-GCM. 17

24 4.3.3 Face-to-face key exchange By using Near Field Communication (NFC) as key exchange during the IPsec setup between two peers the vulnerabilites concerning IKE can be avoided. NFC typically requires a distance of 4 cm or less which makes man-in-the-middle attacks very impractical, unless some malicious software is already installed on the device. This means however that the two peers have to meet in person in order to setup the secure link. The third requirement was that the proof-ofconcept should use NFC to exchange keys. 4.4 Proof-of-concept The proof-of-concept created is an Android application called KandidatBox, which is a sandbox environment that simulates the operations of IPsec. It has its own SPD and SAD as well as classes for creating sending sockets and receiving sockets. An overview of the communication between two devices using KandidatBox can be seen in Figure 5. Figure 5: KandidatBox communication In order for an application to send or receive data inside KandidatBox the required SPs and SAs need to be created. In order to create the SPs (one for incoming traffic and one for outgoing traffic) the two peers first have to choose which action is to be taken: Discard Drop all packets matching the entry. Bypass Forward packets without encrypting or decrypting. Protect Encrypt or decrypt the packets before forwarding. 18

25 The target port number and target IP also need to be specified. The IP addresses are exchanged by putting the devices back to back and sending the addresses using NFC. If the action was Protect, the peers need to create the necessary SAs (incoming and outgoing). For this they first have to choose which encryption algorithm to be used. KandidatBox only supports AES-GCM which is provided by Spongy Castle [32], an Android port of Bouncy Castle, a collection of cryptographic APIs. Next, they each generate a cryptographic key. These keys are used to encrypt and decrypt data going in one direction. The keys are also exchanged using NFC. The peer s own key is used to encrypt outgoing traffic and the received key is used to decrypt incoming traffic. Figure 6: KandidatBox environment An application exists inside KandidatBox by using the two classes BoxSender and BoxReceiver for network communication (see Figure 6). Those two process incoming and outgoing packets similarily to real IPsec (see section 2.4). When BoxSender sends data the SPD is accessed in order to find the appropriate action. If the data is to be protected it finds the corresponding SA containing SPI, algorithm and key. It then generates a cryptographically secure and pseudo-random IV using Javas SecureRandom class and uses the IV together with the key to encrypt the data. BoxSender then concatenates the SPI with the IV and the encrypted data together with a 3 byte header indicating that the data is encrypted. When receiving a packet, BoxReceiver checks for the existance of the protection header. If found, it extracts the SPI and looks up the corresponding SA. BoxReceiver then extracts the IV and the encrypted data and decrypts the data using the IV and the key from the SA. If BoxSender or BoxReceiver does not find a matching SP or SA the data is simply discarded. 19

26 4.4.1 Simulated run In order to demonstrate the proof-of-concept a simple messaging application was created. The application sends text messages to a specified IP address. To show that KandidatBox operates as explained two SPs were created, one for bypassing messages and one for protecting messages with a belonging SA (see Table 3). Table 3: SPD and SAD SPD IP Direction Port Action SPI out Bypass out Protect 1 SAD SPI Algorithm Key 1 AES (128bit key) The messaging application was used to send a message containing the word Hello to each of the IP addresses in the SPD. The traffic was sniffed at the connected access point using tcpdump, a command-line packet analyzer [33]. Table 4 shows a bypassed packet. It has a payload length of 5 bytes which is equals to the length of the message. It is possible to read the plaintext message that was sent at the bottom right corner. Table 4: Bypassed packet containing Hello > : [udp sum ok] UDP, length 5 0x0000: 45c0 003d 625f d c0a E..=..@..M...g 0x0010: c0a8 019c f o.... E..! 0x0020: b678 c0a8 019c x g 0x0030: e 000d c6c 6f H e l l o Table 5 shows a protected packet. The payload length is 44 bytes which means that it contains some additional data other than the message. This data consists of the 3 byte protection header, a 4 byte SPI, a 16 byte IV and the 5 byte long encrypted message with a 16 byte Integrity Check Value (ICV) which is the AES-GCM Authentication tag (see Figure 7). Since the message is encrypted it cannot be read. For this example the encryption payload is much larger than the actual message. However, the extra payload remains the same size even though the message becomes larger. 20

27 Table 5: Protected packet containing Hello > : [udp sum ok] UDP, length 44 0x0000: b601 c0a8 019c 0x0010: c0a8 01b e d9d x0020: b0 f3c0 23c0 ffcf ed9f 5a #.... Z!. 0x0030: b0c4 a86e 3e33 ee8f 44c1 f1a3 3f8d 361a...n > 3.. D...?. 6. 0x0040: ca86 7a4e c45e 621b.. z N. ˆ b. Figure 7: Protected packet If the message is somehow tampered with by a man-in-the-middle attacker the decryption process will fail and throw either an IllegalBlockSizeException or a BadPaddingException. This is thanks to the integrity protection provided by GCM. 21

28 5 Discussion This section reviews the methods used and the derived results. It also puts the concept of secure communication in an ethical and social context. 5.1 Method It was not easy finding information about the vulnerabilites, especially concerning IPsec. This could mean that either IPsec is more secure than TLS or that less research in that area is done. Regarding TLS, most vulnerabilities found affect previous versions. The latest version is definitely the most secure but it probably has vulnerabilties that has not been detected yet. Initially, attempts were made to compile two different IPsec applications, IPsec- Tools [34] and strongswan [35], to run natively on Android. However, the attempts failed because of compilation errors that could not be dealt with. If the attempts were successful it would have meant that all network communications on a device could be protected. In that situation it would be unnecessary for developers to develop inside a sandbox environment, such as KandidatBox. The RFCs cited in the report are the latest versions published by the IETF. Most of the other sources are cited either in the RFCs or in other papers. 5.2 Results Some of the vulnerabilities found do not lie in TLS or IPsec but in their interactions with other protocols. This means that if a user wants to have the most secure implementation possible the user has to investigate vulnerabilties outside the scope of only TLS or IPsec. An indirect vulnerability that exists in both protocols, especially in IPsec, is the fact that they are allowed to be configured to operate insecurely. In order to mitigate this vulnerability the protocols need to include more security restrictions. Even though the proof-of-concept was created with Java and operates in the application layer it does not include any extra security services that do not exist in IPsec, apart from NFC. 5.3 A broader perspective Information security on the web is very important. Today, when our communication on the Internet is increasingly monitored the services provided by TLS and IPsec are necessary for personal integrity and secrecy of correspondence. 22

29 Hopefully, this report gives insight into how to implement TLS and IPsec securely in order to support these fundamental rights. However, even though the confidentiality provided by TLS and IPsec can protect the communications of businesses and common people, it can also be used by criminals in order to conceal their activities. 23

30 6 Conclusion Both TLS and IPsec are good alternatives for secure communication providing confidentiality, integrity and availability, if implemented correctly. Note however, that a secure protocol is only as strong as its weakest link. Insecure elements such as unauthenticated traffic and short cryptographic keys should be avoided and secure elements such as reliable cryptographic algorithms and trusted certificate authorities should be used. TLS is easier to implement but only provides application-to-application security. In order to achieve high security with TLS, RC4 should be avoided and only the most recent version of TLS with the latest patches should be supported. Because most of the TLS vulnerabilities affect earlier versions so you have to weigh compatibility against security. IPsec operates between hosts and can provide security for any IP communication between hosts. It has a high configurability which makes it more difficult to implement securely. Some of the IPsec vulnerabilities found in the literature review can be mitigated by using only ESP with an algorithm using authenticated encryption. The proof-of-concept shows that the threat of a man-in-the-middle attack can be lessened using NFC and that IPsec is a way to setup secure communication on an ad hoc network. 24

31 References [1] S. Turner and T. Polk, Prohibiting secure sockets layer (ssl) version 2.0, RFC 6176, RFC Editor, March [2] M. Bishop, Computer Security : Art and Science. Addison Wesley, [3] J. Davies, Implementing SSL/TLS Using Cryptography and PKI. Indianapolis: John Wiley & Sons, Ltd, 1 ed., [4] J. Postel, Internet control message protocol, STD 5, RFC Editor, September [5] T. Dierks and E. Rescorla, The transport layer security (tls) protocol version 1.2, RFC 5246, RFC Editor, August [6] D. Gollmann, Computer Security. Chichester, West Sussex: John Wiley & Sons, Ltd, 3 ed., [7] S. Kent, Ip encapsulating security payload (esp), RFC 4303, RFC Editor, December [8] S. Kent and K. Seo, Security architecture for the internet protocol, RFC 4301, RFC Editor, December [9] C. Kaufman, P. Hoffman, Y. Nir, P. Eronen, and T. Kivinen, Internet key exchange protocol version 2 (ikev2), STD 79, RFC Editor, October org/rfc/rfc7296.txt. [10] D. McGrew and P. Hoffman, Cryptographic algorithm implementation requirements and usage guidance for encapsulating security payload (esp) and authentication header (ah), RFC 7321, RFC Editor, August [11] E. Rescorla and B. Korver, Guidelines for writing rfc text on security considerations, BCP 72, RFC Editor, July [12] J. Coombs, Understanding oracle attacks on information services, December , Accessed [13] B. Kitchenham, Procedures for performing systematic reviews, Keele, UK, Keele University, vol. 33, p. 28, [14] Y. Sheffer, R. Holz, and P. Saint-Andre, Summarizing known attacks on transport layer security (tls) and datagram tls (dtls), RFC 7457, RFC Editor, February [15] M. Georgiev, S. Iyengar, S. Jana, R. Anubhai, D. Boneh, and V. Shmatikov, The most dangerous code in the world: validating SSL certificates in non-browser software, Proceedings of the 2012 ACM conference on Computer and communications security - CCS 12, p. 38, [16] E. Rescorla, M. Ray, S. Dispensa, and N. Oskov, Transport layer security (tls) renegotiation indication extension, RFC 5746, RFC Editor, February rfc-editor.org/rfc/rfc5746.txt. [17] B. Moeller, T. Duong, and K. Kotowicz, This POODLE Bites: Exploiting The SSL 3.0 Fallback, Accessed: [18] P. Gutmann, Encrypt-then-mac for transport layer security (tls) and datagram transport layer security (dtls), RFC 7366, RFC Editor, September rfc-editor.org/rfc/rfc7366.txt. [19] N. AlFardan, D. J. Bernstein, K. G. Paterson, B. Poettering, and J. C. N. Schuldt, On the security of rc4 in tls, in Presented as part of the 22nd USENIX Security Symposium (USENIX Security 13), (Washington, D.C.), pp , USENIX, [20] A. Popov, Prohibiting rc4 cipher suites, RFC 7465, RFC Editor, February http: // 25