Re: Great idea, compromised right at its heart by insisting on using systemd
I was handing out TAILS live-DVD's at an open day a few years ago and someone rapidly deployed HUMINT to talk to me for an hour (how do I install it, do I have to put it in the coffee-cup holder, which way up? etc etc), just to stop me handing more DVDs out!
I remain astonished. [I was suggesting that the DVDs should be used for secure home banking, this was *not* the revolution that you were looking for]
TOR at the time had unique multiple fingerprint stained traffic(*) so I guess *they* just didnt want to dilute real exciting 'colorful' stuff with random users.
(*) in 2011 Tor claimed that their software protected users in two ways: i) Tor protects your communications from ``traffic analysis;'' and ii) Tor provides ``anonymity.'' Neither of these was always completely true.
Tor uses/used a public key exchange protocol called Diffie-Hellman to establish an initial encrypted connection between the user and an ``entry node.'' However, the parameters to this exchange -- which were sent unencrypted on the wire -- were chosen to be those defined as the ``Second Oakley Group'' (RFC 2409). No other web software used/uses these parameters. Thus, if traffic on the wire is observed to be communicating these parameters, it is almost certainly traffic generated by Tor. In other words, the use of these specific parameters was a unique signature which identifies Tor traffic from all other encrypted traffic
Another TOR bugdoor of that era, around TOR version 0.2.1 of the stable branch
Tor uses/used SSL to secure communications between Tor nodes and clients. When a Tor client wishes to connect to a Tor node (including `bridge' nodes), the node presents the client with an SSL Server Certificate. The problem is that the Common name field in this certificate is literally gibberish. The Tor node fills this field with a domain name generated at random, i.e. one that does not actually exist. For example, a typical Common Name field in a Tor node SSL Server Certificate could be ``www.s4ku5skci.net'' If one were to try to resolve this domain (e.g. using the command `nslookup http://www.s4ku5skci.net'), an error would be returned, since this is not a real domain name. Recall that SSL Server Certificates are/were sent unencrypted on the wire -- before an encrypted connection is established.
This behaviour (filling certificate fields with gibberish) is unique to Tor, i.e. no other SSL-capable server software does this; not Apache or any of its derivatives, not Microsoft's IIS, not Oracle's iPlanet... Even self-signed SSL Server Certificates (used by people who cannot afford one signed by a Certificate Authority) typically contain either an IP address in the Common Name field, or an empty Common Name field.
Therefore, all an ISP or government observer would need to do to unmask Tor traffic is to look for connections where SSL Server Certificates are/were being sent (this is trivial with DPI technology), attempt to resolve the domain(s) in the Common Name field, and if that fails, mark that connection as being Tor traffic, or block it altogether.
A third 'bugdoor' of the time
Historically, the Common Name fields in Tor SSL Server Certificates all begin with 'www.' and ended with '.net'. Simple SPAM traffic analysis tools are/were trivially adapted to identifying Tor traffic handshaking.
hopefully nowadays TOR 0.3.3.x has no bugs ;-)
I'm now focussing on renewables not security