Mozilla Project Fusion: Tor Integration into Firefox

Post by schoen » Fri, Jun 01, 2018, 4:31 PM UTC

detaro wrote: post #16

LinuxBender wrote: post #14

Earlier quoted context omitted.

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.

Post by openasocket » Fri, Jun 01, 2018, 4:36 PM UTC

astrodust wrote: post #47

chipperyman573 wrote: post #41

Earlier quoted context omitted.

I can't read this article because I'm at work, but unless they managed to solve the problem of Tor being very, very, very slow, this will never happen. End users will definitely notice a difference and likely won't care about their privacy. They'll just see Firefox being way slower than Chrome and switch.

So long as Tor depends on volunteers to maintain exit nodes, and with that the risk of being arrested for all sorts of criminal activity by non-tech-savvy law enforcement, this is how it'll be.

Post by cup-of-tea » Fri, Jun 01, 2018, 4:40 PM UTC

forapurpose wrote: post #57

What will Mozilla do about the Tor network's usability problems? Advanced users can workaround them and because they understand the benefits and engineering, accept the frustrations as a cost for a worthwhile (and free) technology. But what will non-technical users do? Many public Internet websites filter connections from the Tor network, many other websites are very slow, yet others impose extra obstacles such as mu…

Post by jean- » Fri, Jun 01, 2018, 4:41 PM UTC

sametmax wrote: post #44

jean- wrote: post #35

Earlier quoted context omitted.

Firefox recently whitelisted a bunch of p2p protocols so that they can be used by browser extensions. One of them is the Dat protocol [0], which is similar to BitTorrent but has better support for mutable data and random access [1]. It's far from being "baked in", but it's a step in the right direction. [0]: https://docs.datproject.org/ [1]: https://docs.datproject.org/faq#dat-vs

We always could do that with extensions since JS is turing complete and has access to the network. Webtorrent is a thing after all. The issue is not technical. It's just a chicken and egg problem. Most won't use bittorent unless it's stupidely easy to do. Remember that the average user don't know what an URL is and doesn't open new tabs willingly. Since they are the majority, they drive cost and benefits, so we must…

Post by 21 » Fri, Jun 01, 2018, 4:42 PM UTC

seba_dos1 wrote: post #42

kchr wrote: post #27

Earlier quoted context omitted.

The use of HSTS is a way to suggest to your clients that they use SSL for that domain - for all requests within a time span (which could be "forever"). If anything, the vendors you mention should be applauded for taking that step towards a more secure distribution of updates. Not enforcing SSL makes malware injection through updates way way easier. Debian introduced HTTPS repos a while back as an option, but not by d…

Debian, and most other distributions as well, verifies its updates for ages and doesn't need SSL to do that. There are some arguments for using HTTPS anyway, but preventing malware injection isn't one (unless your package manager is exploitable).