0

Here's the problem:

Can you trust Tor’s exit nodes?

Excerpt:

Chloe set up a fake website with a Bitcoin theme, downloaded a complete list of exit nodes and then logged in to the honeypot site multiple times via Tor, using a different exit node and a unique password each time.

Crucially the usernames and passwords were sent over regular HTTP rather than encrypted HTTPS so that when Tor’s layers of encryption were peeled back they were visible in the stream of traffic.

If the login attempts had gone unobserved and unabused then the total number of website visits and log in attempts recorded by the honeypot should have matched the number performed by Chloe exactly.

They didn’t.

After a month of testing there were over 600 unexplained page visits, 12 failed log-in attempts and 16 successful ones that hadn’t come from Chloe.

The passwords were not stored anywhere and were far too difficult to guess so if they were indeed stolen, they were stolen by somebody snooping on-the-wire.

Eventually your network traffic leaves Tor’s safe embrace via an exit node – a gateway computer that decrypts your traffic so it can rejoin the regular internet before it arrives at its final destination.

Anyone can set up an exit node and because it’s the place where traffic is decrypted, anyone who runs an exit node can read the traffic passing through it.

people are using Tor in the mistaken belief that it was an end-to-end encryption tool.

It is many things, but it isn’t that.

MY QUESTION IS: Why not set up the Darknet servers as exit nodes with their web sites at address 127.0.0.1 so there is no "in the clear" traffic over the wire at all?

Community
  • 1
SDsolar
  • 977
  • 1
  • 6
  • 25
  • Not sure I understand what your proposed solution is. But anyway, the simple solution is to just use TLS. – Anders Apr 09 '18 at 19:06
  • 1
    More to the real point, Why doesn't every website operator use HTTPS? – Michael Hampton Apr 09 '18 at 19:06
  • I do not have a proposed solution - just asking why it ever outputs to the open internet - between the exit node and the service itself. Doesn't make sense to have Tor encrypt everything except that last hop. Why not keep it encrypted all the way? And yes, HTTPS should be used by EVERY web site, no matter what. – SDsolar Apr 09 '18 at 23:27

2 Answers2

2

There are three general end-to-end encryption techniques for servers using Tor.

HTTPS

When connecting to a website using HTTPS, Tor does provide end-to-end encryption. This is explained beautifully on the EFF's Tor and HTTPS demo page. When you are using HTTPS, the exit node is not privy to any data going through it because the session key for the traffic is shared only between the client's browser and the destination website's server.

Tor and HTTPS

An example of this would be the https://duckduckgo.com/, the DuckDuckGo domain. The session key is known only to your browser and the DDG server. Reading the traffic requires breaking TLS.

Hidden services

This seems to actually be what you are describing. Rather than setting up a website on an exit node (which is public), a website can be created on a server which runs Tor and which is accessible via a particular onion address, allowing the server to be provided with the same anonymity that the client gets. A hidden service is accessible only via its onion name, and the location of the hidden service is hidden from both the client and any other adversaries who may want to pinpoint it. When using a hidden service, traffic never leaves the Tor network.

Connecting to a hidden service involves the client creating a three-hop circuit as normal, but additionally involves the hidden service creating its own three-hop circuit. The client and server agree on a rendezvous point where the third hop in each circuit meet up and exchange data. This allows the traffic to be end-to-end encrypted, even if the hidden service does not provide HTTPS (non-EV certificates are currently not supported for .onion domains). The encryption is provided by the Tor protocol itself, with a key being shared by the client and the server's Tor process.

An example of this is the https://3g2upl4pq6kufc4m.onion/, the DuckDuckGo onion domain. Even without HTTPS, traffic to that site is encrypted by the Tor protocol. There are no exit nodes involved in connecting to a hidden service because no traffic ever exits the network.

Hidden services are now frequently referred to as "onion services". Additionally, a new version of hidden services, version three, has been rolled out. It features a new protocol and longer domain names. The general concept behind v3 hidden services is the same as for v2.

Pinned exit nodes

There is an open proposal to implement pinned exit nodes. This involves a server sending an HTTP header which specifies a particular exit node which the client should from then on use when connecting to the website. It allows websites to run their own trusted exits. The motivation for the proposal is to mitigate man-in-the-middle attacks and promote end-to-end encryption:

Similar to the now-obsolete concept of exit enclaves, this proposal enables web services to express that Tor clients should prefer a predefined set of exit relays when connecting to the service. We encourage sensitive sites to set up their own exit relays and have Tor clients prefer these relays, thus greatly mitigating the risk of man-in-the-middle attacks.

Pinned exit nodes have not yet been implemented.

Glorfindel
  • 2,263
  • 6
  • 19
  • 30
forest
  • 65,613
  • 20
  • 208
  • 262
1

Tor is not and never has been end to end encryption. Never ever trust anything downloaded over HTTP on Tor, as is trivial to alter HTML pages, insert Javascript and even modify download files on the fly. To be safe on Tor, use HTTPS and never trust a misconfigured SSL/TLS certificate.

To answer the question, Darknet operators don't need to create a 127.0.0.1 web site at all. They have to create an Onion Service (formerly Hidden Service) and are good to go. Traffic for an Onion Service never leaves the encrypted layer and are never visible in cleartext, not even by the guard node, gateway node, or any node in between.

ThoriumBR
  • 51,983
  • 13
  • 131
  • 149
  • An onion service _is_ a service on 127.0.0.1. – forest Apr 10 '18 at 01:10
  • This is also partially incorrect. You get end-to-end encryption when using TLS, which is the norm since Tor browser uses HTTPS Everywhere. You are right that there is no e2e when using plain HTTP though. – forest Apr 10 '18 at 01:51
  • @forest An onion service is not required to be on the same host as the Tor node, though this configuration does introduce potential security risks. – Michael Hampton Apr 10 '18 at 03:39
  • @MichaelHampton That's true, but the vast majority of onion services are simply web servers bound to localhost. – forest Apr 10 '18 at 03:44
  • @forest OP specifically said `usernames and passwords were sent over regular HTTP`. So, no end to end encryption. – ThoriumBR Apr 10 '18 at 14:39
  • @ThoriumBR As I said, when you use TLS, you get end-to-end encryption. – forest Apr 11 '18 at 01:17