Transport layer encryption about umbrel HOT 9 CLOSED

You're misunderstanding how the Tor hidden service works.

tor exit (problem) --> webserver

This step only happens if you're proxying through the Tor network to a clearnet HTTP server not when you're connecting to a Tor hidden service.

The Umbrel dashboard is exposed as a Tor hidden service, it's not a clearnet service running on the internet and being accessed through the Tor network. The traffic doesn't leave the Tor network until it arrives at your Umbrel, and is then proxied to the local server running on the Umbrel.

All communication sent to your Umbrel is encrypted with its public key, then extra layers are added with routing information for the relays. It's not possible for these relays to decrypt the final message (as you already understand) and there is no exit node when connecting to a hidden service, the final hop is the Umbrel device itself.

So the correct flow is:

• User (encrypts message with Umbrel's pubkey)
• Bridge (can't decrypt)
• Relay (can't decrypt)
• Relay (can't decrypt)
• Relay (can't decrypt)
• Umbrel (can decrypt)
• Umbrel local web server (get message in plain text via localhost)

The message is completely hidden from:

• Anyone on the user's local network
• The Tor bridge and relay nodes
• Anyone on the Umbrel's local network

Does that clear things up?

from umbrel.

Thank you for clearing up my thoughts/concerns :-)

from umbrel.

@bettyvschmartz Thanks for the suggestion but SSH tunnels don't actually solve the problem if you don't trust the network in the first place. If there was a malicious actor on the network they could MITM the initial SSH connection and you'd have no idea you were connected to the wrong identity.

Assuming your first connection is safe and the SSH identity is saved then all future connections would be safe. But under that assumption it's also just as safe to first connect via local HTTP and then switch over to the Tor hidden service. That's also much simpler than SSH tunnels for non-technical users and doesn't require root/CLI/editing host files etc.

The issue here is that it's not possible to bootstrap a secure connection over an insecure connection without some kind of prior trusted information exchange to verify the identity.

We do have some interesting ideas on how to solve this (see getumbrel/umbrel-os#53 for one attempt) but it's not as simple as just using encryption via SSL/SSH/VPN/etc. For the encryption to serve any purpose we need to not just know that the data is encrypted, but also also verify the identity of the device on the other end of the encrypted connection.

from umbrel.

I think there may be some misunderstanding here. Can you clarify exactly what your concern is?

Are you saying you run a Tor relay on the same network as Umbrel and you're worried that the traffic you are relaying can listen in on your Umbrel connections?

If so, that's not the case, a Tor relay is just relaying traffic internal to the Tor network. If you aren't running an exit node then none of that traffic will ever leave your relay, it can't listen in on traffic on your local network.

if a user connects to the provisioned tor adress the pw is sent in cleartext

If you connect to your Umbrel via the Tor hidden service, the password is not sent in plain text, it's encrypted over the Tor network.

We allow plain text connection over the local network via http://umbrel.local for convenience if users want to do this. We make the assumption that the local network is secure as explained in SECURITY.md. If you have malicious actors on your local network then it is not safe to run Umbrel. We have plans on how we can make Umbrel safe on untrusted networks but that is not currently the case during beta.

if this is by design (beta) no one should put any funds on it even for testing purposes.

It's worth noting we are the exception for even attempting to make Umbrel safe to run on an insecure network. It would be a completely reasonable requirement to keep even after beta, this is a requirement similar projects such as Casa and myNode have.

Was a bit shocked that i did not see any HTTPS encryption. Did i do something wrong?

No that's not wrong, SSL does not help in this situation. We can't get a CA signed certificate for a local address and a self signed SSL cert doesn't really achieve anything because if we generate it randomly the user doesn't know the expected fingerprint for the real cert, and if we hardcode it an attacker can just extract the private key from the source and use that to imitate the real server.

from umbrel.

Hi @lukechilds ,
Lets assume the following case: i run a Tor relay and a Tor bridge.

If i connect now to the onion address the first tor bridge i connect to sees the traffic in clear text as there is no handshake or any other type of encryption done. After that the traffic flows in to tor where onion like layers are build around the request, but the last one has to do the request to the webserver (relay). this is done in cleartext again.

user --> (first bridge is the problem) --> tor relay (no problem) --> tor relay (no problem) --> tor exit (problem) --> webserver

A self signed certificate in my view is required. The fingerprint can be poste in the terminal and the user should note it down.
Additionaly on a first visit users can be forced to connect to the HTTP site which only has a manual on how to import the certificate (Windows, Android, Linux, iOS, MacOS) and Provide the RootCA Cert as a download to being trusted.

Via HTTP i could also log a package and just replay it and get my own auth cookie and have access to the web panel ;(.

Just my 2 cents i might be completely off or have not researched enough on it. What i know is tor only protects you from someone watching your connection (like a ISP or a 3 letter agency). It does not provide you a secure entry/exit point.

In no mean i want to bash the project, i really like it the simplicity and how amazing it looks. I also understand it is in beta and no one should put funds in it yet.

from umbrel.

No problem, great questions!

from umbrel.

Whilst in the end this was a question about accessing Umbrel via Tor as if it was a clear net site (which it isn't), local encryption can still be achieved via SSH for those who want to solve the 'insecure local LAN' problem. AFAICT it would be possible by port forwarding. That way the connection to the Umbrel instance over the local network is encrypted over the SSH tunnel. Something like;

sudo ssh -fNg -L 80:umbrel.local:80 umbrel@your_umbrel_ip

You'd need to run as root so port 80 can be bound. An alias for 127.0.0.1 pointing to umbrel.local would also be needed in the local hosts file so that the correct HTTP header is sent which also means SSH access only via IP as above.

Should work. May be useful in the readme as a workaround/note as I see users may immediately query the insecure connection.

-- BVS

from umbrel.

@lukechilds sure, I take the point totally.

I do think that the scope you're looking at here is wider than I intended when I refer to an 'insecure network'. I'm suggesting the user concern may be someone eavesdropping on the local network so connecting over HTTP is not the same as connecting over SSH using DH key exchange (but yes, assuming you can trust no one is impersonating your Umbrel server).

Anyway, may be useful to some as a suggestion and looking forward to see getumbrel/umbrel-os#53 idea. Looks awesome.

-- BVS

from umbrel.

Yes, it's a great suggestion for users who want to protect against the specific attack vector of someone passively monitoring network communication.

We don't want to spend too much time on this until we have a good method in place to completely eliminate all local attack vectors.

Btw getumbrel/umbrel-os#53 has been implemented since day one! Attach an HDMI monitor and reboot and you should see it.

from umbrel.