Dev/Permanent Takedown Attack Defender

From Whonix

< Dev(Redirected from Dev/pdt)


This is a proposal to defend a Permanent Takedown Attack (PTA). A mechanism to securely download project metadata, which includes censor resistance, defeating rollback and infinite freeze attacks.

Both, TUF (The Update Framework)[1] [2] and PTAD (Permanent Takedown Attack Defender), do not require software to be running on a server and can be run on any (free) web space. [3]

TUF cannot defeat a PTA yet. [archive]


Definition by this page:

Project metadata. Is defined as version information, news, update information, project homepage and so on.

Definition by this page:

Permanent takedown attack. An attacker takes down a mirror by taking over the domain or by taking down the server using DoS[4] attack, cracking down the server with malware or by pressuring humans (the server administrator).

Quote: TUF: Attacks and Weaknesses[5]:

Rollback attacks. An attacker presents a software update system with older files than those the client has already seen, causing the client to use files older than those the client knows about.

Quote: TUF: Attacks and Weaknesses[5]:

Indefinite freeze attacks. An attacker continues to present a software update system with the same files the client has already seen. The result is that the client does not know that new files are available.


What happens if an adversary ever manages to ban project websites such as Tails or Whonix ™? domain and server lost, Whonix ™ kicked from server not getting any other hosting platform.

The project admins will lose the ability to inform their users about critical security updates and communications break down. Users will no longer be able to visit the original homepage, which could even get replaced with a malicious version.

It would take some time to reorganize hosting, move to censor resistant hosting and to inform the existing user base.


Using a single server, i.e. single domain/server for project metadata is recommended against, as it introduces a single point of failure. When the server goes offline, project metadata can no longer be distributed. The server could also serve either due to a bug or by malicious intent a gpg signed, but outdated project metadata.

To prevent disclosing which software is fetching project metadata, the request must go through Tor. Identity correlation through circuit sharing must be circumvented by using a separate circuit for project metadata fetches.

GPG signing of project metadata is a must, since it is independent from SSL certificate authorities.

The public key of the signer must be included into the software project at build time. Distributed trust could be implemented by using X signing keys and defining, that project metadata has to be signed by at least Y of X signers to be accepted as valid.

Apparently, there is not any distributed censor resistant data storage available over Tor. Freenet is a distributed censor resistant data storage, which can unfortunately not be accessed over Tor. [6] Otherwise Freenet could be well suited for this purpose. This is likely not going to change anytime soon.[7]

Had a constructive discussion with GNUnet devs. Will wait for the next stable announcement.[8]


There are web services run by different organizations, which allow (free) web hosting, which can be used for project metadata. Examples are github pages, sourceforge file release system and free onion hosting services.

Below is an example, how a project metadata file could look like.

Hash: SHA512

projectversion: 9

metadataversion: 536
validuntil: 1369159330


news: No important news.

mirror 1:
mirror 2: http://su6ephfi7dtxnbtb.onion/whonix_news.asc
mirror 3:



Such a project metadata file is supposed to be initially copied into the project's binary distribution at build time. The purpose is to initially equip the metadata fetcher with a list of mirrors.

From all available mirrors, the metadata fetcher uses all [9] mirrors at each run time to download the current project metadata. If metadata mirrors are modified or expanded, the updated file will possibly be stored persistently and overrule the metadata file which was included at build time.

The projectversion variable contains the version of the project and can be anything. The homepage variable contains the latest homepage of the project. It can be useful to inform users about the new homepage in case the old one has been taken down. The news variable contains a plain text string. Most of the times it shouldn't contain anything and should only be used to inform users about urgent things, such as when a takedown attack is in place.

The metadataversion variable is a consecutive number, i.e. after 536 follow 537. Each update of the metadata file increases that number. The client may not accept lower metadata version numbers, than the client already knows about. This should defeat rollback attacks.

Defeating indefinite freeze attacks is technically a bit more difficult. Each metadata fetch against a different mirror has to go through its own Tor circuit. Going through its own Tor circuit, most times a different Tor exit will be used (and connections to onion services are stream isolated so or so). This will result in using different ISP's to connect to the metadata mirror and as long as not all Tor exit relays or all Tor exit relays's ISPs or all metadata mirrors are compromised, no indefinite freeze attack can be successfully mounted. When fetching from onion services, there are no ISP's involved, who could tamper with the metadata.

The validuntil variable represents how long the file is valid, until the mirror is considered outdated. The number represents the time in unixtime[10]. If a mirror is considered outdated, a new mirror will be tried.

Distributed trust for the signers has not yet been considered. The signers gpg key is fully trusted. To implement this, one could look into the TUF project, since the TUF project already contains code to define a threshold of signers.

Specifically for Whonix ™, whonixcheck and the Whonix ™ News Format could be extended.

See Also[edit]


Fosshost is sponsors Kicksecure ™ stage server Whonix old logo.png
Fosshost About Advertisements

Search engines: YaCy | Qwant | ecosia | MetaGer | peekier | Whonix ™ Wiki

Follow: 1024px-Telegram 2019 Logo.svg.png Iconfinder Apple Mail 2697658.png Twitter.png Facebook.png Rss.png Reddit.jpg 200px-Mastodon Logotype (Simple).svg.png

Support: 1024px-Telegram 2019 Logo.svg.png Discourse logo.png Matrix logo.svg.png

Donate: Donate Bank Wire Paypal Bitcoin accepted here Monero accepted here Contriute

Whonix donate bitcoin.png Monero donate Whonix.png United Federation of Planets 1000px.png

Twitter-share-button.png Facebook-share-button.png Telegram-share.png link=mailto:?subject=Dev/Permanent Takedown Attack Defender&body= link= Takedown Attack Defender link= Takedown Attack Defender link= Takedown Attack Defender%20 Takedown Attack Defender

Want to help create awesome, up-to-date screenshots for the Whonix ™ wiki? Help is most welcome!

https link onion link Priority Support | Investors | Professional Support

Whonix | © ENCRYPTED SUPPORT LP | Heckert gnu.big.png Freedom Software / Osi standard logo 0.png Open Source (Why?)

The personal opinions of moderators or contributors to the Whonix ™ project do not represent the project as a whole.

By using our website, you acknowledge that you have read, understood and agreed to our Privacy Policy, Cookie Policy, Terms of Service, and E-Sign Consent.