The page isn't loading for me. https://web.archive.org/web/20180601141754/https://trac.torp... ( https://archive.org/donate )
it worked after a few tries for me. I believe its just serverload, keep trying or try later
Mozilla Project Fusion: Tor Integration into Firefox
21–30 of 242 posts
Re: Mozilla Project Fusion: Tor Integration into Firefox
#22> 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
Re: Mozilla Project Fusion: Tor Integration into Firefox
#23Earlier 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.
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.
Re: Mozilla Project Fusion: Tor Integration into Firefox
#24Earlier 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.
nitpick: exit node. The ones on the way can't, neither can any if you access hidden services.
Re: Mozilla Project Fusion: Tor Integration into Firefox
#25I 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).
Re: Mozilla Project Fusion: Tor Integration into Firefox
#26> Ultimate eventual goal: Make Tor Browser obsolete, so Tor Project can focus on research instead of maintaining a fork of Firefox.
EDIT: I mean baked in in the browser like tor, not baked in tor. Although interesting, it's really not my priority.
Re: Mozilla Project Fusion: Tor Integration into Firefox
#27Earlier 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 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.
Re: Mozilla Project Fusion: Tor Integration into Firefox
#28Earlier 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…
Re: Mozilla Project Fusion: Tor Integration into Firefox
#29Re: Mozilla Project Fusion: Tor Integration into Firefox
#30> Ultimate eventual goal: Make Tor Browser obsolete, so Tor Project can focus on research instead of maintaining a fork of Firefox.
Good, now if only we could have bitorrent baked in... EDIT: I mean baked in in the browser like tor, not baked in tor. Although interesting, it's really not my priority.