1 Introduction

In this document we present a specification of a Privacy Enhancing
Live Distribution (PELD) as well as an actual implementation of it called
The Amnesic Incognito Live System (in short: Tails).

By writing this document we intend to help third-parties do
security analyses of any given PELD and specifically of Tails.
We also wish to help establish best practices in
the field of PELD design and implementation, and thus raise the
baseline for all similar projects out there.

This document is heavily based on preliminary work that was done as
part of Incognito 2008.1-r1
Documentation.
The Bibliography section has pointers to other inspiration and reference sources.

2 Privacy Enhancing Live Distribution Specification

Note: the key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
RFC 2119.

2.1 Intent

Let us introduce what the PELD goals are: the features provided by the
PELD, the kind of user the PELD targets, and the (empty) room we think
the PELD fills in the Tor distributions landscape.

2.1.1 Privacy on the Internet

The Privacy Enhancing Live Distribution (or PELD for short) aims at providing
a software solution providing the user with the technological means
for using popular Internet technologies while maintaining their privacy,
in particular with respect to anonymity. While there are
different techniques and services providing that functionality, this
specification will assume the usage of The Tor™
Project's state-of-the-art anonymizing
overlay network Tor.

Due to its deep dependency on Tor, the PELD defers the same possible
goals as Tor:

The PELD does not try to conceal it is connected to the Tor network
unless Tor bridge relays are used.

The PELD is not secure against end-to-end attacks, such as
end-to-end timing or intersection attacks.

Moreover, the PELD is likely to be affected by any feasible attack
against Tor; e.g. the PELD is not secure against some local attacks,
such as confirmation attacks based on website fingerprinting: see Lexi
and Dominik's Contemporary Profiling of Web Usersconference at
27C3
for details.

2.1.2 Protection from data recovery after shutdown

The PELD aims at protecting the user from post-mortem analysis
of the equipment (notably storage media and memory) he or
she runs the PELD on. It is impossible for such a system to determine
which information is sensitive and which is not. Thus, the PELD MUST
be amnesic by default:

It is REQUIRED no trace is left on local storage devices unless the user
explicitly asks for it: the PELD MUST take care not to use any
filesystem or swap volume that might exist on the host machine hard
drives.

The usage of encrypted removable storage devices (such as USB
sticks) SHOULD be encouraged.

Volatile memory MUST be erased on shutdown to prevent memory
recovery such as cold boot attack.

Secure erasure of files and free disk space SHOULD be made easy.

2.1.3 Working on sensitive documents

The PELD aims at providing a "safe" environment to produce and
optionally publish sensitive documents. While the combination of
anonymous access to the Internet and resistance against future
equipment analysis does most of the job, some application-level
attacks deserve special treatment: e.g. tools needed to inspect and
cleanup metadata — such as EXIF data — in files SHOULD be available.

2.1.4 Portability

The PELD MUST be self-contained and portable (literally, not
necessarily with respect to code portability), and thus possible to
run in as many computing environments as possible from the same single
distribution. In addition, while the PELD's main objective indeed is
to act as a traditional Live Distribution (i.e. a Live CD or
Live USB) it SHOULD also be compatible with popular
virtual machine technologies for users who simply want a sandboxed
environment within their usual operating system.

2.1.5 Target user

The PELD's target user is the average user in terms of computer
literacy; he or she does not necessarily control fully the computer
being used. Examples would be a public computer in a library, coffee
shop, university or a residence. We assume that the target user does
not want to do any configuration (at least with respect to
security and anonymity) of the various applications and tools used
themselves, either because of insufficient knowledge, lack of interest
or other reasons. The PELD MUST provide strong anonymity with no
need of advanced configuration whatsoever. It MUST be made as
difficult as possible for the user to unknowingly compromise
anonymity.

2.1.6 Filling some empty room in the Tor distributions landscape

XXX: update

The PELD is meant to be complementary to other Tor distributions. It
has no such goal as replacing other existing tool that properly
fulfills its use cases.

The PELD fills an empty place alongside of other Tor distributions.
Using the PELD certainly requires the user to change more of his or
her habits than installing e.g. the Tor Browser Bundle. On the other
hand, the PELD currently is the only tool that makes it feasible to
use the Internet, and more generally computers, for certain activities
in contexts where the user cannot afford the risks involved by other
Tor distributions.

On the online privacy side of things, the PELD is aimed at offering
roughly the same protection level as e.g. the Tor Browser Bundle, but
provides a full-blown Tor-ified operating system instead of a few
selected and carefully configured applications; this e.g. allows to
safely download and open files using external applications, as
mentioned by the Torbutton warning popup when a user attempts such an
operation outside the PELD.

About protection from post-shutdown data recovery, thanks to its
amnesic-by-default behavior, the PELD can aim at providing a level of
protection only a fine-tuned Live operating system can offer. On the
contrary Tor distributions that rely on an untrusted underlying
operating system could hardly guarantee anything in this area,
regardless of the amount of resources and cleverness that is spent to
leave less traces on local storage:

widespread operating systems and shipped Internet applications
generally default to write all kinds of traces to local storage; Tor
distributions that depend on such systems are therefore forced to
adopt a blacklist approach to lessen the amount of traces left
behind. Such an approach is known to be prone to human error,
such as bug #7449 on Tor Project's Trac.

widespread operating systems typically offer very few control knobs
to userspace applications over their not-amnesic-by-default
behavior, especially when run without any kind of administrator
credentials. Tor distributions that depend on such systems generally
have no choice but hope no undesired trace will be left e.g. in the
system's swap file or partition.

The PELD amnesic feature also allows the user to safely perform
non-Internet activities, which is yet another distinctive trait
compared to other Tor distributions.

To sum up, one can be a Tor expert and carefully configure a
non-amnesic system to be as much Tor-ified as the PELD, but he or she
won't get the same post-mortem analysis protection.

2.1.7 Summary

In short, the PELD aims at providing privacy on computers and on the
Internet for anyone anywhere.

2.2 Threat model

The goal of staying anonymous and keeping sensitive information
protected stands in direct conflict with the goals of several entities
"present" on the Internet. The following threat model is meant to
describe the intentions and capabilities of such attackers.

2.2.1 The goal of the attacker

The adversary may have one or more goals among the following ones.

Identify or locate the user, track his or her activities on the
Internet: information such as the User-Agent HTTP header, locale
and especially IP address can all be used in various degrees to
identify or locate the user, and to track his or her activities on
the Internet.

Eavesdrop on sensitive data: the Tor network only prevents the
data from being traced (according to Tor's threat model) but does not
protect it from eavesdropping.

Data recovery after system shutdown: "normal" operating systems
keep a lot of traces about their users' Internet activities (notably
browser cache, cookies and history) on local storage media;
similary, working on a sensitive document with a "normal" operating
system is very likely to leave traces of this document. User's data
can remain on the equipment even after the machine is shut down; be
it stored in the filesystem or in the memories, both RAM and swap,
which might as well retain data (for example encryption keys or
passwords). The adversary may want to recover such information by
analyzing the equipment that has been used.

2.2.2 Capabilities, methods and other means of the attacker

The adversary may have capabilities needed to perform the following
attacks.

Eavesdropping and content injection: it is assumed that the
adversary is non-global and has full control over the network
traffic of some portion of the Internet (e.g. some Tor exit nodes,
upstream routers of exit nodes, or the ISP that provides the
Internet connection the user is sitting behind). The adversary is
thus able to eavesdrop, modify, delete or delay parts or all of the
user's traffic on the Internet.

Bypass attacks: it is conceivable for attackers to mount attacks
which bypass the proxy and DNS setup in the applications which could
then be used to identify the user, either by injecting data or
social engineering.

Exploit software vulnerabilities: the attacker might be able to
run arbitrary code by exploiting vulnerabilities present in any of
the software packages installed.

Application level attacks: the attacker can utilize certain
applications' services and features to get identifying information.
Examples are JavaScript and Java applets in web browsers, CTCP
queries in IRC clients, etc.

Physical access, live monitoring, post-mortem equipment
analysis: some users face adversaries with intermittent or
constant physical access to the equipment they use. Users in
Internet cafes, for example, face such a threat. This means the
adversary might be physically monitoring the computer while the PELD
is running on it. Moreover the adversary might raid the user at any
moment and then confiscate and analyse the equipment, storage media
and memory in particular.

2.3 Distribution

The PELD MUST be distributed in a common format that can easily be
used to install the PELD on the selected medium. For instance, if
distributed as an ISO 9660 compatible image file it can be burned to a
DVD with almost any DVD recording software available.

Also, it is RECOMMENDED to make it possible for end-users to verify
the downloaded PELD image's integrity using public-key cryptography.

2.4 Operational requirements

This section handles mostly the criteria that the PELD should be
portable and able to run in as many environments as possible.

2.4.1 Platform

The binaries MUST all be executable on the most common computer
hardware architecture(s). As of 2014, the x86 computer architecture
seems to be the obvious choice as the vast majority of personal
computers in use is compatible with it. The PELD SHOULD support UEFI.
Supporting widespread hardware architectures used in mobile
computers, such as phones, is also welcome.

2.4.2 Media

The PELD SHOULD be able to boot and run natively from either a DVD or a
USB drive. While running the PELD in native mode it MUST be completely
independent from the host operating system and all other storage media
on the host computer unless the user explicitly tries to access any of
them.

In all circumstances, binaries, dynamic libraries and other executable
code susceptible to virus infections and similar MUST always be
completely write-protected, even when running from a writeable USB
medium. Such files SHOULD not even be modifiable temporarily, which
could be the case even when running from DVD if the filesystem is
loaded into memory (e.g. tmpfs).

Configuration files, temporary files, user home directories and
similar files that most likely need to be modifiable during operation
MUST only be saved temporarily in memory (e.g. by use of something
like tmpfs or unionfs) unless the user explicitly enables some
persistence feature.

It is tempting to use the possibility to write back data when running
from USB in order to allow user settings to be persistent. If this is
considered, this feature MUST be optional and offer the possibility
to use strong encryption for the persistent storage.

2.4.3 Virtual machines

As an alternative to running the PELD natively from a DVD or USB, it
SHOULD also be possible to run it inside virtual machines.

Running the PELD is such a virtualized environment provides weakened
security compared to running it natively. This drawback is due to the
dependency on the host OS. When the PELD runs as a guest OS:

The PELD cannot defend against keyloggers, viruses and other malware
that could be present in the host OS. The user activities in the
PELD might thus be under surveillance by an attacker who would
control the host OS enough.

The PELD can not guarantee anything with respect to writing to local
storage: the host OS does its own memory management and can write to
swap any part of the memory being used by the PELD without the user
being told.

On the other hand, running the PELD inside a virtual machine is useful
in situations where the user is not in a position to run the PELD
natively, which often is the case with public computers. Additionally,
many users seem to prefer this mode of operation and would prefer to
use their usual operating system instead of rebooting to run the PELD
natively; that alone is a reason for making sure it works.

2.5 Other considerations

2.5.1 Maintainability

The procedure to update the PELD SHOULD NOT be prohibitive to provide
timely software updates that address issues related to security or
anonymity. A scripted, automatic build procedure is RECOMMENDED
over manually setting up things.

2.5.2 Sustainability

PELD development SHOULD be a team work rather than a one person work,
and the deep knowledge of this work SHOULD be shared among the team
members. Thus the development infrastructure SHOULD be designed and
deployed in order to share this knowledge.

2.5.3 Open-source transparency, easing peer review

For the sake of transparency the use of open-source software is
RECOMMENDED. Binary blobs SHOULD only be used when no good alternative
exists, which could be the case with certain hardware drivers or driver
firmwares.

Having third-parties analyze the PELD security is necessary to ensure
it is working as intended. It is thus REQUIRED for the PELD itself
to be open-source. Moreover decisions with non-trivial implications
SHOULD be clearly and publicly documented: such information about what
a PELD implementation intends to achieve and how it does so SHOULD be
made available to reviewers.

Third-parties SHALL be able to reproduce a PELD implementation by
building it from the released source code and publicly available
information. The process MUST yield consistent results.

2.5.4 Easy feedback

In order to collect bug reports and wanted features, the PELD project
SHOULD offer easy ways for end-users to provide feedback to the
developers (email, web forum, bug tracker, shipped-within
application, ...). Efforts SHOULD be made to offer the most anonymous
(or at least pseudonymous) possible way to send this feedback.

2.6 Implementation requirements

2.6.1 Kernel requirements

The role of the kernel is mainly to provide support for the features
required elsewhere in this specification. This includes:

Good hardware support is REQUIRED: "good" is a sketchy word in a
specification. The general idea is to include as much drivers for
relevant hardware as possible, in particular for network cards
(wired and wireless), video adapters and anything necessary for
basic operation.

Support for a stateful firewall with packet filtering
capabilities is REQUIRED: it must somehow be able to sort traffic out for
transparent proxying (mentioned in the next section) to work.
Similarly, it must be able to identify and drop traffic destined to
the Internet that is not supported by the Tor network, such as
transport layer protocols other than TCP.

Security features are RECOMMENDED: with the dangers of exploitable
vulnerabilities in any code running, attempts to mitigate these on
the kernel level is a good idea. Executable space protection with
the NX bit, address space layout randomization and similar
techniques are all interesting in this respect. Access control in
the form of Mandatory Access Control, Role-Based Access control and
so on SHOULD also be considered.

2.6.2 Network requirements

2.6.2.1 Firewall

In order to prevent accidental leaks of information, proxy bypass
attacks on Tor and similar, the access to the Internet MUST be
heavily restricted by a firewall:

All non-TCP transport layer protocols SHOULD be dropped as they are
not supported by the Tor network.

All TCP traffic not explicitly targeting Tor SHOULD be redirected to
the transparent proxy (i.e. to the TransPort as set in torrc);
alternatively this traffic SHOULD be dropped (then only applications
explicitly configured to use Tor will reach the Internet).

All DNS lookups SHOULD be made through the Tor network (i.e.
redirected to DNSPort as set in torrc).

All IPv6 traffic SHOULD be forbidden as it is not supported by the Tor
network.

Note that the above is not necessary (or desirable) for local network
(RFC1918) addresses; it is RECOMMENDED to special-case DNS queries
though as some home gateways and captive wifi portals reply the public
IP provided by the ISP when one asks information about themselves to
their DNS resolver (source: The State of the DNS and Tor Union (also:
a DNS UDP
- TCP shim)
thread on the or-talk mailing list).

Any exception to these rules MUST be thoroughly thought through and
properly documented. If an action that is excepted from the above
rules is user initiated, that MUST be made obvious to the user, and
user opt-out MUST be offered, if possible.

2.6.2.2 Fingerprinting

Efforts SHOULD be made so that it is harder to fingerprint PELD users as
being using the PELD. Considering this goal can conflict with others,
trying to reach perfection in this domain is not necessarily
reasonable.

2.6.3 User interface and applications

2.6.3.1 General user interface

The user SHOULD be able to do all relevant things with easy-to-use
graphical interfaces. The PELD SHOULD present a solid, user-friendly
desktop environment with all the expected features after booting: file
management, system settings configuration, support applications etc.

2.6.3.2 Internet applications

At least clients for the following Internet activities MUST be
supported:

Web browsing: since the web browser is arguably the most used
end-user Internet application as well as the one that offers the
largest attack surface, the Tor Project has spent significant
resources on analyzing and mitigating the many pitfalls of modern
web browsers with respect to anonymity: media plugins,
browser-specific bugs, web technologies such as JavaScript, CSS and
cookies, etc. Benefiting from this work is essential for maintaining
anonymity, so it is REQUIRED to include only web browsers that are
endorsed by the Tor Project, accompanied with any configurations,
extensions/plugins, etc. that they recommend (for instance, Tor
Browser Bundle). The PELD browser fingerprint SHOULD make the PELD
users appear uniformly among Tor users with generally recommended
configuration, such as Tor Browser Bundle users.

Email: support for PGP or S/MIME is highly RECOMMENDED. Also,
beware that the EHLO/HELO sent to the SMTP-server will contain the
host's IP address in many email clients. The Message-ID headers and
HTML/JavaScript email support are other usual leaking spots that
MUST be taken care of.

P2P file-sharing such as BitTorrent: note, however, that large
scale file-sharing activity in general is frowned upon in the Tor
community as it consumes extreme amounts of network resources
compared to other kinds of services.

Given that these applications will be the user's interface to the
Internet, they MUST be chosen and configured cautiously, and with
security in mind. In general, as little information as possible SHOULD
leak about the user, the applications used and the system settings.

2.6.3.3 Document production applications

A great deal of communication over the Internet is done via the
distribution of different types of commonly used media and document
formats, so the PELD MUST contain the basic facilities for creating
and editing such formats. More specifically, at least the following
media and text production tasks MUST be possible using software
shipped by the PELD:

Word processing

Bitmap and vector graphics

Sound recording and editing

Desktop publishing

Printing and scanning

Other RECOMMENDED media and text manipulation tools include:

Video editor

Spreadsheet

Presentation software

Gettext catalogs (.po files) editor

These applications SHOULD be compatible with widely spread file formats in
their domain.

2.6.3.4 Cryptographic tools

Tools for securely signing, verifying, encrypting and decrypting files
and messages SHOULD be available. In particular, some implementation
of OpenPGP SHOULD be included as it is the de-facto standard for these
tasks in the Free Software world. GUIs for managing keys and
performing the relevant cryptographic tasks SHOULD be available. The
OpenPGP implementation SHOULD be pre-configured to use an encrypted
tunnel when connecting to a keyserver (read: hkps://).

Tools for creating and using encrypted storage containers are also RECOMMENDED.

A password manager SHOULD be included and allow one to store many
passwords in an encrypted database which is protected by a single key.
This is meant to encourage users to use strong passwords, and to
discourage password reuse.

Any cryptographic tool shipped in the PELD SHOULD by default use
up-to-date parameters with respect to the current commonly agreed best
practices: digests, ciphers and key sizes.

2.6.3.5 Tor

Only stable releases SHOULD be considered since Tor really is at the
core of the PELD.

Tor SHOULD be set up to enable its DNS server (DNSPort) to allow DNS
lookups through the Tor network; alternatively a local DNS server can
be configured to use Tor.

If transparent proxying (as opposed to dropping non-Tor traffic) was
chosen in the network section, then Tor MUST be set up to enable its
transparent proxy (TransPort, TransListen); alternatively any
transparent proxy configured to use Tor as the parent proxy can be
used.

While there are many other interesting configuration possibilities
described in the Tor manual, care MUST be taken to avoid those that may
impair anonymity or security.

A GUI Tor controller application such as Vidalia or TorK is highly
RECOMMENDED. However, this requires opening the control port in Tor,
and thus some means of authentication will be REQUIRED
(CookieAuthentication preferably) to hinder attacks on the Tor
software. XXX: this paragraph is mostly obsolete.

2.6.3.6 Hardened tool chain and compiling

As an addition to the security against exploitable vulnerabilities
provided by the kernel, compiling software with stack smashing
protection, Position Independant Executable (PIE) and similar compiler
security enhancements is RECOMMENDED. Note that some
compiler-level options may be necessary to take advantage of in-kernel
security features. Thus the use of a hardened tool chain might depend
on the vendor distribution used to build the PELD upon. If such
techniques are not widely deployed at this level, using them to build
the PELD can require a lot of time from its developers and impact its
ease of maintenance, which would make it harder for new contributors
to get involved in the project. For this reason, compile-time
hardening features should be carefully selected to balance the costs
they impose against the extra security they bring. If using a hardened
tool chain to build the PELD is deemed to require too much energy,
resources could be better spent pushing usage of such hardening
features in the base operating system.

2.6.3.7 "Virtual" input system

Since one goal of the PELD is to permit usage of untrusted computers
while preserving anonymity, measures MUST be taken against hardware
that might de-anonymize or facilitate recording of a user, such as
hardware keyloggers. Thus a
virtual keyboard (usable with the mouse) MUST be available.

2.6.3.8 Entropy

Some crucial applications of the PELD, such as the Tor client, make
heavy use of cryptographic techniques and therefore rely on a high
quality pseudo-random number generator (PRNG). Initializing (seeding)
a PRNG is tricky in a Live system context as the system state after
boot, if not fully deterministic, is parameterized by far fewer
variables than in the case of a non-Live system.

2.6.4 Usability

Security is usually hard to get. Therefore steps SHOULD be taken in
order to make users more comfortable with the PELD, and also to
educate users about specific risks and non-intuitive situations that
may affect their anonymity on the Internet.

2.6.4.1 Internationalization

The user MUST be able to easily select his or her language of
preference among a great number of widespread ones. User applications
SHOULD be localized to fit this preference, as SHOULD system settings
such as keyboard layout.

The PELD documentation, either online or shipped within, SHOULD be
easily translatable. Software written specifically for the PELD SHOULD
be developed with i18n/l10n-awareness in mind.

2.6.4.2 Education and user help

The PELD SHOULD include an easy-to-read document explaining:

what the PELD goals (and non-goals) are. The PELD is no magic wand.

how to securely use the PELD and the bundled software.

As the user is assumed to only have the knowledge of an average
computer user, it will be required to explain some general security
concepts.

Real-world experience demonstrates that the average user quite rarely
thinks about upgrading his or her PELD copy, and is often pretty happy
unknowingly running an obsolete version affected by numerous
well-known security issues. A PELD running copy SHOULD therefore
notice it is affected by known security issues and notify the user if
a newer release fixes some.

2.7 The future

A few more or less well known issues shall be thought through so that
this specification can provide reasonable guidance about them.

2.7.1 Memory recovery attacks

Research
aims at recovering a Live system's in-memory filesystem and partial
recovery of its previously deleted contents. Most current Live systems
do not protect against that kind of attacks: at best, they erase free
memory on shutdown, leaving intact in memory any data saved in the
unionfs/aufs ramdisk branch.

This was
discussed
on the or-talk mailing list, and a new system that mitigates such
attacks is part of Tails 0.7 and newer.

This specification must warn about such matters.

2.7.2 HTTP keepalive

OPTIONAL? To prevent the browser from keeping HTTP sessions open
over existing circuits the following network settings should be
applied. This will ensure that new circuits, such as requested via
NEWNYM, will service subsequent HTTP requests.

2.7.3 Mounting of filesystems stored on removable devices

Some attacks recently put under the spotlights exploit vulnerabilities
in the desktop software stack that triggers automatic mounting,
display and files preview of filesystems stored on removable devices.

This specification must warn about such matters.

2.7.4 Miscellaneous

FireWire is known to allow read access to the system memory, at
least when such devices are allowed to use DMA (Linux: options
ohci1394 phys_dma=0 helps mitigating that).

IrDA and other network links might allow attacks.

3 Implementation

Tails is an implementation of the PELD specification above. It is
licensed under the GNU GPL version 3 or (at your option) any later
version.

Critical parts of the configuration are based on the ones from
well-known and trusted sources, namely Tails ancestor
Incognito
and the Tor BrowserBundle.
This is for example the case for the firewall and Tor configurations.

NOTICE: this distribution is provided as-is with no warranty of
fitness for a particular purpose, including total anonymity. Anonymity
depends not only on the software but also on the user understanding
the risks involved and how to manage those risks.

3.1 Download

See the installation section on Tails's website
for download information. Published Tails images integrity can be
checked using OpenPGP detached signatures made with a key that is well
linked to the web-of-trust.

The sources are stored in a bunch of Git
repositories. The git page on the Tails website provides all
needed information to access these repositories.

The latest version of this document can be found on the Tails
website: contribute/design.

3.2 Software

Tails ships the following software. This list is not complete, but
only contains packages deemed as important for whatever reason. The
full packages list can be found in the BitTorrent files download
directory (look for files with the .packages
extension).

3.2.1 Core software

Tor: anonymizing overlay network for
TCP. Our intention is to always use the latest stable version.

Being based in Debian, Tails benefits from its great package
management tools, facilitating its build and the inclusion of new
software. Sadly compile time options that would enhance Tails
security (-fPIE, -fPIC, -fstack-protector etc.) are not widely
used in Debian yet. Thus having them included in Tails would require
to recompile every package with the right compile-time options. This
would badly impact the development and build efforts required to
release Tails. As an alternative, efforts have been
started
to push usage of such hardening features in Debian.

A lot of security features have been implemented upstream at the
kernel level (ASLR, removal of /dev/kmem, /dev/mem protections,
various stack and heap hardening features, /proc or /sys not leaking
sensitive information, etc.), most of them being slowly integrated
into Debian. This is the reason why the Tails kernel has no more special
kernel security feature than the stock Debian kernel.

3.2.2 Other applications

3.3 Internationalization

Tails ships, as is, localization files provided by the installed
Debian packages. All available Tor Browser localization packages
are installed. Spell checking software and data is installed for the
set of best supported languages; it is usable at least is Tor Browser,
LibreOffice and gedit.

3.3.1 Input methods

Tails ships with IBus and a few engines (Anthy for Japanese, Pinyin
and Bopomofo for Chinese, and Hangul for Korean).

A login script prepares and configures IBus. When a Japanese,
Chinese or Korean locale is selected, this login script selects
the right default input method. GNOME starts the IBus daemon itself.

Still, since one may want to work on documents written in
Chinese, Japanese or Korean even when selecting English as their
preferred language, IBus is also started in other locales, with all
supported input engines pre-loaded.

IBus' environment variables are always exported on login to make this work.

3.4 Notification of security issues and new Tails releases

Tails ships a script that checks if there are security issues that are
not fixed by any Tails release (and thus, affect the currently running
Tails regardless of its version). A desktop notification is displayed
for every such issue.

The connections are made to the Tails website through Tor, over HTTPS
with a pinned CA. The only piece of information leaked to the Tails
web server (apart of LWP::UserAgent's specific User-Agent
and HTTP behavior) is the first two chars of the LANG
environment variable.

This script is run after the user has logged-in and Tor is
in known-working state.

3.5 Feedback

A dedicated application called WhisperBack
is also available in every running Tails copy. WhisperBack allows
users to send anonymous or pseudonymous feedback via OpenPGP-encrypted
email. It is configured in Tails to use a Tor hidden service run by
Tails developers as the outgoing SMTP server. WhiperBack only sends
email over a STARTTLS session after carefully verifying the remote
SMTP SSL certificate. Some minimal information about the system is
gathered and sent along with the report; the reporting user can
opt-out of this though. Users can also provide an email address and an
OpenPGP public key in case further discussion is needed to address the
reported issue. WhisperBack's graphical interface fully supports
internationalization and is ready to be translated.

3.6 Configuration

In this section we briefly present the setup of several key software
packages and system settings of Tails with respect to security and
anonymity. There are of course other minor tweaks here and there, but
those are mainly for usability issues and similar.

3.6.1 The Tor™ software

The Tor software is currently configured as a client only (onion
proxy). The client listens for control connections on port 9052 (using
cookie authentication) which is non-standard (see about the "control
port filter" below), as a transparent proxy on port 9040 (only used
for remapped hidden services) and as a DNS server on port 8853.

Only connections from localhost are accepted. It can be argued
that running a Tor server (onion router) would increase one's
anonymity for a number for reasons but we still feel that most users
probably would not want this due to the added consumption of
bandwidth.

If a compromised software had access to the Tor control port,
an attacker who controls it could simply ask Tor the public
IP through the GETINFO address command.
To prevent this, access to the Tor control port is only
granted to the root user, as well as to the
members of the debian-tor group (via the control socket).
A filtering proxy to the control port runs on port 9051 (i.e. the default
Tor ControlPort), so for instance
Torbutton still can perform safe commands like SIGNAL NEWNYM. It
allows defining fine-grained access whitelists of commands (and their
argunents) and events on a per-application basis, which can enforce
rules like "this $user (e.g. amnesia) when running this
$application (e.g. /usr/bin/onionshare) can only run these commands
(ADD_ONION etc.) and listen to these events (e.g. HS_DESC, which is
expected after a successfull use of ADD_ONION)".

We disabled the default warning messages of Tor (WarnPlaintextPorts)
when connecting to ports 110 (POP3) and 143 (IMAP). These ports are used
for both plaintext and StartTLS connections. As more and more email
providers recommend and even enforce StartTLS on these ports, the effect
of these warnings were most of the time counterproductive as people had
to click through needlessly scary security warnings.

3.6.3 DNS

Tor does not support UDP so we cannot simply redirect DNS queries to
the Tor transparent proxy.

Most DNS leaks are avoided by having the system resolver query
the Tor network using the DNSPort configured in
torrc.

There is a concern that any application could attempt to do its own
DNS resolution without using the system resolver; UDP datagrams are
therefore blocked in order to prevent leaks. Another solution may be
to use the Linux network filter to forward outgoing UDP datagrams to
the local DNS proxy.

Tails also forbids DNS queries to RFC1918 addresses; those might
indeed allow the system to learn the local network's public IP
address.

resolv.conf is configured to point to the Tor DNS resolver, and NetworkManager and dhclient are configured
not to manage resolv.conf at all:

The following is the complete list of the applications allowed to use
the clearnet DNS configuration:

the tor process itself, but only if the user requested to
configure Tor's network settings in Tails Greeter; in this case
tor being able to resolve hostnames is convenient (e.g. hostnames
are human-readable, IP addresses not as much) or even necessary
(e.g. for the Meek pluggable transport):

3.6.4 HTTP Proxy

Tails does not include any HTTP proxy anymore.

3.6.5 SOCKS libraries

torsocks and torify are installed. Since Tor-ification is done at a
lower level (in-kernel network filter, Tor-ified DNS), these tools are
actually unnecessary. They are solely included due to dependencies and
configured for completeness.

3.6.6 Network Filter

One serious security issue is that we don't know what software will
attempt to contact the network and whether their proxy settings are
set up to use the Tor SOCKS proxy correctly.
This is solved by blocking all outbound Internet traffic except Tor,
and explicitly configuring all applications to use one of
these.

The default case is to block all outbound network traffic; let us now
document all exceptions and some clarifications to this rule.

Tor user

Tor itself obviously has to connect to the Internet without going
through the Tor network. This is achieved by special-casing
connections originating from the debian-tor Unix user.

Unsafe Browser and the clearnet user

The clearnet user used to run the
Unsafe Browser is granted full network access
(but no loopback access) in order to deal with captive portals.

Local Area Network (LAN)

Tails short description talks of sending through Tor outgoing
connections to the Internet. Indeed: traffic to the local LAN
(RFC1918 addresses) is wide open as well as the loopback traffic
obviously.

LAN DNS queries are forbidden to protect against some attacks.

Local services whitelist

The Tails firewall uses a whitelist which only grants access to each
local service to the users that actually need it. This blocks
potential leaks due to misconfigurations or bugs, and deanonymization
attacks by compromised processes. For specifics, see the firewall
configuration where this is well commented:
config/chroot local-includes/etc/ferm/ferm.conf

Automapped addresses

AutomapHostsOnResolve is enabled in Tor configuration, and
a firewall rule transparently redirects to the Tor transparent proxy
port the connections targeted at the 127.192.0.0/10 virtual mapped
address space.

Only the amnesia user is granted access to the Tor transparent proxy
port, so in practice only this user can use this hostname-to-address
mapping facility.

RELATED packets

As a general rule, the Tails' firewall does not accept RELATED
packets: accepting them enables quite a lot of code in the kernel that
we don't need, so we prefer reducing the attack surface a bit by
blocking them. See the "[Tails-dev] Reducing attack surface of kernel
and tightening firewall/sysctls" thread for details.

However, RELATED ICMP packets to the loopback interface are let
through, in order to smooth user experience whenever a program's local
network connection is blocked, and the TCP stack generates ICMP
packets (e.g. with TYPE=3 CODE=3, i.e. the destination port is
unreachable) to let the program know what is going on early, instead
of letting it wait for a timeout.

3.6.7 MAC address spoofing

3.6.8 Host system swap

Tails takes care not to use any swap filesystem that might exist on
the host machine hard drive. Most of this is done at build time:
the /sbin/swapon binary is replaced by a fake no-op script, and
live-boot's swapon option is not set.

3.6.9 Host system RAM

In order to protect against memory recovery such as cold boot attack,
most of the system RAM is overwritten when Tails is being shutdown or when the
boot medium is physically removed. Also, memory allocated to processes
is erased upon process termination.

The big picture

But memory poisoning only works when memory is actually freed,
and a regular shutdown would not free the memory used by the aufs
read-write branch. So we use the systemd-shutdown ability to return
to the initramfs, to ensure the root filesystem is unmounted.

… so that the copy of systemd-shutdown that runs in the real,
non-initramfs system can switch root into /run/initramfs, and run
another copy of systemd-shutdown that's
included
in the initramfs. That one will unmount all filesystems, run
a custom hook
that helps us automatically test this behavior, and finally perform
the requested poweroff/reboot action.

Triggers

Different kinds of events trigger the memory erasure process. All lead
to run the shutdown process that erases memory.

Automated tests
ensure that the most important parts of memory are erased this way.

Second, the memory erasure process is triggered when the boot medium
is physically removed during runtime (USB boot medium is unplugged or
boot DVD is ejected). This is implemented by a custom udev-watchdog
program monitors the boot medium; it's run by a wrapper, started at
boot time, that brutally invokes the memory erasure process, bypassing
other system shutdown scripts, when this medium happens to be
physically removed.

Limitations

As discussed in
an email thread
with the authors of PAX_MEMORY_SANITIZE, kernel memory poisoning
does not clear all kinds of memory once it's freed:

we enable free poisoning for the buddy allocator and the slub/slab
ones, but there may be other ways the Linux kernel allocates
memory, that are not subject to poisoning;

on shutdown all process memory is freed (and thus erased), but some
kernel memory is not erased on shutdown, and is currently
not erased.

It's not obvious that our previous approaches (see below) did any
better, and this one is much more reliable, so we think this trade-off
is the most sensible one with the resources and skills currently
available for Tails.

Obsolete approaches

The initial implementation of the Tails memory erasure feature
suffered from flaws that were demonstrated by external
audit. In short, it
only erased free memory and let data in the aufs read-write branch in
recoverable state.

Then, in order to erase the biggest possible part of the system memory,
a new implementation, shipped from Tails 0.7 to 2.12, runs in a
fresh environment provided by a newly started Linux kernel. This way,
a given part of the memory either is used by the memory erasure
process itself or it is considered as free and thus erased by this
process; in any case, it is at least overwritten once.

Sadly, this approach suffered from severe usability and reliability
problems (e.g. #12354, #11786).
So it was removed in Tails 3.0.

3.6.10 Host system disks and partitions

Tails takes care not to use any filesystem that might exist on
the host machine hard drive, unless explicitly told to do so by the
user. The Debian Live persistence feature is disabled by passing
nopersistence over the kernel command line to live-boot.

3.6.11 Filesystems stored on removable devices

3.6.11 Secure erasure of files and free disk space

Securely erasing files and free disk space is made easy by integrating
secure-delete tools into the Nautilus file
manager, thanks to Nautilus
Wipe.

3.6.12 Passwords

Two users are intended to be used for logins: amnesia and root.
None have a password by default; the amnesia user is
allowed to gain super user privileges, using sudo, if an
administrator password is set in tails-greeter.

The PELD specification recommends to prevent executable code to be
modifiable, even temporarily; Tails does not implement this
recommendation. Instead, thanks to the super user privileges being
available to the end-user, Tails makes it possible to modify or add
executable code by:

upgrading bundled software: this allows (technical) users to protect
themselves from serious security issues until an updated Tails is
released

installing additional software: this helps achieving the PELD
"Working on sensitive documents" goal by enabling users to perform
tasks that need software not shipped in Tails.

Such modifications happen only in RAM, the user will remove the DVD/USB
when done and there are no services allowing logins from the network.

As a first step Tails has stopped
granting sudo privileges to the amnesia user by default.
Unless an administrator password is set in tails-greeter,
no root access is possible afterwards.

3.6.13 Tor Browser

Tails ships with the Tor Browser, which is based on Mozilla Firefox
and patched by the Tor Project for improved anonymity by reducing
information leaks, decreasing attack surface and similar. The actual
binaries etc. used in Tails are those distributed by the Tor Project,
but the configuration differs slightly, which is described below.

In Tails we diverge from the Tor Browser's one-profile-only design, and
install the Tor Browser in a globally accessible directory used by all
browser profiles (and other XUL applications).

Tails also installs the
uBlock Origin
extension to protect against many tracking possibilities by removing
most ads.

Tails does not install the Tor Launcher extension as part of the
browser. Instead we extract Tor Launcher from the bundled .xpi and
make it available as a stand-alone XUL application for Tor
bridge/proxy configuration.

In Tails we do not use the start-tor-browser script, since it does a
lot of stuff not needed in Tails (error checking mainly) and isn't
flexible since it looks for the browser profile in a specific
place. Our custom script makes use of the global installation and also
makes sure the default profile is used as a basis. Any shared libraries
shipped inside the Tor Browser are also used (via LD_LIBRARY_PATH) since
Debian stable often has too old versions to start the browser.

Whenever the user tries to start the Tor Browser before Tor is
ready, they are informed it won't work, and asked whether to start the
browser anyway:

It should also be noted that the global Tor Browser installation is also used
for the Unsafe Browser, although it is
user-isolated and use a separate profile with very different
configuration.

3.6.14 Thunderbird

Thunderbird, in combination with TorBirdy, sends email through Tor.

Thunderbird itself leaks a lot of data and makes DNS requests, for example by
retrieving mail server configurations from a remote server over an insecure
channel. This is prevented by the TorBirdy extension as well as by custom
patches for Thunderbird in Tails, which we are currently in the process of
upstreaming (#11215).

Thunderbird generates Message-ID headers using the hostname part of
the sender's email address, which does not leak usage of the PELD nor
any user location information.

It also always says EHLO[127.0.0.1] to the SMTP server instead of
disclosing the real IP address and hostname.

Torbirdy disables HTML email and inline attachments
in order to get rid of a whole class of privacy concerns.
Furthermore, when setting up an IMAP account, the drafts folder, instead
of being remote, is set to ~$HOME/.thunderbird/Local Folders.

The original TorBirdy extension disables automatic email configuration
through Thunderbird's email configuration wizard. This wizard is enabled in
Tails. This is possible because our patches allow using only secure protocols
for the domain and ISPDB lookups as well as for the actual mail account
configuration. In detail this means:

we prevent all testing of plaintext protocols when guessing configurations.

we make autoconfiguration skip database lookups if mailnews.auto_config_url
isn't HTTPS.

we make ISP autoconfiguration lookups first try https, then http, but only
if we allow insecure protocols.

we discard any configurations using plaintext protocols.

In addition, even when plaintext protocols are allowed, the patches make
us prefer secure options if available.
This setting can be disabled (opt-out by the user). This also applies to
manual configuration.

3.6.15 Pidgin

Pidgin is configured in Tails to not log anything as well as not to reveal too
much of user activity by disabling reporting of online/away/typing
status. Only IRC and Jabber/XMPP protocols are left available, to
avoid the usage of less well audited plugins. The Off-the-record
plugin is enabled
to help one-to-one conversations being as private and unrecordable as
possible. At boot a language confluxer generates a random looking default
nickname from the 2000 most common U.S. names (according to the U.S. social
security administration in the 1970's), which results in something Englishesque
sounding. The nickname is further made to look like a typical IRC nickname by
prefixing it with ^ or _ with probability 0.05, and changing it to leet speak
with probability 0.05. When answering to CTCP requests, Pidgin does
not leak any information apart from PING and VERSION (Purple IRC),
which is deemed acceptable as there are probably other weirdness in
how the protocol is implemented, that disclose as much.

3.6.16 GnuPG

GnuPG tools (namely: GPG itself and Seahorse) are configured to use
the sks-keyservers pool since it's reliable, well-synchronized with
the other HKP keyservers pools, and reachable over hkps://.

Monkeysphere's hkpms:// support will be used as soon as
possible in place of the hierarchical X.509 certification model.

GnuPG is configured accordingly to the OpenPGP Best
Practices,
e.g. to prefer non-outdated digest algorithms from the
SHA-2 family, to force exclusion of the version string in ASCII armored
output, to avoid automatically locating and retrieving keys, and to
disregard the preferred keyserver assigned to specific keys.

3.6.17 Persistence feature

An opt-in data persistence feature is available in Tails 0.11 and
newer. See persistence for details.

3.6.18 Installation on USB sticks and SD cards

An easy (read: not command-line based) way to install and upgrade
Tails on USB sticks and SD cards is available in Tails 0.11 and newer.
SD cards readers wired via SDIO are supported since Tails 0.21.
See installation for details.

3.6.19 Wireless devices handling

Tails puts the wireless devices in a sensible state at boot time.

At boot time, Tails unblocks Wi-Fi, WWAN and WiMAX radios
and soft-blocks all other kinds of wireless devices (e.g. Bluetooth,
UWB, GPS, FM).

3.6.20 OpenSSH

3.6.21 Incremental upgrades

When a Tails release is out, Tails users are proposed to download and
apply a partial upgrade (that is, only what has changed between two
releases). See incremental upgrades for details.
To start with, this upgrade mechanism may be only available for
point-releases.

The Tails OpenPGP applet allows to symmetrically and asymmetrically
encrypt and decrypt text, and to verify OpenPGP signatures.

3.6.23 DHCP hostname leaks

Tails prevents dhclient from sending the hostname over the network.

We patch NetworkManager to make it never instruct dhclient to send the
hostname in DHCP requests, until GNOME bug #768076 is fixed.

Also, dhclient itself is told not to send the hostname. This is
needed because on Jessie, NetworkManager runs dhclient with the -cf
/var/lib/NetworkManager/dhclient-$UUID-eth0.conf option, and generates that file by
concatenating /etc/dhcp/dhclient.conf with its own settings.

dhclient is told to override any hostname provided by the DHCP
server with amnesia. This is meant to prevent dhclient hooks,
NetworkManager and others from setting the hostname to a value
controlled by the DHCP server.

3.6.24 TCP timestamps

TCP time stamps allow for tracking clock
information with millisecond resolution. This may or may not allow an
attacker to learn information about the system clock at such
a resolution, depending on various issues such as network lag.
This information is available to anyone who monitors the network
somewhere between the attacked Tails system and the Tor entry nodes
being used. It may allow an attacker to find out how long a given
Tails system has been running, and to distinguish several Tails
systems running behind NAT and using the same IP address. It might
also allow to look for clocks that match an expected value to find the
public IP used by a user.

Note that TCP time stamps normally have some usefulness. They are
needed for:

the TCP protection against wrapped sequence numbers; however, to
trigger a wrap, one needs to send roughly 232 packets in one
minute: as said in RFC 1700, "The current recommended default
time to live (TTL) for the Internet Protocol (IP) [45,105] is 64".
So, we don't think this is a practical problem in the context
of Tails.

"Round-Trip Time Measurement", which is only useful when the user
manages to saturate their connection. When using Tails, we believe
that the limiting factor for transmission speed is rarely the
capacity of the user connection.

3.6.25 Application isolation

Tails has some minimal application isolation to
mitigate a bit the consequences of security issues in individual
applications being exploited by attackers.

3.6.26 wget

We wrap wget with torsocks, after unsetting the http_proxy
environment variable and friends, so that it talks directly to the Tor
SOCKS port.

3.6.28 Electrum

We install the Electrum Bitcoin client and the
default configuration tells it to use the default of Tor's
SOCKSPort:s, and sync the necessary parts of the Bitcoin blockchain
(as a lightweight client) from the default server pool using SSL.

There is also a persistence preset for the live user's .electrum
configuration folder, which stores the Bitcoin wallet, application
preferences and the cached Bitcoin blockchain.

slab_nomerge

Disables the merging of slabs of similar sizes. Many times some
obscure slab will be used in a vulnerable way, allowing an attacker to
mess with it more or less arbitrarily. Most slabs are not usable even
when exploited, so this isn't too big of a deal. Unfortunately the
kernel will merge similar slabs to save a tiny bit of space, and if
a vulnerable and useless slab is merged with a safe but useful slab,
an attacker can leverage that aliasing to do far more harm than they
could have otherwise. In effect, this reduces kernel attack surface
area by isolating slabs from each other. The trade-off is a very
slight increase in kernel memory utilization. slabinfo -a can be
used to tell what the memory footprint increase would be on
a given system.

slub_debug=FZP

Enables sanity checks (F), redzoning (Z) and poisoning (P). Sanity checks are
self-evident and come with a modest performance impact, but this is
unlikely to be significant on an average Tails system. The checks are
basic but are still useful both for security and as a debugging
measure. Redzoning adds extra areas around slabs that detect when
a slab is overwritten past its real size, which can help detect
overflows. Its performance impact is negligible.

Poisoning writes an arbitrary value to freed objects, so any
modification or reference to that object after being freed or before
being initialized will be detected and prevented. This prevents many
types of use-after-free vulnerabilities at little performance cost.

An additional note: any time slub_debug= is put in the kernel
command line, slab_nomerge is implied. But having slab_nomerge
explicitely declared can help prevent regressions where disabling of
debugging features is desired but re-enabling of merging is not.

vsyscall=none

Virtual syscalls are the obsolete predecessor of vDSO calls.
Unfortunately, both vsyscall=native and vsyscall=emulate (the
default) have a negative security impact, with the latter a little
less so. Namely, they provide a target for any attacker who has
control of the return instruction pointer, which is increasingly
common these days now that attackers need to resort to ROP and similar
attacks which target a process' control flow. The impact of this is
with reduced compatibility, however only legacy statically compiled
binaries and old versions of glibc used vsyscalls. All software on
modern Tails uses vDSO instead. If for some reason a program does try
to use a vsyscall, the process will crash with a memory access
violation, and won't bring the whole system down.

mce=0

Mostly useful for systems with ECC memory, setting mce to 0 will
cause the kernel to panic on any uncorrectable errors detected by the
machine check exception system. Corrected errors will just be logged.
The default is mce=1, which will SIGBUS on many uncorrected errors.
Unfortunately this means malicious processes which try to exploit
hardware bugginess (such as rowhammer) will be able to try over and
over, suffering only a SIGBUS at failure. Setting mce=0 should have
no impact. Any hardware which regularly triggers a memory-based MCE is
unlikely to even boot, and the default is 1 only for
long-lived servers.

kASLR

Linux kASLR is known as not being particularly strong, but one has to
start somewhere.
See self-protection.txt
for details.

kASLR is enabled by default in the Debian kernel since 4.7~rc7-1~exp1
(CONFIG_RANDOMIZE_BASE and CONFIG_RANDOMIZE_MEMORY) so there is no
need to enable it with a specific kernel parameter.

kernel.kptr_restrict=2

Some off-the-shelf malware exploit kernel addresses exposed via
/proc/kallsyms so by not making these addresses easily available we
increase the cost of such attack some what; now such malware has to
check which kernel Tails is running and then fetch the corresponding
kernel address map from some external source. This is not hard, but
certainly not all malware has such functionality.

vm.mmap_rnd_bits, vm.mmap_rnd_compat_bits

kernel.kexec_load_disabled = 1

kexec is dangerous: it enables replacement of the running kernel.

3.7 Running Tails in virtual machines

3.7.1 Current support

Tails may of course be run in virtual machines. Due to the
popularity of VMWare we include
open-vm-tools (an open-source
alternative to VMware tools) as well as special video drivers
for an improved user experience in that environment. Due to the
closed-source nature of VMWare we try to encourage users of open VMs,
like VirtualBox and
QEMU, by making sure that
these also work. In the case of VirtualBox both video and input
drivers are included, as well as the guest utilities.

3.7.2 Security concerns

Security concerns for all VMs are numerous. Tails therefore tries to
detect whether it is run inside a VM and warns the
user if it is.

3.7.3 Running Tails inside a Windows session

Potential work may make it easier to
run the DVD/USB in a virtual machine inside a Windows session whenever
native boot is impossible or not desirable. This probably will be
implemented by shipping a QEMU or
VirtualBox binary for Microsoft Windows.

3.8 Build process and maintenance

3.8.1 Build tools

The Debian Live is a toolkit to build Live
systems based on Debian, such as Tails. Debian Live is designed to
automate the build process of the target distribution, which eases
Tails development and maintenance. As an added bonus, Debian Live
makes it possible for other people to build custom systems based on
Tails, e.g. to include additional software.

For detailed instructions on how to build and modify Tails, see
the build page and the contribute section on the wiki.

3.8.2 Testing process

An automated build and test environment is useful to avoid
regressions in Tails, especially anonymity and security related
ones. It also makes it easier for developers to work on Tails with
more confidence, and at release time to cut down the time needed for
quality assurance work.

Tails' manual test suite is "run"
against Tails release candidates images before they are officially
published. Automating this test suite is partly
done, and a work
in progress.

3.8.3 Upgrades

Remaining applications, including the base system, will be upgraded
using Debian standard upgrade process, and generally based on the
latest Debian stable release so there are not many problems.

We intend to build and publish point releases (e.g.
0.6.1) in a timely manner when security issues
affect Tails. Such releases are based on the stable Git
branch and can thus also fix important — although not
security-related — bugs.

3.9 Hardware support

Tails generally ships the latest Linux kernel from Debian unstable or Debian
Backports as a compromise between
stability and recent hardware support. Recent Intel and AMD microcode
are included as well.

Binary firmware blobs from the Debian non-free archive are installed
when no good Free Software alternative exists. Our reasoning behind
this choice is:

If Tails does not work out-of-the-box on the computer(s) they have
available, most potential users will simply use something else, that
will:

just work ("thanks" to the inclusion of binary firmware);

be less safe in the vast majority of real-world cases.

Much hardware that does not require proprietary firmware to be
injected into it at runtime is simply embedding such proprietary
blobs, often on read-only memory. Not only this does not provide
much more security than injecting proprietary firmware at runtime,
but it prevents hardware vendors from fixing (potentially
security-relevant) bugs in the firmware once it's been shipped
to users.

3.10 Caveats

Tails currently offers almost no protection against live physical
monitoring, except for hardware keyloggers.

UDP and IPv6 are a problem. The Tor network does not support any of
those yet. Outgoing UDP and IPv6 packets are dropped altogether by
netfilter for this reason.

See the development roadmap for more information about
where Tails is heading to.

3.11 Fingerprint

Tails tries to make it as difficult as possible to distinguish Tails
users from other Tor users.

The Tor Browser used in Tails is configured to match the fingerprint of the Tor Browser
Bundle and the known differences, if any, are listed in the known
issues page.

However the fact that different browser extensions are installed in Tails and in
the Tor Browser surely allows more sophisticated attacks that usual fingerprint
as returned by tools such as https://panopticlick.eff.org/ and
http://ip-check.info/. For example, the fact that uBlock Origin is removing
ads could be analysed.

From the point of view of the local network administrator, Tails is
almost exclusively generating Tor activity and that is probably quite
different from other Tor Browser users. We believe this would be hard to avoid.
Other possible fingerprint issues on the LAN or ISP exist but we believe
they would be harder to detect. See the discussion on fingerprinting in
the Time sync design document and the
fingerprint documentation.