From what I researched, all traffic entering the Tor network undergoes encryption before reaching the entry/guard node, with each relay decrypting a layer before passing it along. However, if HTTPS isn’t used (which is often the case for onion services), the exit relay sends the data without encryption to the destination.
What caught my attention is the claim in the documentation that onion services have end-to-end encryption.
Onion service traffic is encrypted from the client to the onion host. This is like getting strong SSL/HTTPS for free.
I’m a bit confused. Are onion services truly end-to-end encrypted? And if they are, does what I mentioned only apply to regular internet use (clearnet)?
In case there’s an error in the documentation, would setting up an onion service using something like OnionShare’s private chat expose the messages to snooping between the onion service host and the exit relay?
After reading deeper into the documentation, I remember reading something about the connection to the onion services being encrypted with the onion service key. Am I wrong? However, for this to work shouldn’t there be a key exchange first? How is this done?
I could be wrong. I was told it worked something like this.
Scenario 1- use tor to connect to clearnet website with http, not https
In scenario 1, the traffic is unencrypted at the exit node, allowing the exit node to spy on all of it. This has been exploited in the past, but now much more of the clearnet is served via https.
Scenario 2- use tor to connect to clearnet website with https
In scenario 2, the traffic leaving the exit node is still encrypted via https, similar as to how it would be if you were connecting to the website via the normal internet. It is still a problem if the https encryption is cracked through lazy implementation / reusing keys instead of computing new ones. It is still a problem if the private keys are given to the NSA by the website. It is still a problem if cloudflare is on the website, doing a man-in-the-middle attack that undermines end-to-end https encryption. But unlike scenario 1, the exit node cannot automatically spy on your traffic.
Scenario 3- You connect to a hidden service using .onion and http.
In scenario 3, you do not need https encryption. The traffic takes place on the tor network and does not leave the clearnet. You do not have to worry about exit nodes spying on you due to not having https. However, https encryption in addition to .oniom encryption might not hurt and adds an extra layer of encryption.
Right, uppon further reading I managed to understand what you said. Let me explain for future users:
In order to make a connection to an onion service, a rendezvous point is used between the client and the host. In the end, the common 3-relay structure (guard → middle → exit) isn’t used, it is rather used a 6-relay structure with the third (starting the flow from the client) being the rendezvous point. It’s easier to understand with the picture from the documentation.
The 6-relay structure is used to protect the location from the onion service, establishing its connection to the rendezvous point through its own 3 relays.
The rendezvous point validates both one-time-secrets and establishes the end-to-end encryption, therefore preventing snooping.
The rendezvous point simply relays (end-to-end encrypted) messages from client to service and vice versa.
Now I feel kind of stupid since I read this docs before but didn’t manage to fully understand the procedure, now I do. I will also read the Tor Rendezvous Specification, which further explains all of this, although it is going to be a hard read and will take time. I will share here any other relevant yet important information.
Yes, there must be a key exchange first, it is explained in the documentation as well. To sum up, a HSDir is used to share the onion service’s descriptor and an introduction point set by the onion service for the client to send its secret string.
Yes, I was wrong. The key (or secret string) used to encrypt the connection is actually your own key, which is sent to the r-point and to the onion service using one of its introduction points, it then verifies if it’s trustworthy or not and sends it to the rendezvous point, and as I said before, the r-point validates (checks if they match) and establishes the connection.
