Tor exit nodes attempt to spy on encrypted traffic, researchers find

19 Tor exit relays used self-signed certificates to launch man-in-the-middle attacks against HTTPS and SSH connections

Computer scientists found almost 20 exit relays in the Tor anonymity network that attempted to spy on users' encrypted traffic using man-in-the-middle techniques.

The research was carried out over a period of four months by Philipp Winter and Stefan Lindskog, researchers in the PriSec (Privacy and Security) group at Karlstad University in Sweden, who recently published a paper with their findings.

The Tor network is designed to provide anonymity for users and bypass Internet censorship attempts. This is achieved by encrypting user traffic and routing it through a series of computers that act as relays and are run by volunteers before sending it to its intended destination on the Internet.

Computers that handle the final hop in the Tor network are known as exit relays. According to statistics from the Tor Project, there are about 1,000 such relays as of this month.

Even though connections between Tor relays are encrypted, traffic is returned to its original state when it leaves the network. This means that if it's not using SSL or another secure transport protocol, Tor exit relays can inspect it. That's why the Tor Project recommends the use of HTTPS -- HTTP with SSL encryption -- with all websites that support it, even if using Tor.

However, their man-in-the-middle (MitM) position allows Tor exit relays to tamper with HTTPS connections, using techniques like SSL stripping or impersonating the destination website using a rogue certificate.

The researchers built a scanning tool called exitmap that can identify exit relays behaving maliciously or abnormally and ran it on the Tor network. Over a four-month period they identified 25 bad relays that were subsequently reported to the Tor Project and blacklisted.

Fourteen relays engaged in man-in-the-middle HTTPS traffic sniffing using fake certificates, four relays did both HTTPS and SSH sniffing and one attempted only SSH sniffing. Two other relays used the sslstrip tool to force HTTPS connections over plain HTTP, one relay injected HTML code in HTTP traffic and three relays engaged in Internet censorship by blocking access to certain websites at the DNS level, intentionally or because of misconfiguration.

The relays engaged in HTTPS sniffing used self-signed certificates which lowered the attack's success rate because this triggered browser certificate errors that users would have had to manually dismiss. The Tor Project maintains and distributes a software package called the Tor Browser Bundle that contains a browser based on Mozilla Firefox and other components needed to access the Web over Tor.

The researchers believe the relays doing HTTPS or SSH traffic interception were operated by the same individual or group of individuals because they used very similar self-signed certificates, almost all of them were located in Russia on the network of a virtual private server (VPS) hosting provider and all of them ran an old version of Tor -- 0.2.2.37 -- that's uncommon among relays. Only two benign relays that used this same Tor version were identified during the scans.

The HTTPS sniffing relays did not target all connections passing through them. Their connection sampling rates varied between 12 and 68 percent, the researchers said in the paper.

They also only appeared to target connections to particular websites. For example, Facebook.com was targeted, but other sites in the Alexa top ten list or popular Russian social media sites were not.

It's possible the connection sampling and destination targeting techniques were intended to make the attacks harder to detect. However, it also made them a lot less effective, especially when also considering the certificate errors they triggered.

"We don't know how many users were actually tricked, but we don't think it's many because people wouldn't expect a certificate error if they go to Facebook," Winter said. "We tried to figure out what they were actually doing with this, so we set up a fake Facebook profile and logged into it through one of those malicious relays. We didn't see anyone logging in after us."

"I'm not even sure if they captured passwords," the researcher said. "Maybe it was just an experiment. It didn't seem like a very sophisticated and serious attack to us."

There's a possibility that the man-in-the-middle attacks happened upstream of the exit relays, on their ISP's network, for example. However, the researchers believe that's unlikely because there was one malicious relay with the same particularities that was located in the U.S., so in a different region and network. That suggests that the relays themselves were the source of attack.

While the number of victims is likely to be very small, this new research shows that Tor exit relays can and do get abused for malicious purposes.

The two researchers developed a patch for the Tor Browser Bundle in the form of a browser extension that informs users when a MitM attack is potentially in progress and offers the option to send an anonymous report to the Tor Project. When it detects a certificate error in the browser, the extension opens a connection to the destination site through a different Tor exit relay and compares the certificates received in both cases. If they differ, it was probably a man-in-the-middle attack attempt.

However, this approach does have limitations. For example, if an attacker controls a large number of exit relays and they're all set up for MitM HTTPS sniffing, the chances of detecting an attack by comparing certificates received over two exit relays decreases.

Also, the extension wouldn't detect MitM attacks that use fraudulently obtained certificates signed by trusted certificate authorities, as those certificates would automatically be trusted by browsers and wouldn't result in errors.

However, such certificates represent a risk for the entire Internet, not only Tor, Winter said. The solution should be something that fixes HTTPS as a whole, he said.

Fortunately, there are ongoing efforts to address this problem at the protocol level.

From CIO: 8 Free Online Courses to Grow Your Tech Skills
Join the discussion
Be the first to comment on this article. Our Commenting Policies