Mozilla Project Fusion: Tor Integration into Firefox
trac.torproject.org
trac.torproject.org
If anyone is interested in assisting development-wise, Firefox bugs tagged 'fingerprinting' in the whiteboard are a good place to start. You can also run Tor relays and help us improve the health of the network by working with Tor's new Relay Advocate (https://blog.torproject.org/get-help-running-your-relay-our-...). More people being involved in spec work (especially at the W3C) and focusing on fingerprinting and privacy concerns is also very useful - it's very hard to keep eyes on all the things happening everywhere.
We also appreciate users of Firefox Beta and Nightly (Nightly especially). The flags Tor features are developed behind (privacy.resistFingerprinting and privacy.firstparty.isolate) are experimental. I appreciate bug reports from users running these flags but you should expect them to break things on the web (resistFingerprinting especially; first party isolate is generally more stable and usually only has breakage on particular login forms).
Some anti-features that come to my attention off the top of my head:
* Biometric login (as of FF60)
* Dumb PR Stunts like Mr. Robot
* Telemetry
* Balrog (Analytics and browser fingerprinting on AmazonS3)
* Social API
* VR sensors
* DRM
* Google Chrome (large contract Mozilla has with them as they backport this into IPC)
* CloudFlare DNS (Department of Homeland Security partner and Tor arch-enemy)
etc...
What issues exactly? Tor Browser = Firefox ESR + some patches + some other stuff and tweaks. Before the release of the next ESR TB devs rebase and submit these patches to mainline Firefox, that's why you have prefs like privacy.resistFingerprinting and privacy.firstparty.isolate in mainline Firefox, see: https://wiki.mozilla.org/Security/Tor_Uplift
Are you talking about Web Authentication? What is wrong with it?
What's this?
Since I've seen this come up before in many previous discussions of Tor I think it's worth emphasizing/clarifying up front: Tor relays are not the same as Tor exit nodes. Relays do not talk to the public internet, they serve only the full encrypted internal Tor virtual network. So they won't ever send out traffic from an IP under your control to some website or general Internet system (and in turn tie that IP in any way to spam/abuse/whatever, at least not for that reason). It's not necessarily hidden that it is acting as a relay, but the relay itself will have no knowledge of the traffic it's carrying.
Plenty of people have reasonable concerns about the risks/inconveniences that might come with acting as an exit node, but on both a legal and practical level there are many more jurisdictions where merely relaying encrypted traffic between other relays isn't a problem. And it's still quite helpful, both for network speed and because purely internal Tor Hidden Services do not need any exit nodes at all.
Sites such as https://www.dan.me.uk/dnsbl then help people do this.
That site in particular may "warn":
> This DNS blacklist contains ALL tor nodes (entry, transit and exit nodes) - think carefully before choosing to use this list for blocking purposes.
but anyone who doesn't understand tor simply won't understand the decision and choose ALL.
Running a relay on your own address isn't sensible because of this. Nevermind an exit node.
I think it might be a problem if I also ran a mail server from home, but almost nobody does that anymore.
I could do some shenanigans on my modem and end up with a new dynamic IP from cox, but generally within hours that new IP would be on whatever list people use to track exit node IPs and the pain would start all over again.
I still contribute to Tor via VPS rentals and such, but relays are not no-risk alternatives to exit nodes. Period.
Edit: nvm, found the answer by pricechild below.
Are you referring to third-party login services and comment systems (such as disqus and similar)?
See the full list of bugs of breakage when privacy.firstparty.isolate is enabled: https://wiki.mozilla.org/Security/FirstPartyIsolation#First_...
If that doesn't pan out, do you expect the ongoing work on this project to reduce the size of the patches that the Tor Browser project needs to carry on top of the Firefox trunk?
> The intention of Tor Uplift project is to land all Tor Browser patches so that Tor can directly use Firefox main trunk instead of a fork.
"Why you need balls of steel to run a Tor exit node":
https://lists.torproject.org/pipermail/tor-talk/2009-Septemb...
Given the low level of technical knowledge with a great deal of US law enforcement, increasing militarization, no knock warrants, etc... Please think twice before running an exit node from your house. Do it in Colo somewhere with a small, plucky ISP owned by a first and fourth amendment absolutist.
EDIT: I mean baked in in the browser like tor, not baked in tor. Although interesting, it's really not my priority.
Facebook used to deploy their code using bittorent. I doubt it has changed.
A lot of blizzard video games update using bittorent as well. If you play Starcraft 2, you use bittorent.
Streaming services like stremio are basically bittorent. After netflix, it's my main source of video content.
If you want to download the internet archive, that's the saner option. Same if you are a pentester, as a lot of heavy leak or hash db are so huge only bittorent makes it practical. Too expensive to host for one small actor. It's also more resistant to take down notice.
We talked a lot about RSS lately, and how to revive it, while in comments people said it actually never died. Bittorrent is a lot like that. Great tech, great standard, it works flawlessly and fill its use case perfectly.
The only reason it's not more adopted is because it's not in the browser by default. Otherwise the hosting benefit and the dl speed is such that it would be an instant hit.
I'll be happy to give more details on ngdp if you are curious.
https://gist.github.com/jleclanche/91f2f5c0f2042a81db1c61464...
They basically created their own git protocol + virtual filesystem, optimized for asset patches inside large compressed binary files. I wish they'd open source it.
Related discussion: https://news.ycombinator.com/item?id=13140257
However it is usually through VPN, not Tor.
(And before you say anything, I do pay for Netflix and have video included in my Amazon Prime membership - none of which had those movies)
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 include them.
It does not have access to TCP or UDP sockets.
You couldn't, until Firefox 59. Before that, protocol handlers were not allowed to handle links to Dat/IPFS resources [0].
And while I agree with your comment regarding the chicken and egg problem, there are still some technical issues. As the shadowbanned sibling comment says, extensions don't have access to UDP/TCP sockets, meaning that you will need to run a gateway on your machine. See e.g. what dat-fox [1] does.
[0]: https://developer.mozilla.org/en-US/Add-ons/WebExtensions/ma...
You could, kind of, before Firefox 57 (or at least, at some point). Implementing nsIProtocolHandler/nsIChannel/etc. correctly was difficult (and probably not from JavaScript), and distribution problems meant nobody did it.
https://addons.mozilla.org/en-US/firefox/addon/overbiteff/
But, not possible anymore (without tricks).
Apart from the existing ecosystem of content, are their any reasons you want BitTorrent over ipfs?
Everyone on tor AND ipfs... Now that would be something.
I think IFPS needs a little more field testing before being set in stone. Indeed, if you bake in something in the browsers, then those implementation will be the boundary of what is practical to do. So any innovation will then be constraint by the browsers release and good will.
IFPS is a young tech, it needs time to evolve yet.
Tor and bittorrent are now quite mature.
It used WebRTC which is also encrypted. So gets you some privacy.
It's nice, but not nearly good enough.
Could you share your concerns about IPFS in its current state or what you see as its limitations? Thanks.
[1] https://developer.chrome.com/extensions/background_pages
[2] https://developer.mozilla.org/en-US/Add-ons/WebExtensions/An...
You can be arrested for things just by using Tor if they mix you up with someone else or something?
https://www.eff.org/deeplinks/2017/04/access-now-and-eff-con...
If you use tor and visit the regular web sites (like, say, HN), the last computer that does the actual request to the website is an exit node, as far as that site is concerned, the exit node made the http request. If you run an exit node, your computer is going to be doing tons of requests to all kinds of websites, this may include sites that deal in illegal stuff like drugs, child prostitution, human trafficking, terrorism, etc.
edit: Forgot to say, you must explicit be running an exit node. Not every tor node is an exit node.
For example: https://www.deepdotweb.com/2017/05/01/russian-tor-exit-node-... https://www.zdnet.com/article/dan-egerstads-tor-exit-nodes-g... https://www.pcworld.com/article/2452320/tor-exit-node-operat...
(Also check the new relay guide: https://trac.torproject.org/projects/tor/wiki/TorRelayGuide)
But the sad truth is that there aren't that many hosting providers that allow Tor relays. Especially exit relays, because of abuse complaints.
Also, as you might expect, Tor relays can use lots of bandwidth. It's more common to get flat-rate bandwidth for 100 Mbps uplinks, and metered bandwidth for 1 Gbps uplinks. Digital Ocean, for example, just switched to metered bandwidth, and that has killed some relays.
However, all this could arguably change, if Tor became mainstream, as part of Firefox.
Run an exit node and then do something illegal. Then blame it on someone else.
So running an exit at home to coverup for posting on a forum that bans all Tor exits, that makes no sense.
Currently Tor looks like HTTPS done with TLS/1.2 on TCP (like regular HTTPS). As these newer protocols get more and more delpoyed Tor can start using them too which will help make Tor faster.
I don't know how much (if at all) it might help—but other, similar overlay networks have previously noticed that (intuitively) inefficiency in the transport protocol is likely to be (broadly speaking) multiplied by the number of hops; so any improvements in that might be useful in improving the user experience by using the same available resources more efficiently.
What that might mean for Tor's perceived speed is a somewhat murky issue, as that's a function of the complex interaction of latency and bandwidth and crypto and routing overhead of all the involved nodes in a tunnel put together; which of course is also shared with other tunnels; not to mention it will _also_ be particularly affected by exit node outproxy bandwidth; _and_ any possible packet loss and delay caused by both incidental _and_ deliberate adverse network conditions…
So with four hops, rtt would at most be 1200-2000 msec, if every hop were the maximum length. In practice, rtt for Tor is at most half that, and often even less. But latency is actually good if your goal is anonymity. Because it reduces the accuracy of traffic analysis.
With traditional onion sites, there are two three-relay circuits, one for the user and one for the site, plus a rendezvous relay. So rtt is much greater. However, sites can opt for one-relay circuits, sacrificing anonymity, so overall rtt isn't that bad.
Bandwidth is also reduced with Tor. Increased latency is part of that. But also, many relays have low-bandwidth uplinks, especially ones that people run at home. The Tor client does pick faster relays, but there's a tradeoff, in that doing so reduces anonymity. Increased investment in high-bandwidth relays would help a lot.
Also, with more relays, it would be workable to implement multipath circuits. Especially for onion sites, where precious exit relays aren't needed. Using MPTCP, I managed ~50 Mbps throughput for bbcp transfers between onion sites (with gigabit uplinks).[1] I was getting ~36 subflows per tcp connection.
0) https://www.ivpn.net/privacy-guides/how-to-verify-physical-l...
1) https://ipfs.io/ipfs/QmUDV2KHrAgs84oUc7z9zQmZ3whx1NB6YDPv8ZR...
And if i recall correctly, a "global passive attacker" listening to internet traffic around can de-anonimize TOR using ML. Seems like something that would be possible and profitable for a Google and internet infra companies.
This is what Telegram is trying to acheive with their TON and Gram.
Convince everyone that using a closed source, proprietary app is good security?
Detecting WhatsApp usage is trivial. With Tor you can use pluggable transports to obfuscate your traffic.
If Tor is going to be a built-in feature of Firefox, most employers are going to flag it as malware. This is a ridiculously dumb thing on so many levels -- promote privacy by directing your network traffic to "volunteer" proxy services?
Plus, users do not understand what Tor is or how to use it.
Fighting political battles with software is dumb — the end result is going to be a permanent loss of freedom, as governments force the use of platforms with trusted app stores.
If you're using TLS, it doesn't matter so much if the exit node is malicious because they still won't be able to read it.
Obviously I’m being downvoted into oblivion, but I truly feel this is a solution looking for a problem.
Project Fusion is a superset of that effort.
The key config file is distribution.ini. [3]
[1] https://hg.mozilla.org/build/partner-repacks/file
[2] https://www.mozilla.org/en-US/about/partnerships/distributio...
[3] https://brashear.me/blog/2017/12/07/how-to-deploy-firefox-wi...
Many public Internet websites filter connections from the Tor network, many other websites are very slow, yet others impose extra obstacles such as multiple rounds of captchas (even 5 or more) or degraded service (including high suspicion of payments), and of course you often will receive webpages in the wrong locale or language - which can trigger regional filters. Currently, workarounds requires resetting the circuit (few non-technical users will even understand what the circuit is), lots of patience and reloads, and often just giving up. [EDIT: And non-technical users won't understand what is happening and therefore won't know when to use which workaround.]
If that's the experience of typical Firefox users, they won't use it and they will have bad associations with Tor and Firefox.
I think the theory behind this project is that those problems are primarily caused by Tor's popular image as a 'fringe network for pedophiles and drug dealers' and that by making it more mainstream they can fix those issues.
(please more replies saying "that sounds really hard" and less replies saying "tor is not a fringe network for pedophiles and drug dealers", thanks)
They're identical now, I rarely got the awful one that you're talking about when searching on Google.
https://www.pcworld.com/article/2877592/mozilla-puts-old-har... (2015)
With wider adoption of ipv6 and all the good things that come with it (don't mistake me, they are great!) also comes the risk that each computer will get a uniquely identifiable IP address that will be used for fingerprinting. I've never really used Tor in the past, but this got me thinking about it.
An option could be to provide a webRTC-based node, but I am not sure how feasible that would be, after reading some comments here. Maybe for entry nodes and guard nodes instead of exit nodes? The transient nature of browser sessions could greatly enhance privacy. Of course, you would need some algorithms to deal with this very nature... But I can imagine some.
This surely lowers the barrier to entry for greatly enhanced privacy. Quite a lot of people seem to be aware of the private browsing mode, and I can imagine this being turned into a simple toggle on the private browsing home page, along with a short explanation (and a link to additional privacy tips).
A low hanging fruit that could enhance the privacy a bit would be to use the trusted recursive resolver (DNS over https) in private browsing by default, since it already is part of Firefox. It just needs a default trusted resolver.
I'll point you at FlashProxy (https://crypto.stanford.edu/flashproxy/) and Snowflake (https://github.com/keroserene/snowflake) the latter of which is in active development. =)
What are your frustrations with the Tor Browser?
Installing additional extensions is discouraged; but in my experience Decentraleyes makes latency somewhat less disturbing, CAPTCHAs appear less often; and uBlock Origin is essential [-].
[-] shipping with every available filter list enabled and cached may be a good enough default
See https://bugs.torproject.org/22089 and https://bugs.torproject.org/17569
1. You can hide the fact that you're using Tor by using pluggable transports which are already built-in the Tor Browser (such as meek-azure, obfs4, snowflake, ...).
2. That's the biggest reason as to why one must use Tor as much as possible even if they don't care about privacy. More people using Tor = the less interesting it is to be a Tor user.
That's exactly why I use it on a regular basis!
Perhaps when looking up political or medical things (also for friends), it could be good to run that through Tor. That is not something to hide per se, but it is definitely not something that is anyone else's business, and you don't want to be bubbled.
The latter might even be preferred since the former is only at the tab level and probably quite easy to forget whether you are in Tor before entering an address. It appears to be what is suggested in the notes (now that the link is up).
See for instance:
https://blog.mozilla.org/addons/2018/01/26/extensions-firefo... (CTRL-F Decentralization)
This is exactly the kind of tech Mozilla should be supporting - tech that gives users more freedom on the internet.
For security, instead of a JIT, a simple JavaScript bytecode interpreter written in Rust to be used exclusively in the Tor mode would be ideal, for maximum security at the cost of worse performance.
Another option is a JIT that generates code that is easily proven to be safe (e.g. because it does a bounds check on all memory accesses and only does indirect jumps using a jump table, or because it's the only thing running in a process and jumps are still constrained with a read only jump table and read only code).
I hope they give a good name to this new super-private mode (which actually isn't too bad of a name, either).
I also hope they don't just implement a "more private" mode in Firefox, but also a more hardened mode for Tor. The Tor mode in Firefox should use the strictest possible sandboxing technologies available to them from the operating system (file system virtualization, etc).
I'm even talking about those new fancy hypervisor-based micro-VMs in Windows 10, which I believe they are called Krypton containers, and it's what Edge uses within the Application Guard context. Although if the users have to enable Hyper-V/Micro-VMs first in Windows, then maybe this hardening mechanism should be optional, but encouraged. Otherwise, it should probably be the default.
https://www.zdnet.com/article/how-containers-will-transform-...
Oh, and this hardened mode should use a different process for every tab/extension, too, by default, just like Chrome does. I still don't think Mozilla's "hybrid" approach makes it as secure as Chrome (which is why it's a hybrid/compromise for lower memory usage).
Tor has hundreds of millions of daily users?
Some simple examples:
* Various navigator APIs (oscpu, platform, etc) need to be disabled.
* Gamepad API needs to be disabled.
* Have to prevent reading canvas pixel data
* Have to block information about avaiable OpenGL extensions from WebGL
* Modifier keys on keyboard events need to be spoofed (because they can be used to guess at keyboard layout)
* Errors from the media stack (for <video> and <audio>) need to be blanked out.
* Something to do with voice synthesis APIs; I didn't look into details.
* Connection API needs to be neutered
* Various timing APIs hanging off "performance" need to be neutered.
* Presentation API needs to be neutered.
* Number of CPUs reported by the navigator API needs to be spoofed.
* Window sizing for window.open needs to be spoofed.
* Ability to measure the difference between the window.inner* and window.outer* APIs needs to be disabled.
* Mouse positions in mouse events need to be spoofed to make it look like the window is fullscreened.
* Touch event positions need to be spoofed.
* Geolocation needs to be disabled.
And so on, and so forth.
Just shipping a standard bundled set of fonts and only allowing use of that doesn't suffice because anti-aliasing width differences could give away the used font renderer.
So let me ask again. When are you guys going to start building firefox from the ground up and make the perfect browser we all deserve?
And if you disagree, please. Present your arguments. I am the person you need to sell right now.
Do you remember netscape?
But webstandards are evolving faster than modern browsers are, so building a browser from the ground up would require quite a bit more money, and worse know-how - you can't just buy that in unlimited amounts, than they have for Firefox right now, and they can't exactly stop developing Firefox in the meantime either.
Also, their three big competitors have most of their browser market share thanks to building an operating system underneath it. No matter how slim Mozilla's chances at success were, it would've been foolish to not try to get into the operating system market. And they built it based on web technologies, because that's where they have know-how.
Now, if you're using Public Internet->Tor->Public Internet, then absolutely yes the last node CAN read the contents of your packets. In that case, you absolutely need appropriate encryption to hide the contents (sigh, not the metadata) of your packets.
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.
Perhaps the Tor team or an affiliate could set up a simplified CA and have a public CA cert restricted to .onion that folks could install as a work around to having browsers trust it by default.
https://cabforum.org/pipermail/public/2017-November/thread.h...
Since then Fotis Loukos and I have drafted a ballot, which I believe he plans to introduce soon after asking a few other organizations to look it over.
You can subscribe to the cabfpub mailing list without becoming an Interested Party or Member. Only Interested Parties or Members can post to the list, while only Members can introduce or vote on ballots.
(Edit: Strangely, the reason for this is seemingly not that they're worried that the general public will make crazy suggestions, but rather that the general public will make patented suggestions, without being willing to license them according to the Forum's patent policy, and thereby sneak patented technology into the standards.)
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.
To summarize, you are a dissident. I am a news reporter. You are giving me information about your government. Your life and the lives of your family members now depend 100% on the security of the Tor Proxy transport. Tor is a proxy transport and nothing more.
As a dissident, you have been trained by me to install addons that validate the signature of my HTTPS certs will not change. I also showed you how to do this using openssl s_client. When Tor is popped and routing you to your government hosts, you will see the SSL signature change. Per my instructions, you will cease all communication with me.
Without HTTPS, you are relying entirely on the transport for assurance of who you are talking to. This is neither appropriate nor acceptable for this type of communication.
PGP is not a mitigating control, because the handshake has completed and you are now downloading your state sponsored rootkit. It's too late by that point. The only thing we have to validate ID and allow or block application traffic is a certificate.
That's not the case, even with a SecureDrop setup, a Gov can compromise your SecureDrop machine and listen directly.
I can set up multiple canaries that they will have to pop and the fingerprint of one of those canaries is going to change or drop off the net.
I think you're misunderstanding something here, with onion services traffic is e2e encrypted and self-authenticated, as Matt explains:
> When you connect to an onion service, how do you know no one is MitM'ing you? Easy. It's impossible. The bad guy would have to be in your browser (more accurately: between the browser part of Tor Browser and the Tor process it runs in the background) or between the Tor process the onion service operator is running and the webserver it's pointing at. If you assume your Tor Browser hasn't been compromised, and you assume the onion service is being run intelligently, then a MitM attack is impossible. (And if the onion service isn't being run intelligently, can you really trust its operator to do HTTPS intelligently?) > > https://matt.traudt.xyz/posts/dont-https-your-o44SnkW2.html
My point is that is a single point of success. Any other web service I would cut some slack. In the case of Tor, it is marketed as a means by which dissidents may communicate safely. Putting peoples lives on a single point of success is not appropriate, especially when there are technical means to mitigate the risk.
Yes, the guy running the exit node can read the bytes that come in and out there. Tor anonymizes the origin of your traffic, and it makes sure to encrypt everything inside the Tor network, but it does not magically encrypt all traffic throughout the Internet.
This is why you should always use end-to-end encryption such as SSL for sensitive Internet connections.
```
Fortunately HTTPS adoption is much better now :)
It's HSTS what we need in 2018
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 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 default. Other distros already offer it.
Otherwise go ahead and disable DEP, ASLR, and other modern defense in depth and mitigations mechanisms used by Debian, of course, unless your OS is exploitable.
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 :)
That depends a lot on what you're sending. Tor stops people from identifying you based on your IP address, but you can still identify yourself by logging in on http://not-encrypted.com.