* Tails 3.0 works on 64-bit computers only and not on 32-bit computers anymore. Dropping hardware support, even for a small portion of our user base, is always a hard decision to make but being 64-bit only has important security and reliability benefits. For example, to protect against some types of security exploits, support for the NX bit is compulsory and most binaries are hardened with PIE which allows ASLR.
* Update Tor Browser to 7.0 (based on Firefox 52 ESR) which is multiprocess and paves the way to content sandboxing. This should make it harder to exploit security vulnerabilities in the browser.
The 32-bit computers are the only thing available to lots of poor people or those just relying on other people's computers. People's teenagers, people using libraries, workers with legacy systems, and Internet cafes come to mind. Dropping it is a mistake if both could be supported. If it was lack of contributions or funding, I can understand the perspective of focusing on most secure one.
EDIT to add: Always remember with solutions like this that the adversary isn't always the NSA and so on. The Tor users' page lists all kinds of people who need help against foes with limited budgets or knowledge who might not be able to break Linux or Tor.
I wonder if this will effect journalists and activists in parts of the world where old machines are still used (Africa, Middle East, parts of Asia). Not being able to make use of newer browser versions (without updating every time or taking the risk of using a persistent volume) could put them at greater risk.
I don't think it is unreasonable to assume everyone already has a 64-bit capable PC considering the most recent mainstream 32-bit only CPU is 2004's first gen Prescott Pentium 4.
Intel early centrinos are not 64bit (Dothan / Banias) so are the initial Core / Core Duo CPUs (Yona).
Intel didn't release a mobile 64bit CPU until 2006/7 with Core 2 Duo.
Also the initial implementations of Intel64/EMT64 lack certain functions so even tho they technically support 64bit they might lack certain other features that are required by modern operating systems.
So overall if you have a 10 year old laptop you might not be able to use Tails 3.0.
Beyond that, I thought it was now well understood that rolling ones own security software is a terrible idea. Many eyeballs etc. Activists with the technical skills /should not/ roll their own, they should definitely contribute to existing projects.
I understand thst 32-bit is inherently less secure than 64-bit but if you had no choice but to use a 32-bit computer, what would be the best way to provide yourself with similar security features?
I guess you could use an older version of Tails but I imagine this would become less and less secure as more and more vulnerabilities are found.
If they don't have any usage data, I think, they should provide old version and support it with critical security updates. If they have usage data, it depends, I guess.
I still occasionally use My Asus 1000HE (early 2009) and my Sony Vaio FE11S (2006), both still run fine with Arch/Ubuntu and Mate. Getting more and more difficult to find distro's though.
32-bit is insecure. There's no good reason to support it. Get a cheap old laptop if you have 32-bit machine for some reason, it's good to have separate hardware for this type of thing anyway.
There are a bunch of new machines that have 64 bit processors but tiny amounts of RAM. The low ram makes 64 bit OSs unfun to use, and most recommendations (Microsoft, Arch, Debian, etc) are to avoid 64 bit OSs on these machines.
If you're someone buying burner laptops these machines, which are very cheap, are now probably not a good idea.
A lot of hosting companies run KVM/qemu/Xen or even UML with 32-bit guests by default. But yeah in terms of physical computers 64-bit has long been the default.
I remember upgrading from 32-bit to 64-bit in-place a few times, which is a bit fiddly but not impossible with Debian. I wrote up a couple of guides once upon a time, but right now I can just find this old wiki-page discussing the process:
This is great. I very much appreciate the work done by the contributors to the Tails project and I trust & agree with their technical decisions for this release. As Internet keeps getting more monitored, Tails serves as an important tool in maintaining the balance of privacy and allowing for the anonymous sharing of information going forward. Big thanks to the Tails team.
> Update Tor Browser to 7.0 (based on Firefox 52 ESR) which is multiprocess and paves the way to content sandboxing. This should make it harder to exploit security vulnerabilities in the browser.
Firefox 52 ESR sounds like mainline Firefox to me.
Literally the same version of Firefox as underpins Tor Browser will tend, pretty much at all times, to be safer than Tor Browser. You can use the search bar at the bottom of the page to find out why, or search the Internet for "grugq tor browser" if you want more people explaining the issue.
> Literally the same version of Firefox as underpins Tor Browser will tend, pretty much at all times, to be safer than Tor Browser.
This is absolutely false. Especially if you're considering the alpha versions which include Selfrando.
See "Real-world Exploits against the Tor Browser" pages 9-10 where they conclude,
> The reason is that these function pointers are only accessed through an indirection layer, i.e., memory objects on the heap contain a pointer to a virtual table which is located in the code or data section of the application and contains a number of pointers to virtual functions. Since the attackers can only disclose the virtual table pointer, but not the virtual table itself, as it is not on the heap, they cannot disclose gadget addresses. Note that, when only ASLR is applied, the address of the virtual table is randomized with the same offset as the ROP gadgets. Therefore, such an attack can bypass ASLR but not selfrando.
> We therefore conclude that selfrando can thwart most real-world exploits. Attackers can only succeed in rare cases where they can disclose the complete heap and data section.
I'm not necessarily doubting you, but I wonder if you can say why you think the Tor project is distributing such an unsafe browser? If that's a very poor decision, does it call into question other decisions the project has made?
Making a claim while not explaining your reasoning is a sign of a low quality post that provides no actual contribution to the thread (and more often than not, of trolling) which justifies downvoting the post, no matter who the creator.
Reputation matters if you want to buy something or if you want an expert opinion on a topic that you have no idea about. However I don't believe that reputation matters in a forum full of people who would be able to understand (and wish for) a reasoning behind a claim.
A warning from a knowledgeable person without explanation is still better than no warning at all. I hope tptacek just didn't have time to post an explanation; maybe he'll find the time later.
Not only that, without the Tor Browser you wont have stream isolation, so all of your website browsing can be watched by a single exit node (whereas with the Tor Browser each site has its own circuit) which makes correlation attacks much damaging (whole browsing history in a session vs 1 site).
There are people that customize Firefox with plugins to make it look like TorBundle. All you need is FoxyProxy[0] hooked up to tor and a useragent spoofer which mimics common TorBundle useragent strings and you're set. This is very dangerous though as FoxyProxy could potentially leak your IP, aswell as a slew of other things that could go wrong.
TorBundle devs have stripped out a tonne of things which increase attack surfaces and the fingerprintability of mainline Firefox. Best just blending in and looking like everyone else and use TorBundle.
Not only that, using the particular setup you're describing, you wont have stream isolation, so all of your website browsing can be watched by a single exit node (whereas with the Tor Browser each site has its own circuit) which makes correlation attacks much damaging (whole browsing history in a session vs 1 site).
IIRC, the highlights of the anti-Tor-Browser argument are something like:
- Various people who are very interesting to intelligence agencies, police, organized crime syndicates, and private security for major corporations use Tor Browser, increasing the demand for and thus price of black market exploits specifically targeted at it.
- Tor Browser incorporates patches and default settings that receive less testing and review than the code and defaults of vanilla Firefox, making it more likely that vulnerabilities exist.
- Architecturally, Firefox lacks robust exploit mitigations, making it more likely that such vulnerabilities are actually exploitable.
- There's a delay between security fixes in vanilla Firefox and their release in a Tor Browser update.
- Exit nodes and root CA certificates may both be controlled by attackers, potentially giving them the ability to deploy exploits even to targets that only use HTTPS to trusted sites.
Adding all of the above together, it is not only plausible but likely that effective exploits specifically for Tor Browser currently exist in some attackers' toolkits.
An addition to this summary: Tor Browser is generally good for anonymity, because it creates a pool of users with identical browser fingerprints. But it is bad for security, for the reasons above. And I suppose that if your security is broken, your anonymity probably is, though at one remove.
The safer solution is to run the modern browser of your choice (probably chrome) in an isolated VM routed through a torified gateway. Hardware isolation would of course be preferable.
If you're using Tails you'd probably be much better off using Whonix instead.
With Tails, an attacker capable of breaking your browser will m̶o̶s̶t̶ ̶l̶i̶k̶e̶l̶y̶ definitely also be capable of easily grabbing your IP address.
Whonix is an OS, a modern browser of your choice could be firefox.
Whonix runs TOR in a separate VM from your browser/user space. The idea is that even if you get hacked they don't get your IP address since they can only access the internet through the gateway VM that pushes all traffic through TOR.
I always wondered why they need whonix gateway? Couldn't they just pass it through host's tor? Why do i need to run entire full blown debian just as a proxy?
That's indeed far better; specifically, Firefox ESR with all the calling-home features disabled in about:config and noscript with no whitelist on top of it.
Ideally you'd make sure the one responsible for going through tor isn't Firefox, too; IE at the very least a wrapper such as tsocks when running it or even better, a VM containing the browser and the entire VM connecting only through tor.
> The safer solution is to run the modern browser of your choice (probably chrome) in an isolated VM routed through a torified gateway.
This is bad and dangerous advice that can potentially put people in trouble. As I said elsewhere in this thread: If you don't use the Tor Browser you're exposing yourself to all the fingerprinting attacks that the Tor Browser tries to protect from: https://www.torproject.org/projects/torbrowser/design/
Not only that, using the particular setup you're describing, you wont have stream isolation, so all of your website browsing can be watched by a single exit node (whereas with the Tor Browser each site has its own circuit) which makes correlation attacks much damaging (whole browsing history in a session vs 1 site).
>This is bad and dangerous advice that can potentially put people in trouble. As I said elsewhere in this thread: If you don't use the Tor Browser you're exposing yourself to all the fingerprinting attacks that the Tor Browser tries to protect from: https://www.torproject.org/projects/torbrowser/design/
And if you do use Tor Browser you're exposing yourself to an old insecure browser. This situation has dramatically improved recently, but it's still far from optimal.
I think for most people fingerprinting is the far lesser threat, especially when discussing an install that'll presumably always remain behind Tor.
>Not only that, using the particular setup you're describing, you wont have stream isolation, so all of your website browsing can be watched by a single exit node (whereas with the Tor Browser each site has its own circuit) which makes correlation attacks much damaging (whole browsing history in a session vs 1 site).
Both Firefox and Chrome should grab KDEs proxy settings and therefore automatically benefit from stream isolation on Whonix, no?
> And if you do use Tor Browser you're exposing yourself to an old insecure browser.
1) The Tor Browser is based on the Firefox 52 ESR, sure, it's not the most secure browser in the market, but it's far from being "old and insecure".
2) If you're considering the alpha Linux 64 version, it includes Selfrando, which should provide more protection than a vanilla Firefox. See "Real-world Exploits against the Tor Browser" pages 9-10 where they conclude [1],
> The reason is that these function pointers are only accessed through an indirection layer, i.e., memory objects on the heap contain a pointer to a virtual table which is located in the code or data section of the application and contains a number of pointers to virtual functions. Since the attackers can only disclose the virtual table pointer, but not the virtual table itself, as it is not on the heap, they cannot disclose gadget addresses. Note that, when only ASLR is applied, the address of the virtual table is randomized with the same offset as the ROP gadgets. Therefore, such an attack can bypass ASLR but not selfrando.
> We therefore conclude that selfrando can thwart most real-world exploits. Attackers can only succeed in rare cases where they can disclose the complete heap and data section.
It's only for Linux for now, but that may change in the future.
3) Would you consider the Tor Browser with the security slider set to High or even just Medium to be "insecure"?
4) You still provided no alternatives.
> I think for most people fingerprinting is the far lesser threat, especially when discussing an install that'll presumably always remain behind Tor.
Sorry, shoving up all your traffic through Tor while not caring about your browser's fingerprint is useless, 29 bits of identifying information just from screen resolution output alone. It's just too easy...
And it's not just about fingerprinting, I'm afraid, see the other problems mentioned in the Tor Browser Design document.[2]
> Both Firefox and Chrome should grab KDEs proxy settings and therefore automatically benefit from stream isolation on Whonix, no?
No, unfortunately, these two different browsers will use two different catch-all circuits, but you wont get _first party_ stream isolation on them, _which was my whole point_. In other words, your Chromium (I assume that Chrome in your comment was just a typo) will use a single circuit for all of your websites, whereas with the Tor Browser each website will get its own circuit. That means that it's much much easier for an adversary who controls a portion of Tor relays to de-anonymize ALL your traffic with Chromium, when he can de-anonymize only a single website with the Tor Browser.
Also since you mentioned Whonix, note that they actually recommend using the Tor Browser without Tor for clearnet browsing instead of other browsers since it's (quoting their lead dev) "better hardened than regular Firefox".[3]
many things wrong with tails but it is not the browsers fault
anyone breaking firefox will have an extensive hardware profile and easily determine your entry node, bssid, mac and by running traffic correlation (3-letter now knows the entry) determine exactly who you are connecting from and all this without a root exploit just by breaking the TBrowser
nothing new really has been there since the beginning which is why tails doesn't even come close to whonix/qubesos which make this inherent insecurity a lot harder to exploit
I mean, "uname -m" gives you information about the kernel, not about the hardware.
If "uname -m" says "i686" it means that your kernels is 32-bit (or pretends¹ to be so). It doesn't necessarily mean that your hardware is not capable of running a 64-bit kernel.
So unless I'm missing something, the above procedure does not work correctly. Instead, you should run something like this:
$ lscpu | grep -w mode
CPU op-mode(s): 32-bit, 64-bit
I recently started using Tails so for security reasons coughbackdoorwindowsioscough,.. and found that it worked surprisely well. It has a disk utility, liber office, and the drivers even worked for my wireless dongle! Kudos to the Tails team!
Assuming Debian Stretch still uses non-systemd networking configuration (which was the default case in 8 at least), or Tails switches back to it, systemd shouldn't impact what Tails tries to do in any way.
Why is that important? Especially considering Tails has worked fine using systemd in their previous version based on Jessie. Additionally, Tails has used systemd's service namespacing functionality as part of a defense-in-depth strategy. Switching to Devuan makes little to no sense based on this track record.
* Tails 3.0 works on 64-bit computers only and not on 32-bit computers anymore. Dropping hardware support, even for a small portion of our user base, is always a hard decision to make but being 64-bit only has important security and reliability benefits. For example, to protect against some types of security exploits, support for the NX bit is compulsory and most binaries are hardened with PIE which allows ASLR.
* Update Tor Browser to 7.0 (based on Firefox 52 ESR) which is multiprocess and paves the way to content sandboxing. This should make it harder to exploit security vulnerabilities in the browser.
What do you guys think about dropping 32-bit?