Onion Service version 2 deprecation timeline

Thank you so much for your reply! This is a good example of the kind of useful basic information I'd like to see more of here, as opposed to posts which sometimes appear intended mostly to keep grantors happy (although those posts also have value).

Indeed, I was asking about CVE-2019-13050 (key-bombing or sig-bombing).

I have been downloading keys from multiple sources and checking full fingerprints, subkey expiration dates, etc, for many years (I see that trick is also mentioned in another reply below). That is, I obtain what should be the correct key in two or more ways (using gpg itself from two keyservers, and https via Tor Browser) from various sites, giving them different file names, then import them into GPG running in a temporary instance. GPG running in Tails should kick if they do not appear to be the same key (often some versions show sigs others lack, of course, which is expected). I also store multiple copies of what should be the correct key in multiple well encrypted places (USBs, encrypted directories on hard drives, etc) and periodically check them against each other. The hope is that even an attacker who gains illicit access to one or more of my devices will not be able to anticipate all the things I do and that (hopefully) if the worst happens I will notice something appears to be wrong.

You make a very good point about a GPG key downloaded directly from a trusted website such as www.torproject.org being free of spammed sigs, a point which had not occurred to me. Previously I had given more weight to uncertainty that a bad actor might have replaced the genuine key without being noticed (I certainly hope TP has regular checks against that), or that despite https and certs my Tor Browser might have somehow been tricked into using an imposter site. Thus the fallback upon trying various ways to try to catch a hypothetical impostor key in a contradiction.

> Secondly, I believe most or all of the keyserver implementations have patched against this. Spamming attacks take up a lot of space and bandwidth on the keyservers themselves. In response, many servers have begun discarding signatures that are unknown, or those that don't link to an existing web of trust.

Good to know; thank you.

> As one example, keys.openpgp.org decided to give up and just stop accepting signatures altogether.

That is one of the keyservers I use for some of my attempts to catch hypothetical imposter keys. (Well, not entirely hypothetical since we know bad actors or jokers have in fact submitted fake keys.) Has anyone else noticed that pgp.mit.edu has become less useful over time?

The web of trust has problems but I think it retains value. I think signing keys with keys which have been known for a long time and which themselves are signed is valuable. Before key bombing became such an issue I did extensive sig checking at least once a year, for critical signing keys.

> Third, it's a well-known vuln and every current version is patched.

Very good to know. This is a good example of the kind of very important very useful and morale-improving information which I would like to see TP share, perhaps in a regular Fri afternoon "Have you heard?" post in which Tor users are allowed to raise questions they would like to see answered in the comment section.

> Even so, at worst it's a temporary denial of service attack. You should be keeping regular backups of your public keyring in the first place, as it can become corrupt for any number of reasons ranging from power failures to ransomware

Right, I am doing that but will do it more.

I have lost at least two computers to power failures (third world power distribution although things are getting a bit more reliable). A related source of keyring corruption or loss is that equipment dies for mysterious reasons, often several at the same time, which seems suspicious.

The laptop I am using right now seems to work fine using Tails 4.8 but unfortunately has a very nasty habit of freezing up every hour or so under Debian 10.4 with MATE. One of my guesses is that an unfixed bug in Wayland (when a device possibly lacks drivers/firmware written for the exact same make and model device) is somehow involved, leading to concern that when Tails adopts Wayland in future versions it may suddenly become unreliable.

> Also note that, from what I understand, GPG automatically keeps a backup of the keyring, which is updated after every *successful* operation. If your keyring gets corrupted during an import, you should be able to replace pubring.gpg with pubring.gpg~ and be back where you were before.

Yes, I have never tested that but I believe that is true. Obviously won't help guard against malicious deletion but as you say other sources of data loss are probably more likely for most of us.

These points would all be good to add to the Tor Browser documention, ideally in a seperate page, perhaps called something like "Useful GPG Tips and Tricks".

I agree with you that GPG FUD is unwarranted, dangerous, and possibly in some cases coming from bad actors who hate strong encryption. As you know, for many years, GPG was maintained by only one person upon whom the entire world depended, and eventually began to break, but I understand more people finally joined the team, the code was rewritten and much improved (for one thing, GPG became much faster!). It's over-featured but invaluable if only because its used to verify ISO images and tarballs for everything else. I also still use it to encrypt files (both data at rest and data in motion). It is possible to use short shell scripts to avoid typing multiple flags in GPG commands.

Incidently, existing elliptic curve crypto tools in the Debian repository are still more at the level of ill conceived and hard to use school programming projects. We need tools written in the true unix spirit (do one thing but do it very well), in particular which play nice with the pipe.

I am trying to save all the links but I often cannot find them when I need them in a high stress situation, so it would be nice if TP had some useful concise FAQ pages bookmarked in Tor Browser itself. Of course, all TP pages should have a date ("last modified") because people might stumble over them via a search engine 10 years from now, by which point the information may be dangerous out of date.

As far as I know, all Tor Project onions are v2 at the moment. See: https://onion.torproject.org/ Open an issue on https://gitlab.torproject.org/ to request v3 onions. Which repository should it be posted under? Don't know.

Onion addresses of other websites cannot be authenticated by Tor Project but only by those websites. From the perspective of those hosts and their visitors, Tor Project is a third party and cannot provide proof of their addresses. See: https://trac.torproject.org/projects/tor/wiki/org/projects/WeSupportTor

Starting from Tor Browser 9.5, the host itself can hint to the browser that it has an onion address by adding the HTTP header, "Onion-Location". The browser can then automatically redirect you from the "clearnet" ("surface web") hostname to its onion. You can view the header in Tor Browser (Firefox) by opening the Main Menu --> Web Developer tools --> Network tab. See: https://stackoverflow.com/questions/33974595/in-firefox-how-do-i-see-ht…

LUKS encryption applies to all files you save in it no matter if they are related to Tor or not. You may be ordered or coerced to decrypt data or give the passphrase by court order, legal warrant, legalese, social engineering, threat of harm, or other situations, particularly at national borders and airports.
- https://www.theverge.com/2017/2/12/14583124/nasa-sidd-bikkannavar-detai…
- https://www.aclu.org/blog/free-future/can-border-agents-search-your-ele…
- https://ssd.eff.org/en/module/things-consider-when-crossing-us-border

The "keyring-bombing problem," as you call it, is circumvented by the updated instructions on Tor Project's Support site that specify the wkd (Web Key Directory) key-locate mechanism. Developers of Tails instruct to download its key from Tails' website.
- https://support.torproject.org/tbb/how-to-verify-signature/
- https://wiki.gnupg.org/WKD
- https://tails.boum.org/install/download/

As always, the 40-character fingerprints of the keys can be viewed in gpg and compared to online sources. In general, it may be possible to corroborate a key by downloading copies of it from different sources at different times through different exit nodes or public IP addresses and import the copies one by one to be sure they all have the same fingerprint. See sks-keyservers. Verify keys on a machine you trust, and locally sign the key ("lsign" in gpg) to mark it in your keyring as authenticated. You can export your entire keyring or specific keys from gpg to save in your LUKS encrypted volume and import them into Tails' gpg anytime. Optionally consider gpg's "export-clean" or "export-minimal".