The first major release that lacks all support for most tor onion service domains. Tor v2 code was removed for security reasons. But the community still mostly uses v2.
Doubtful. At some point it is likely the tor project will use their control of things to push a version consensus flag that will block v2 supporting relays from participating in the network.
It's most like going from http to https in that it changes the fundamental systems beneath it resulting in having stronger keys, longer keys, composed with different tech. You notice the new onion addresses are much longer, and created differently, this is that change.
Unlike IPv4 IPv6, there isn't an authority name service to advertise both connectable addresses. This makes discovery for the end user an explicit action.
If they cannot connect on V2, the method to discover v3 is almost definitely out of band and potentially in the prone to hijacking.
I thought there was some meta tag you could stick in your page's HTML that said what its onion address was; couldn't you just add that with the v3 onion address and clients connecting over v2 would see it and switch over just as if they'd started from non-TOR?
So it would be best if those services simply advertise their new address on the v2 domain right? Rather than sit still and lose their traffic when everyone's forced to, or when attacks really become feasible.
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.
Sure, but that's not effort on the site's behalf so they can switch over and make the V2 show the redirect notice. If IPv6 would have been this simple, just show a redirect, we'd have upgraded long ago...
Yes, it probably is. Most people use tor because they just want a pseudoanonymous proxy to the clear web. For them the switch to v3 internally is important and probably required. For users of the .onion and onion services in general it's more split but I think most would say v2 going away is good. Soon it will be possible to spoof v2 domain prefixes at a feasible cost.
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.
The depreciation of v2 addresses is the best course of action in this case. v2 addresses consist of the first 80 bits of the SHA-1 hash of the hidden services 1024 bit public RSA key. This sentence alone is enough to make any cryptographer cringe, it is really bad! (SHA-1 has been shown to be broken and it is suspected that 1024 bit RSA can be cracked by any determined well funded state actor)
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.
It's not the fact that the hash of the public key is exposed, it's the fact that
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.
For 2) my understanding is that the security issues in sha1 are not relavent to finding preimages, which if im not mistaken is what you would need to take over an onion address. But maybe im mistaken.
I am curious: why can't you redirect your community to a new v3 address? Deprecating v2 onion services has been publicly planned for several years now, and it is being done for security reasons (e.g. name collisions and weak crypto). Honestly, it would seem irresponsible of the Tor community not to stop supporting insecure versions of Tor.
I should probably add something about that to the post.
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.
1. For now
2. That kind of traffic mostly died out with plugins like Flash, streaming media today is usually encapsulated in small frequent chunks over the same https channels as the rest of the page are delivered as that's what's available in JS/native. WebRTC reintroduced some UDP stuff and can be used for streaming but is still mostly used for peer to peer calls.
3. https://gitweb.torproject.org/tor-browser-spec.git/plain/pos...
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.
It's easy to get a webrtc fingerprint just using a public stun server, maybe people smarter can deploy their own. I've used it in our ad tracking js.
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.
> 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.
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).
> streaming media today is usually encapsulated in small frequent chunks over the same https channels as the rest of the page are delivered as that's what's available in JS/native
QUIC and HTTP3 are great technologies, but they are never likely to become the only protocol a service supports.
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.
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.
Thanks for all the knowledge. What is your interest in these protocols, out of curiosity?
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.
> Thanks for all the knowledge. What is your interest in these protocols, out of curiosity?
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.
My other daily browser is Firefox ESR, so Tor Browser 11 is the first I've seen these strange new tabs.
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.
Precisely this. Tor browser after this update looks pretty FU'ed. I hope they are going to fix this one ASAP.
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.
TOR has been an invaluable tool for me for its ability to circumvent state censorship in an undetectable way.
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.
I don't know the parent or their situation, but if you need similar security I would be very cautious about taking the parent literally. Sorry if I sound like a jerk; it sounds like the parent has taken great risks for the public good, but I don't want people to be hurt:
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.
The parent poster who thinks they're saved from Saudi arabian domestic intelligence agencies by using tor is probably overly confident about how much tor is doing for them. The saudis absolutely have lots of money to pay for good quality DPI boxes from China. Using tor by itself stands out.
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.
> 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.
They wouldn't need to break TLS 1.3 if they have access to root certificates, they could use them to perform MitM attacks.
> 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.
I wouldn't be surprised if the Saudis have access to the root signing certificates themselves. They wouldn't have to put new certificates in computers' trust stores, as computers would ship from manufacturers already trusting certificates that were signed with those root signing certificates.
As marshray said below, Tor doesn't generally try to hide the fact that you're using Tor, only what you're doing with it. This is complicated by the very active research on obfuscating methods for accessing Tor, but those methods are mostly trying to prevent automated large-scale detection in real time, in order to evade blocking by national firewalls. They aren't necessarily trying to prevent more manual or after-the-fact forensics that might confirm that a particular person was 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.
I'm not sure if you're aware but Tor has a specific mode for OP's situation, where it disguises traffic by using standard TLS on standard ports which looks no different to any other HTTPS traffic for example, among other things.
I think the end solution is not to have TOR replicate normal randomish usage, but to have normal usage from everything go through a tor like process so that everyone looks the same.
That would require active participation of major entities who distribute HTTP clients, such as Mozilla, Apple, or the Chromium team. I cannot imagine them participating.
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).
I think this is an exaggeration. The Tor technology was originally invented by researchers with the U.S. Naval Research Laboratory, who suggested that the system might be useful to Navy personnel among others. While Paul Syverson, one of those researchers, has remained involved with Tor since inventing it, no one from the Navy has ever publicly stated how or to what extent Tor is used by the military operationally.
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.
Very different concept from Tor -- this is about passing sensitive information between dedicated government facilities, not about hiding some of the details of your activity on the public Internet.
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.
Tor on it’s own is definitely not a panacea. However, interested parties should look into Qubes OS. If detection is a huge concern, there is always the potential you could bridge your sensitive traffic in a less obvious manner. I believe you can configure this with a Qubes Whonix setup by selecting the “Tor is dangerous or censored in my area” option. It’s pretty powerful. I haven’t personally tried this as I don’t actually use Qubes except to play around with its neat VM setup.
FYI in ops security model they likely used bridges, which are not on a public list as the other nodes.
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.
Tor has long been billed as a tool for journalists to fly under the radar and avoid persecution, but it's great to hear these case studies from the horse's mouth. Thanks to you and other journalists who risk life and limb to report on and within these abusive regimes.
Is a VPN illegal in Saudi Arabia? My girlfriend is Qatari and everyone there uses VPNs to access Pornhub etc. She says that while the state censors the Internet it does not criminalize the use of VPNs. It's a confusing issue.
(I also undertstand that even if something isn't technically illegal it can bring the heat of LEOs upon you)
How is that possible? The fact that you are using Tor is detectable by ISPs just like it is detectable that you are using VPNs. Also, it's sometimes possible to de-anonymize your Tor traffic, and state-level actors would be capable to do so if they wanted.
Look at the language of that page. All the statements are without certainty, eg it's not "an adversary cannot identify them" but "an adversary cannot identify them easily."
Yes, the tor project is very transparent that anonymity is not guaranteed. Bridges and obfuscation tools are simply one possible answer to the "how is [connecting to tor without ISP detection] possible?" question.
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].
Obfuscation is a cat-and-mouse game and with enough resources, it's always possible to detect. While Tor is OK for privacy from your ISP or the big-tech firms, certainly not for what the OP described. I think recommending Tor as the definite solution for these types of people is irresponsible.
If you ever see security software that promises absolutes, you should view it like an investment opportunity that allegedly only goes up and can't possibly go down (i.e. you're about to lose all your money)
Same. The world would feel quite dystopian without Tor, Signal and other similar software aiming to preserve your privacy. I rarely use Tor but I'm soooo happy it exists.
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)?
If TOR went away tomorrow, I assume i2p would pick up the slack; it's already there and AFAIK a good alternative, just with a smaller network and less emphasis on exit nodes.
Network isn't even necessarily smaller. Since it has a lesser emphasis on exit nodes, each node is a relay and there are more of them than Tor relay nodes.
I don't know about the low level / security details. But the Tor team constantly pushed good upgrades for a long time. Seriously impressive. Works great and is slick on pc and mobile.
Security. I'm a die hard Firefox user. But chromium has insanely good site isolation and some other great security features. It was built with privilege separation in mind almost since day one, something Firefox does not do. My source here is OpenBSD devs, who said that Chromium was easy to sandbox with pledge+unveil, because for the most part the code was already written in such a way (to separate privileges). Firefox was a pain to sandbox, because its code is not written in the same way.
Firefox is only now catching up in regard to site isolation.
> 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.
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)