Live data from Hacker News

Mozilla Project Fusion: Tor Integration into Firefox

trac.torproject.org

11–20 of 242 posts

Re: Mozilla Project Fusion: Tor Integration into Firefox

#11
post #9

Earlier quoted context omitted.

>Fortunately HTTPS adoption is much better now :) It's HSTS what we need in 2018

I disagree. Ive seen HSTS applied to things like Windows 10 updates, to prevent users from seeing what exactly your OS is sending to the mothership. Ideally, we should be able to see exactly the content being exfiltrated, and choose to allow/disallow. But the moment we use tools like ettercap or mitmssl, it kills the session and we can't see the data. HSTS seems more "self cutting" than useful at this juncture.

If its truly your OS I think you can read all the network data you want to, including the key negotiation. Albeit its not the easiest thing to do.

Re: Mozilla Project Fusion: Tor Integration into Firefox

#13
post #2

Why does the Tor Browser Bundle ship with HTTPS Everywhere? Surely if you're connected through a Tor circuit, HTTPS provides no extra security?

If you're connecting to a clearnet site, you probably need HTTPS _more_ than on a standard connection - you _explicitly_ have a node between you and the site that you don't necessarily trust (see, e.g., https://nakedsecurity.sophos.com/2015/06/25/can-you-trust-to...).

Re: Mozilla Project Fusion: Tor Integration into Firefox

#14
post #3

Earlier quoted context omitted.

This is the biggest misconception about Tor. Tor provides anonymity, but any node (EDIT: any exit node) can read what you're sending if it's not encrypted. You need both.

That's definitely not true if your endpoint you're talking to is an *.onion . A connection to an Onion is encrypted to the destination. That also means if you were running, say NodeRed with authentication, sending credentials "over the clear" (no SSL cert, because stupidity) it's not actually sent over the clear. It's encrypted to the public key relating to your onion address. Now, if you're using Public Internet->To…

I would still prefer https on a .onion. If tor itself is popped, then traffic can be routed or mirrored to another host. This has happened in a PoC and was fixed in a security update in one of the alpha releases. There are additional fixes required for HS that are coming.

If the target is using https, you can see if the signature changes (there are addons for this).

Digicert will sign .onion domains, though the hidden site must be willing to share their identity with Digicert. I would love to see LetsEncrypt sign .onion domains, assuming they are willing to connect back to a .onion to validate the server.

Re: Mozilla Project Fusion: Tor Integration into Firefox

#15
post #2

Why does the Tor Browser Bundle ship with HTTPS Everywhere? Surely if you're connected through a Tor circuit, HTTPS provides no extra security?

anonymity /= confidentiality

you can stay anonymous while making sure anyone can read what you are sending.

you can send confidential messages while making sure anyone knows who you are.

you can also combine the two :)

Re: Mozilla Project Fusion: Tor Integration into Firefox

#16

Earlier quoted context omitted.

That's definitely not true if your endpoint you're talking to is an *.onion . A connection to an Onion is encrypted to the destination. That also means if you were running, say NodeRed with authentication, sending credentials "over the clear" (no SSL cert, because stupidity) it's not actually sent over the clear. It's encrypted to the public key relating to your onion address. Now, if you're using Public Internet->To…

I would still prefer https on a .onion. If tor itself is popped, then traffic can be routed or mirrored to another host. This has happened in a PoC and was fixed in a security update in one of the alpha releases. There are additional fixes required for HS that are coming. If the target is using https, you can see if the signature changes (there are addons for this). Digicert will sign .onion domains, though the hidde…

The CA/B Forum rules only allow EV certificates for .onion, so even if Let's Encrypt wanted they couldn't give out .onion certificates without getting that changed first.

Re: Mozilla Project Fusion: Tor Integration into Firefox

#18

Earlier quoted context omitted.

That's definitely not true if your endpoint you're talking to is an *.onion . A connection to an Onion is encrypted to the destination. That also means if you were running, say NodeRed with authentication, sending credentials "over the clear" (no SSL cert, because stupidity) it's not actually sent over the clear. It's encrypted to the public key relating to your onion address. Now, if you're using Public Internet->To…

I would still prefer https on a .onion. If tor itself is popped, then traffic can be routed or mirrored to another host. This has happened in a PoC and was fixed in a security update in one of the alpha releases. There are additional fixes required for HS that are coming. If the target is using https, you can see if the signature changes (there are addons for this). Digicert will sign .onion domains, though the hidde…

Indeed, I too would love to have SSL certs for .onions and not have to bend over with an Extended Payment... Err, Verification check.

I thought about setting up boulder on tor, and start rolling it myself. But then again who'd trust me? This should be part of the Tor organization. I can't see my own system getting inertia, or put into TBB, or Firefox for that matter. It was hard enough for LE to be put in trusted CAs on machines.

Re: Mozilla Project Fusion: Tor Integration into Firefox

#20

> Ultimate eventual goal: Make Tor Browser obsolete, so Tor Project can focus on research instead of maintaining a fork of Firefox.

Hopefully other browsers are encouraged to do something similar also, else Mozilla will effectively control the destiny of Tor
Post reply on HN