Tor Browser 11.0
blog.torproject.org
blog.torproject.org
Follow along with the death of most tor onion services in the plots at: https://www.encryptionin.space/tracking-hsdirs-and-the-versi... (here's a snapshot mirror if the site is slow under load, https://i.ibb.co/9NzVcsz/plot.png)
I personally don't like that v2 is being shut off instead of let run alongside v3. I thought I owned my tor domain I've been using the last decade but it's clear the tor project has the same amount of control as any registrar. I thought I could work on building a community like I have on the clear web but the tor project doesn't consider that a priority and will throw 15 years of history away to make sure non-technical users don't accidentally use v2 services. Tor is not really a place for community building. My mistake. I just won't use it anymore.
Also, Tor Project has had v2 address depreciation on it's roadmap for 2 years now, they have given hidden service operators plenty of time to prime their community for the v2 --> v3 switch. This gradual change is way better than scrambling to depreciate v2 addresses in response to some state actor publicly breaking the RSA keys of v2 hidden services.
> I thought I owned my tor domain
You may now, but if v2 is kept around soon you won't be the only one with the domains private key.
What is the danger of exposing the hash of the services public key? Public keys are public anyway.
1. so little of the hash is exposed (only 80 bits of 160 for sha1), making it easier to find a collision
2. the hash is so weak (sha1 is widely considered broken), making it easier to find a collision
3. the underlying public key is so small, making it easier to derive the private key from the public key
IIRC if you find a collision you can use that to take over / contest an onion address, and obviously reversing the public key into a private key gives you as much control over an onion address as the original creator.
If they cannot connect on V2, the method to discover v3 is almost definitely out of band and potentially in the prone to hijacking.
It's not even a hard upgrade, afaik it's literally just a change of what address users have to copy/bookmark and nothing else. I just don't get what the reason to not upgrade is.
...and all of the links that everyone has embedded in content all over the ecosystem.
Sorta like the Tor version of DNS. It's where your Tor goes to get information about an onion, e.g. how to connect to it. Tor versions that don't support v2 will refuse to host this information, and so if all 6 HSDirs of an v2 onion doesn't support it, the onion will be unreachable.
Maybe understanding a bit about how onion services work will help: https://community.torproject.org/onion-services/overview/
1. Is that (still) correct?
2. Can't web pages include non-TCP traffic, and if so, is it routed via Tor? For example, doesn't some some streaming media use UDP?
3. QUIC doesn't use TCP (deliberately, I think). Won't that affect Tor's long-term viability if everyone eventually moves to QUIC?
2. So there is some non-TCP traffic. What happens when you load that page in Tor Browser, for example? Does it leak back to your clear Internet connection? Is it simply dropped? This seems like a critical issue.
3. Thanks. Do you know when that was written? To save others clicking the link and finding the applicable section, I'll paste it below. Designing and building your own protocol for Internet transport, compatible with the entire net and performing competitively enough to be usable, sounds like quite a project for a small organization. Note that Google didn't do that; they used UDP for QUIC.
7 Tor Network Compatibility Concerns
Our final area of concern is continued compatibility of the Tor network with future versions of the HTTP proto- col. It is our understanding that there is a desire for future versions of HTTP to move to a UDP transport layer so that reliability, congestion control, and client mobility will be more directly under control of the client user agent.
At present, the Tor Network is only capable of carrying TCP traffic. While it will be possible to support the transit of UDP datagrams using our existing TCP overlay network without significant anonymity risks within a year’s time or sooner, it is unlikely that this level of support will be sufficient to warrant the use of a finely-tuned UDP version of HTTP rather than a TCP variant.
Long term, our goal is to transition the entire Tor network to our own datagram protocol with custom con- gestion and flow control to better support both native datagram transport and end-to-end flow control. However, additional research is still needed to examine the anonymity implications associated with this transition[12]. Our present estimate is that a full network transition to UDP is at least five years away.
We are also concerned that even after a full network transition to a datagram transport, it is likely that the congestion, flow, and reliability control of a UDP version of HTTP may still end up performing poorly over higher-latency overlay networks such as ours.
For these reasons, we are especially interested in ensuring that overlay networks are taken into account in the design of any UDP-based future versions of HTTP, and also prefer to retain the ability to use future HTTP versions over TCP, should the UDP implementations prove sub-optimal for our use case.
$> --- HLS ---<3
I'm not sure if Tor Browser turns off by default, searching found this one ticket which suggest that default flag but maybe it's not implemented out of the box.
[1] https://privacycheck.sec.lrz.de/active/fp_wrtc/fp_webrtc.htm...
It does and it is removed at compile time since that ticket was closed (i.e. that was a build flag not a runtime flag).
For one thing, convection to a website via one of those protocols first, and then a header informs the client that it can reconnect via QUIC/HTTP3. IE they have to have a working http 1 or 2 webserver first.
UDP is disallowed in many many places, and many ISPs treat UDP as hostile and rate limit it.
In the places it works, it provides some benefits. But we're unlikely to see it take over as the sole protocol any time soon.
Agreed, but I'm not talking about soon. I mean the long term. Even FTP has been deprecated.
But since it is provably a non-issue today because it requires upgrading from TCP, it's going to be low priority.
Not everywhere. FTP-over-TLS is secure, standardised (RFC4217 as updated by RFC8996), and in some environments is still preferred to SFTP, particularly mainframe and minicomputer environments. FTP, due to its age, has a lot of "legacy" features which mean it can work better with non-POSIX filesystems used on mainframe and minicomputer systems than SFTP can. In principle you could add extensions to SFTP to improve its support for non-POSIX filesystems, but why bother when FTP already has very well-established support for that?
Another area in which FTP is still preferred is transfer of very large (multi-terabyte) scientific datasets. GridFTP has defined FTP extensions which permit these transfers, including encryption and striping of files across multiple connections and servers (so multiple servers can cooperate to simultaneously transfer different portions of an extremely large file). SFTP has no advantage for this application, and why bother redefining those extensions over SFTP when they work perfectly well over FTP? The main competitor to GridFTP is not SFTP, but rather proprietary solutions such as IBM Aspera. GridFTP actually supports SSH as a transport, but even then the file transfer protocol is based on FTP not the binary SFTP protocol.
Similar comments apply to TELNET. TELNET-over-TLS is secure, and still preferred in some IBM environments, because there are established protocols for passing 3270 and 5250 block mode terminal data streams over TELNET. Again, no reason in principle why you couldn't define similar protocol extensions for SSH, but why bother when TELNET works perfectly well for this application? And if you really want to use SSH instead of TLS as a transport/security layer, nothing stops you from tunnelling TELNET over SSH.
If curl decided to remove it, I would be more worried.
Deprecated doesn't mean 'wiped off all computers everywhere'. By that definition, name something that is truly 'deprecated'? An interesting trivia question. I think we have to exclude rare tech like prototypes.
Curiosity, yeah, pretty much. One day I decided to read the TELNET and FTP RFCs and became fascinated with all the historical cruft in them. I've also long been enjoyed studying IBM mainframe and midrange systems, they are their own somewhat alien world – most of that study has been limited to reading manuals, although I have mucked around with MVS 3.8J under Hercules (which unfortunately doesn't really have TCP/IP networking, or when it does it is some hacked-on thing with little in common with how TCP/IP actually works on MVS whether today or historically).
> Deprecated doesn't mean 'wiped off all computers everywhere'. By that definition, name something that is truly 'deprecated'? An interesting trivia question. I think we have to exclude rare tech like prototypes.
There are many systems which we know nobody still uses for production use, only for hobbyist / retrocomputing uses. A famous example would be Multics, at its peak it had over 50 production sites, the last production site was shut down in 2000, it took over 10 years between the last production site being shut down and an emulator becoming available so anyone could run it.
By contrast, people still use FTP and TELNET every day in production. Neither is inherently insecure, because both can be used over TLS. The majority of open source FTP/TELNET clients/servers never added TLS support, but commercial/proprietary implementations targeted at IBM mainframe sites do.
Nit: new SVCB DNS records can serve the same purpose as Alt-Svc HTTP headers before the initial request, so the first request to a server is HTTP/3.
But yeah, HTTP/1.1 isn't going away (and shouldn't go away) for many reasons.
> Final deprecation of v2 onion services
Final removal, not deprecation.
> v2 onion services would be deprecated in late 2021
No, removed in late 2021, after being deprecated for over a year (from July or September, depending on how you count it).
It's like they kept making the active tab harder to distinguish, until eventually someone had a thought, "the active tab is really hard to distinguish, so let's make this puppy dominate the entire UI".
This is my least-favorite UI change since the intermediate submenu "Close Multiple Tabs" was introduced, to make a somewhat tedious mousing task even more work.
Some of these issues seem like pretty big issues:
> Bug 40671: Fonts don't render > Bug 40695: JS enabled on Safest in Windows (new)
This update is actually so messed up, that I had to delete my whole profile and start from scratch, because everything was missing, including icons and text. It starts and is usable with the fresh profile, but this should seriously be fixed.
At some point in my career I was involved in some journalistic reporting in Saudi Arabia; had I used a regular VPN, it could have been easily detected, and in best case defeated, worst case put me in serious legal trouble, which in Saudi Arabia can easily end in corporal punishment and/or death. TOR allowed me to circumvent all that and keep reporting on government official and police force corruption in a safe way, in a country that frankly could use a lot more of this type of journalism.
Thank you, TOR project!
I'm almost certain that Tor use is easily detected; that is what I've always (100%) read from security experts and it makes sense to me: Traffic patterns, packet fingerprints (encryption implementations, size, etc.), and of course all the traffic is going to and from a Tor node, a list of which is available to every Tor user.
The attacker may not be able to read the contents or metadata, but they will know you are using Tor. Tor users are a very small population; it's a red flag.
The same is true for websites, etc. that you visit: They can easily see that your traffic is coming from a Tor exit node. Also, exit nodes are of course as vulnerable to attack as any other server, and they provide access to the ip addresses you connect with and, when https isn't used or properly implemented, to the contents of the communication.
Tor is not a panacea. Also, don't conflate Tor with Tor Browser, which I've read is possibly the worst security choice among browsers - a huge target without the resources to secure itself.
Also, the traffic still goes to a Tor node.
Finally, the Tor Project works very hard, but they are outgunned. Security is significantly a matter of resources. Tor's small team has a hard time competing with well-funded state security actors (who can also buy exploits).
You can also use bridges, which are unlisted Tor nodes.
Military researchers invent a lot of cool stuff, much of which theoretically could be useful to the military in some way, but you shouldn't take the military research pedigree as proof that something is necessarily useful for a particular application or threat model today, any more than being invented by people from a famous university means that a technology is good or is the best choice for some application.
A better case for the kind of considerations you mention might be found in infosec guidance that government agencies offer to other government agencies and contractors. For example, NSA has recommended that government agencies use AES to protect sensitive data, which doesn't mean that they think it's perfect (or would necessarily tell us if they knew of problems with it), but presumably puts some kind of cap on how bad it can be. I'm not aware of any government infosec authority that has publicly recommended that people inside the government use Tor.
The argument for Tor's benefit for military personnel (which may or may not have panned out in practice) was all about protecting some of their activity on networks controlled or at least monitored by their adversaries. That's almost the opposite of SIPRNet.
Last I heard Tor split all data up into 512 byte chunks. So the statistical distribution of packet sizes could still give you away.
In general, Tor does not hide the fact that you are using Tor.
To be clear, the threat models of the obfuscating transports can vary, so what I've described is just a trend in emphasis, not necessarily a suggestion that nobody ever cares about obfuscation-in-retrospect. But the history of that work is around censorship circumvention, which is often a slightly different goal (with slightly different priorities) than confidentiality.
For example, I've heard people who work on obfuscation talk about how it would be good if something required an expensive calculation in order to distinguish from other traffic types. They care about this because a national firewall may not have sufficient capacity to do this in real time.
Depending a lot on your threat model, Tor might still be a benefit even if people do know you are using it, supposing that they don't know for what.
And then they can use the rubber hose method to find out. Knowing that you have traffic you want to hide is almost as good as knowing the traffic
Since it doesn't look like saudi arabia is blocking traffic to/from major cloud hosting providers (obviously, they'd break most of the internet), this person could simply run a remote desktop session as something like VNC-over-https-by-TLS1.3 (apache guacamole or similar, lots of things).
Or use any of a number of US-based companies that will sell you a cloud-hosted remote desktop system you can use via an HTML5 client inside chrome, firefox, edge or safari, again, over TLS1.3
If the saudis are breaking TLS1.3 in an up to date browser in a client workstation that doesn't have some kind of APT/rootkit on it (also a high risk), we have other problems.
And then keep the saudi workstation as basically a thin client only.
It would look indistinguishable from any ordinary company persistent TLS session used between a workstation PC and some business application hosted in the "cloud".
All of the above doesn't help much if subject to rubber hose cryptanalysis.
They wouldn't need to break TLS 1.3 if they have access to root certificates, they could use them to perform MitM attacks.
It's trivially easy and almost undetectable for any nation-state to perform targeted MitM against HTTPS. It wouldn't be legally possible in most of jurisdictions, but Saudi Arabia isn't exactly "rule of law" country.
Uzbekistan tried, because they wanted zero-risk mass surveillance.
That said, I am no specialist however, I am pretty sure pattern matching does not really work reliably.
The most common attack to de-anonymize tor users in the recent years is getting control of their server and than match incoming traffic with outgoing traffic from their country and basically catch them logged in. However as you can tell this needs international cooperation and a bit of work.
https://www.thesecmaster.com/4-types-of-attacks-on-the-tor-n...
The linked article tries to imply that Ross Ulbricht's arrest was somehow the result of deanonymized tor traffic, but in reality many (most?) large DNM [1,2] and malware/hacking arrests seem to be the result of poor opsec [3].
[1] https://www.ivpn.net/privacy-guides/online-privacy-through-o...
[2] https://en.wikipedia.org/wiki/AlphaBay#Seizure_and_shutdown
(I also undertstand that even if something isn't technically illegal it can bring the heat of LEOs upon you)
Or. Well. It is same easily detected, but you can reasonably say you have VPN "just to watch US netflix" or something like that.
You cannot say that about Tor.
Was it a career in the IC?
Tor is almost always detectable. You can see someone is using Tor, but not what theyre doing with it.
Just started wondering: If Tor disappeared off the face of the earth right now, what would be the replacement?
1. Would it be an existing alternative that would become dominant in the space?
2. Would an identical software/network be built?
3. Would something new (and better) be built to replace it (and how would that look like)?
Firefox is only now catching up in regard to site isolation.
Yes, but firefox has other benefits. if only that, a cooperative team that's happy to take patches as part of the "tor uplift" project, whereas Chrome wants to fingerprint every single user and makes projects like TBB harder to implement.
Also, i personally think it's a good thing that TBB is a noscript-first browser. Everything involving JS, even with a 10 feet pole, is a glaring security issue. So yes you can enable JS and the site isolation isn't the best, but truth is just use "Safest" mode and you'll be fine.
Also Torbrowser uses a security-hardened version of FF LTS, so it's pretty useless to assume FF vulnerabilities all apply to Torbrowser.