Linux Solution Overview – MITM Attacks and SSL/TLS

Ensuring the security of communication channels is one of the most challenging problems in modern software development. A compromised communication channel may lead to the leakage of sensitive information and therefore cause significant damage to users.

This article provides an overview of the principles behind man-in-the-middle (MITM) attacks — a popular type of attack used for intercepting and altering data. It focuses on active MITM attacks, man in the middle attack prevention, and takes a closer look at one tool that may be used for performing MITM attacks — SSLsplit.

Man-in-the-middle (MITM) attacks: definition and origins
MITM and SSL/TLS: how it works
SSLsplit: a deeper look
Main caveats of SSLsplit
Data plane frameworks for fast packet processing
Conclusion

Man-in-the-middle (MITM) attacks: definition and origins

What is a man in the middle attack (MITM)? It’s an attack in which there’s an eavesdropper in a point-to-point communication channel between two parties. If performed successfully, an MITM attack allows the attacker to sniff and alter data transmitted over the compromised channel.

One of the first mentions of a man-in-the-middle attack can be found in Gerald H. Larsen’s Software: A Qualitative Assessment, or The Man in the Middle Speaks Back in the November 1973 edition of Datamation. In 1981, Leslie Lamport published his article Password Authentication with Insecure Communication, in which he also writes about ways of protecting against an MITM attack.

In the context of encrypted communication, MITM attacks are possible and easy to implement when there’s no trusted certificate authority (SSL/TLS) that can be used to authenticate both parties.

Standard man in the middle attack examples will help you get a better understanding of the process. Let’s look at a simple example of an attack where an eavesdropper is able to read and alter plain data in the encrypted session even when an asymmetric cryptographic algorithm is used.

Let’s assume that two parties wish to communicate with each other. We’ll call them Anna and Rob. A third party, Melody, wants to intercept the communication between Anna and Rob.

1. Anna asks Rob for his public key and Rob sends it.

2. Melody intercepts Rob’s message, replaces his public key with her own key, and then sends the message to Anna.

3. Anna receives Melody’s public key, believing it belongs to Rob. She encrypts her next message with this key and sends it to Rob.

4. Melody once again intercepts the message. Since she has the key, Melody can decipher Anna’s message and alter it if she wants. Then, Melody re-enciphers the message with Rob’s public key and sends it back to Rob. Rob receives the newly enciphered message, believing it came from Anna, and decrypts it using his private key.

In this case, both Anna and Rob are convinced that they’re communicating securely with each other and don’t know that Melody has intercepted their communications and is able to alter their messages.

Now let’s take a closer look at how exactly MITM attacks can intercept an SSL/TLS session.

MITM and SSL/TLS: how it works

There are two types of MITM attacks: passive and active. Passive MITM attacks rely on traffic decryption using a server’s private keys. These attacks are only possible when RSA keys are used and the eavesdropper has access to them (which really narrows the possible vector of the attack).

The main idea of an active MITM attack is based on splitting an SSL/TLS session into two fully separate sessions. As a result of the attack, these two sessions will have different session keys and may also use different cipher suites and protocol versions.

Suppose that we have a transparent proxy that intercepts all SSL traffic forwarded through it from a client PC to a server, as shown in Figure 1 below.

Figure 1. An SSL/TLS connection

When the client tries to establish an SSL/TLS session, the proxy server hijacks it. To gain control over the session and start eavesdropping or altering data, the proxy performs the following steps:

When the proxy server intercepts the TLS ClientHello from the client, it starts the second session using the same Server Name Indication (SNI) value.
The proxy server initiates a handshake procedure with the initial server, providing its own ClientHello.
After the handshake has successfully finished and a secure connection has been established, the TLS proxy server uses the original server certificate to generate a new X.509v3 on-the-fly, copying data from the original certificate fields and signing it with its own private key.
The TLS proxy server finishes the handshake for the original session with the client.

Take a look at Figure 2 below to get a better understanding of how active MITM interception works.

Figure 2. SSL/TLS MITM active interception

Now, two sessions have been established. The only way the client can see that the session has been hijacked is to check the server certificate signature. However, the user is unlikely to receive any verification errors if the storage of the root certificate has been tampered with (which could be done, for example, by big enterprises as a security measure and a precaution against intellectual property loss).

Currently, there are two open-source projects that can be used for intercepting TLS/SSL traffic using the technique we’ve described: SSLsplit and MITMproxy. Next, we’ll focus on how to use SSLsplit.

Related services

Engineering for Cybersecurity Projects

SSLsplit: a deeper look

SSLsplit is a tool that can be used for performing MITM attacks against network connections encrypted with SSL/TLS. SSLsplit can be useful for penetration testing and application and network security analysis, and therefore, may help prevent man in the middle attack.

Using a NAT (network address translation) engine, SSLsplit transparently intercepts and redirects SSL/TLS encrypted connections. Then, SSLsplit starts new SSL/TLS connections to the initial destination addresses. Further, SSLsplit logs all the data transmitted through the encrypted network.

SSLsplit supports several types of connections over IPv4 and IPv6:

Plain TCP
Plain SSL
HTTP
HTTPS

In the case of SSL and HTTPS connections, SSLsplit generates forged X.509v3 certificates on-the-fly. It can sign them using data taken from the subject DN and subjectAltName extensions of the original server certificate.

In addition, SSLsplit fully supports Server Name Indication (SNI). It works with three kinds of keys (RSA, DSA, and ECDSA) and two kinds of cipher suites (DHE and ECDHE). Depending on the version of OpenSSL, SSLsplit may support the following versions of cryptographic protocols:

TLS 1.0
TLS 1.1
TLS 1.2
SSL 3.0

Optionally, SSLsplit supports SSL 2.0 as well.

SSLsplit is commonly used on L3 routers with NAT. However, it’s also possible to set up an L2 bridge between two segments of the same network. We’ll explain how this scheme works in practice.

Let’s assume we have a PC with two network interface controllers (NICs) that connect two segments of the same network. Basically, this PC plays the role of a simple L2 bridge. All packets arriving to eth0 are automatically forwarded through eth1 and vice-versa.

First, let’s create a simple bridge:

ShellScript

#!/bin/bash
ETH0=eth0
ETH1=eth1
BR=br0
IP=192.168.1.200
GW=192.168.1.1
brctl addbr $BR
brctl addif dev $ETH0 $ETH1
ifconfig $ETH0 up
ifconfig $ETH1 up
ifconfig $BR up

Now, traffic should go transparently through our PC. To be able to start an SSL/TLS interception, we can forward all TCP packets that have destination port 443 from FORWARD PATH to INPUT PATH and receive data on the local listening socket (8443). We can do this using the iptables tool:

ShellScript

#!/bin/bash
ETH0=eth0
ETH1=eth1
BR=br0
iptables -t nat -F
iptables -t mangle -F
iptables -F
ebtables -t broute -F
ebtables -t broute -A BROUTING -i $ETH0 -p ipv4 --ip-proto tcp --ip-dport 443 -j redirect --redirect-target ACCEPT
iptables -t nat -A PREROUTING -i br0 -p tcp --dport 443 -j REDIRECT --to-port 8443

Then we’re ready to start SSLsplit:

ShellScript

$ ./sslsplit 
  -D 
  -l connections.log 
  -j /tmp/sslsplit/ 
  -S logdir/ 
  -k ca.key 
  -c ca.cer 
   ssl 0.0.0.0 8443 
   tcp 0.0.0.0 8080

All TCP packets that have destination port 443 are now automatically forwarded to the local 8443 listening socket.

While SSLsplit can be used for research purposes, it cannot protect against the MITM attack, so using this tool within a big corporate network isn’t the best idea. Next, we’ll talk about some of the crucial problems you may face when using SSLsplit.

Main caveats of SSLsplit

While being a helpful and informative tool for penetration testing and network security analysis, SSLsplit is more of a toy than a comprehensive solution that you can use in a big corporate network for handling huge throughputs. Unfortunately, it has three major caveats.

1. 5-tuple management

It’s hard to reach a decent performance level with 5-tuple handling when it comes to the Linux kernel network subsystem, replacing L2/L3/L4 headers on-the-fly (source IP address, source MAC address, etc.) for all TCP packets within the server session with appropriate values from the client session and vice versa.

Although Netfilter provides all capabilities (using usermode apps ebtables/iptables) for 5-tuple management, adding a rule for each new TCP session can lead to a huge increase in context switches (user mode — kernel mode calls), resulting in high latency and throughput degradation.

Linux offers to use RAW sockets, but in this case we would have to build our own TCP/IP stack on top of Linux RAW sockets to be able to construct an L2 frame with appropriate headers.

This feature is vital for eliminating any suspicions from IDS/IPS/firewall software or if TLS/SSL interception is done deliberately and is a planned part of a company’s IT infrastructure (to protect information assets, for instance), so we can feed IDS/IPS software with a correct 5-tuple.

2. TCP packets with plain data

Since IDS/IPS (intrusion detection system/intrusion prevention system) software is able to analyze and alter plain data, it should be possible to send all data not only as a debug log but also to encapsulate it into TCP packets with proper metadata. Only then will we be able to analyze traffic with the help of different IDS/IPS setups.

3. Performance issues

There are two possible performance bottlenecks:

Cryptographic operations and CPU utilization
Linux kernel networking latencies and memory utilization

Cryptographic operations and CPU utilization. Modern CPUs accelerate some cryptographic algorithms either explicitly, as with AES (Intel AES NI set of instructions), or implicitly, as with AVX-512, which demonstrates a huge impact on the secure hashing algorithms SHA-1, SHA-256, and SHA-512. Moving from Intel AVX2 to Intel AVX-512 implementations of the SHA family brings benefits beyond doubling of the number of data buffers that can be processed at once.

Unfortunately, it’s not enough to just accelerate cryptographic algorithms in order to handle thousands of TLS/SSL sessions. For these purposes, vendors (Intel and others) provide dedicated solutions like Intel QAT that can be used specifically for offloading cryptographic operations. Intel QAT is already integrated into the OpenSSL library (as a cryptographic backend) and doesn’t require any changes to the software you use.

Linux kernel networking latencies and memory utilization.The main problems here are the following:

Long and unpredictable latencies
Huge metadata size (SKB, Netfilter, TCP/IP) for each packet
Both user space and kernel space TLB entries
No support of hardware accelerators for packet handling/filtering
No huge pages support

Related services

Security Testing

Data plane frameworks for fast packet processing

As we mentioned earlier, performance issues and lack of control over packet (filtering packet payloads/altering headers, and so on) are the main concerns regarding the use of SSLsplit, MITMproxy, and similar products. And even though Netfilter iptables/ebtables utilities can enable some decent packet processing capabilities (particularly, by altering L2/L3/L4 headers), this can be done only at the expense of performance.

Thankfully, there’s a bit of a different approach that allows you to gain the power of low-level packet processing and keep performance at a high level. With the help of data plane frameworks, you can perform custom packet processing directly in the user mode application after arriving on an inbound interface. This approach helps eliminate many of the problems described in the previous section while providing some additional advantages:

High scalability — it’s possible to separate network traffic using different ingress/egress queues that can be handled by different threads.
Per-core resource management — specific cores can be allocated for latency-critical operations such as L2 forwarding of time-sensitive traffic.
Elimination of system call overhead — no kernel-user switches for each read/write operation on the socket.
Cache-aware threading model — helps to avoid cache misses, TLB misses, and so on.
Zero-copy input/output.

Currently, there are two major open-source projects that provide such capabilities: Intel DPDK and Linaro OpenDataPlane (ODP). While ODP is mostly used in embedded configurations and Linaro focuses on support for ARM SoCs, ODP can use Linaro DPDK as a backend for Intel-based NICs on x86 PCs.

Full TCP/IP stack support is the only major problem with using ODP or DPDK data plane frameworks, particularly when it comes to SSL/TLS handling. And unfortunately, there isn’t any open-source TCP/IP stack implementation on top of ODP or DPDK that boasts both reliability and full support for subsets of TCP/IP protocols.

We’ve performed additional research on one of the most popular open-source software projects called OpenFastPath (OFP). OFP is developed by industry giants including ENEA, Cavium, Marvell, and Nokia. Still, OFP has some serious pitfalls:

Limited support for epoll events (EPOLLOUT, EPOLLERR, and EPOLLRDHUP) and an inefficient implementation that more resembles a basic poll/select call than an epoll.
Strange issues in timer handling that lead to abnormal TCP ACK retransmits.
Inpcb lookup time (hash calculation with a high rate of collisions).
Abnormal packet drops while adding to socket buffers. After a little research, we discovered that the root cause is the logic of the reassembling queue, which collects out-of-order packets whose sequence numbers are higher than expected.
Huge memory consumption for each opened socket. In order to handle more than 800,000 connections, we need more than 64GB of RAM.

It will take you a lot of time and effort to make the OFP stack reliable for fast packet processing. Still, there’s a chance that all the pitfalls listed above will be fixed soon.

Conclusion

TLS/SSL is the biggest achievement in the world of security. And even though it provides a comprehensive and reliable MITM attack defense against attempts at eavesdropping and altering data, TLS/SSL is still prone to attacks. These attacks are easier to perform in enterprise networks where network administrators have full access to PCs and can easily mess with root certificates of your operating system.

And even though SSLSplit can perform simple MITM attacks on SSL/TLS and, therefore, may be used for research purposes, it’s not the best solution for testing large corporate networks because of performance issues. In order to gain control over packet headers and increase performance, you can use products like the ODP or DPDK data plane frameworks.

At Apriorit, we have a team of experienced professionals who can help you ensure that any network communications performed by your software are secured against MITM attacks. Just send a request for proposal and we’ll get back to you.

If you’re interested in a more in-depth look at low-level Linux development, check out our tutorial on creating Linux drivers here.