Changes between Version 207 and Version 208 of doc/TorBOX/SecurityAndHardening

Sep 27, 2012, 11:47:40 PM (7 years ago)



  • doc/TorBOX/SecurityAndHardening

    v207 v208  
    1 [[TOC(noheading, depth=0)]]
     1TorBOX has been renamed to Whonix.
    3 [ aos Homepage]
     3This page has been moved. The History of this page might still be interesting.
    5 = Technical Intro =
    6 aos aims to be safer than Tor alone. The main goal is, that no one can find out the users IP and location.
    8 The basic idea is, that all applications are untrustworthy. No application must be able to obtain the users real external IP. aos ensures that applications can only connect through Tor. Direct connections (leaks) must be impossible. This is the only way we know of, that can reliably protect your anonymity from client application vulnerabilities and IP/DNS and [ protocol leaks].^10^
    10 aos consists of two machines, which are connected through an isolated network. One machine acts as the client or "aos-Workstation", the other as a proxy or "aos-Gateway", which will route all of the aos-Workstation's traffic through Tor. This setup can be implemented either through virtualization and/or Physical Isolation (explained below).
    12 The ''aos concept'' is agnostic about everything, the anonymizer, platform, etc. See ''aos Framework'' below.
    14 aos ''example implementation'': Anonymity setup build around '''Tor''', two virtual machines using '''VirtualBox''' and '''Ubuntu GNU/Linux'''. aos can be installed on every computer capable of running [ VirtualBox]. (Supports Windows, OS X, Linux, BSD and Solaris.)
    16 Physical Isolation describes installing aos-Gateway and aos-Workstation on two different pieces of hardware. It is more secure than virtual machines alone, requires more physical space, hardware and electricity costs are higher. Keep in mind that you don't need very powerful dedicated servers or desktops. For more information, see [ aos/BareMetalHints].
    18 See [ SecurityAndHardening] for the threat model and security of aos.
    20 The listed advantages and disadvantages shall give you an overview, what aos is useful for, what aos can do for you, and what not.
    22 == Advantages of aos ==
    23  * All applications, including those, which do not support proxy settings, will automatically be routed through Tor.^1^ Only those dependent on UDP^2^ or IPv6^12^ will still not function. See footnotes for limited workarounds. Services that need to listen on publicly reachable ports (open/forwarded ports) are also not supported. However you may run [ Hidden services] which are reachable via Tor or tor2web ([ be careful]).
    24  * Installation of any software package possible.^11^
    25  * Safe hosting of [ Hidden services] possible. ^7^
    26  * Protection against side channel attacks, no IP or DNS leaks possible^3^ To test for leaks, see [ aos/LeakTests].
    27  * Advantage over Live CD's: Tor's data directory is still available after reboot, due to persistent storage. Tor requires persistent storage to save it's [ Entry Guards].
    28  * Java / JavaScript^9^ / flash / [ Browser Plugins]^4^ / misconfigured applications cannot leak your real external IP. See [ aos security in real world].
    29  * Aos does even protect against root exploits or [ Malware] with root rights, but you really should not test it and read footnote ^1^ ^a^ and follow links.
    30  * Uses only [ Free Software].
    31  * Building aos from source is easy.
    32  * [ Tor]+[ Vidalia]^5^ and [ Tor Browser] are not running inside the same machine. That means that for example an exploit in the browser can't affect the integrity of the Tor process.
    33  * It is possible to use aos setup in conjunction with VPNs, ssh and other proxies. But see [ Warning]. Everything possible, as [ first chain] or [ last chain], or both.
    34  * Loads of [ Optional Configurations] (additional features / Add-Ons) possible.
    35  * Best possible [ Protocol-Leak-Protection and Fingerprinting-Protection].
    37 == Disadvantages of aos ==
    38  * More difficult to set up compared to the regular Tor Browser Bundle.
    39  * Needs virtual machines or spare hardware.
    40  * Updating OS and applications behind the Tor proxy is slow.^6^
    41  * Higher maintenance required.^8^
    42  * Tor Button's New Identity button is not supported with aos, see [ aos/ApplicationWarningsAndNotes#TorBrowser] for a workaround.
    43 ,,
    44 ^1^ See application warnings below[[BR]]
    45 ^2^ ICMP, ping, VOIP calls^13^ over UDP, etc... Limited Workaround 1) [ OnionCat]; Limited Workaround 2) [ Tunneling UDP over Tor] [[BR]]
    46 ^3^ The operating system and applications behind the isolated Tor proxy (gateway) cannot determine the real external IP. Therefore they also cannot leak it as long as the network, gateway server, virtual machine or host system are not compromised as well. See whole Security And Hardening page footnote ^1^ ^a^ and follow links. [[BR]]
    47 ^4^ This is still not recommended as they may decrease anonymity (e.g. flash cookies) and often have security vulnerabilities. Most popular plugins are closed source. See [ Browser Plugins] for more information. [[BR]]
    48 ^5^ [ Vidalia] is optional; [ Arm] is recommend as alternative [[BR]]
    49 ^6^ If using Ubuntu GNU/Linux for the client look into [ Offline updates]. [[BR]]
    50 ^7^ Even if someone hacks your hidden server software (thttpd, apache, etc.), he can not steal your hidden service key. The key is stored on the aos-Gateway. Once you cleaned your aos-Workstation, no one can impersonate your hidden service anymore. [[BR]]
    51 ^8^ You need to maintain three instead of one OS. You need to remember several passwords and update at least three systems. [[BR]]
    52 ^9^ There is no difference compared to using JavaScript directly within the [ Tor Browser Bundle]. Of course JavaScript within TBB inside aos will also not leak your IP. Decide yourself. Browser fingerprinting still applies. For more information see [ Web-browser]! [[BR]]
    53 ^10^ aos protects against IP and DNS leaks. Other possible leaks (such as username; time zone; etc.) and how to mitigate them is [ documented]. Additionally aos [ mitigates many possible fingerprinting attacks] by using common, non-identifying defaults. (username set to user; timezone set to UTC; etc.) [[BR]]
    54 ^11^ Must be able to run on Ubuntu GNU/Linux. See [ Software installation on aos's aos-Workstation] for details. [[BR]]
    55 ^12^ IPv6 not yet supported by Tor. ([ OnionCat] is a limited workaround.) [[BR]]
    56 ^13^ Skype over TCP does work, but it's not recommend, because it's proprietary, closed source and there is no control over the encryption keys. Skype authority can compromise you out any moment. A secure encryption/authentication works different. GPG or OTR for example are secure. [[BR]]
    57 ,,
    59 == Status of aos ==
    60 aos 0.2.1 is currently alpha quality software. 0.1.3 is beta quality but is now considered outdated and lacking important features.
    62 The basic functionality is ready. You can use aos to browse the web and [ host hidden services], use email, IRC, ssh, etc. Development is still ongoing and more features are being added to aos. If you want join the development process or want to see what issues are still open visit [ aos/Dev].
    64 == Comparison of aos, Tails and TBB ==
    65 Quick comparison of aos and Tails key virtues. If ever anything in this table is incorrect/outdated feel free to contact aos developers, we'll correct as fast as possible.
    67 === General ===
    68 || || aos || Tails || Tor Browser Bundle ||
    69 || Focus on anonymity, privacy and security || Yes || Yes || Yes
    70 || Type || general purpose operating system || LiveCD/DVD/USB || portable browser
    71 || Supported hardware || any ^9^ || x86 compatible and/or and Virtual Machines || Windows, Linux, Mac and Virtual Machines
    72 || Based on || Tor, Ubuntu ^3^, Virtual Box || Tor, Debian || Tor, Firefox
    73 || Live CD || No || Yes || No
    74 || Live USB || No || Yes || No
    75 || USB bootable || Yes ^6^ || Yes || Yes ^6^
    76 || Requires Virtual Box || Yes ^4^ || No || No
    77 || System requirements || higher || lower || lowest
    78 || Can run in VM || Yes || Yes || Yes
    79 || Persistence || Full || Optional for Live USB || Yes ^11^
    80 || Number of developers || one with lots of anonymous contributions || multiple || multiple
    81 || Maturity || project since 2012 || established, respected project for many years || established, respected project for many years
    82 || Open Source || Yes || Yes || Yes
    83 || Anonymous developers || Yes || Yes || No
    85 === Security ===
    86 || || aos || Tails || Tor Browser Bundle
    87 || Amnesic || Optional Feature ^7^ || Yes || No ^12^
    88 || Protection against root exploits  || Yes ^1^ || No ^2^ || No ^2^
    89 || IP/DNS protocol leak protection || Full ^1^ || Depends ^5^ || Depends ^5^
    90 || Takes advantage of Entry Guards || Yes || No || Yes
    91 || Operating System Updates || persist once updated || are lost after reboot || persist once updated
    92 || Hides hardware serials || Yes || No || No
    93 || Includes Tor Browser || Yes || No || Yes
    94 || Stream isolation to prevent identity correlation through circuit sharing || Yes || No, planed. ^13^ || See ^14^ ^15^
    95 || Stream isolates Tor Browser || No ^14^ || No ^14^ || No ^14^
    96 || Encryption || Should be applied on host. || Yes, for persistent USB. || Should be applied on host.
    97 || Cold Boot Attack Protection ^8^ || No, planed. || Yes || No
    98 || Secure Distribiuted Network Time Synchronization || No, will be introduced in aos 0.3.0 and above ^10^ || Yes || No
    100 === Attacks ===
    101 There is a comparison of TBB, Tails, aos Standard/Download version (host+VM+VM) and aos with Physical Isolatoin under [ Attack on aos].
    103 === Conclusion ===
    104 Conclusion: different thread model, different implementation, different use cases, although some overlap.
    106 === Footnotes ===
    107 ,, ^1^ ^a^ In case aos-Workstation gets rooted, the adversary can not find out the users real IP/location. This is because aos-Workstation can only connect through the aos-Gateway. How difficult is it to compromise aos? See the whole Security and Hardening site. More skill is required. See [ Attack on aos]. [[BR]]
    108 ^2^ In case Tails gets rooted, the adversary can simply run ''ifconfig'' and see the user's IP. Or he could tamper with firewall rules and bypass them. [[BR]]
    109 ^3^ We may switch in near future to Debian. In long term we are also agnostic about any other secure distributions. [[BR]]
    110 ^4^ Default downloads are for Virtual Box. (Subject for change in future.) You can build your own images for other virtualizers. You can also install on bare metal but we don't recommend that, because using a virtualizer is the only way to hide hardware serials. [[BR]]
    111 ^5^ See first example of [ aos security in real world]. When applications in Tails are configured wrong, due to a bug in Tails or the application, IP can leak. [[BR]]
    112 ^6^ You can install your host operating system on USB. [[BR]]
    113 ^7^ See [ Recommendation to use multiple VM Snapshots]. [[BR]]
    114 ^8^ See [ Cold boot attack]. [[BR]]
    115 ^9^ Aos example implementation still requires PAE (may likely change in future). Intel VT-x or AMD-V will greatly speed up Virtual Machines. Aos framework workstation: self made builds can run on any real or virtual hardware. Aos framework gateway: anonymizer (Tor) must support that platform. [[BR]]
    116 ^10^ Aos 0.3.0 will soon be released and is already available as source code. [[BR]]
    117 ^11^ You can download files and keep them, save bookmarks and passwords depending on your settings. [[BR]]
    118 ^12^ Although it does not try to store to disk, swap can still leak. [[BR]]
    119 ^13^ [ Tails separate Tor streams] [[BR]]
    120 ^14^ [ Tor Browser should set SOCKS username for a request based on referer] [[BR]]
    121 ^15^ Tor Browser comes with it's own Tor instance. It's just a browser, not a live system or operating system. [[BR]]
    123 == Comparison of different aos variants ==
    124 || Name|| Nr. of systems || Comments||
    125 || OneVM || host+VM=2 || Protection: better security than Tor Browser Bundle, Tor Live CDs ||
    126 || Standard / Download version || host+VM+VM=3 || Same as OneVM; redistributable and easy to deploy; larger maintenance overhead ||
    127 || Physical Isolation with bare metal Gateway || host+VM+host=3 || Protection: stronger than standard ||
    128 || Physical Isolation with virtualized Gateway || host+VM+host+VM=4 || Easier to deploy; higher attack surface; maintenance overhead ||
    129 || Physical Isolation without any virtualization || host+host=2 || Basically same as standard Physical Isolation;^1^; no protection against hardware fingerprinting^2^||
    131 Two options for aos-Gateway's operating system. Ubuntu Server 12.04 GNU/Linux (default, recommand). There is [ Hardened Gentoo based aos-Gateway]. (experts only!) [[BR]]
    133 Potential future variant: Live CD [[BR]]
    134 ,,^1^ Smaller attack surface because not using Virtual Machines. [[BR]]
    135 ,,^2^ therefore unsupported! [[BR]]
    137 Virtual machines can provide following security related features:
    138  * Network isolation (connections can easily be forced through tor)
    139  * Hardware isolation (hide unique hardware serials)
    140  * Roll back feature
    141  * Cheap and simple multi-level security through running multiple clones/VMs
    143 Live CDs offer:
    144  * Non-persistence in case of software compromises
    145  * Anti-Forensics and deniability (no encryption keys to disclose, if it's powered down and RAM is wiped/faded everything is "gone")
    146  * But: difficult to roll out security updates
    148 == aos Framework ==
    149 The ''aos concept'' is agnostic about everything. With some development effort you can replace any component. The aos developers would like to support each and any use case, but due to limited amount of developers this is impossible and we focus on the ''aos example implementation''.
    151 The Tor network is aos's official and best supported anonymizing network. aos can also potentially and optionally use [ other anonymizing networks] (Such as JonDo, i2p, freenet, RetroShare), either in addition (tunneled through Tor) or as a replacement for Tor. See the article for more information.
    153 You can also avoid using virtualization by using Physical Isolation, although that is not recommend, see Comparison of different aos variants fore more information.
    155 It's possible to use other virtualization platforms (e.g. [ VMware], KVM, XEN, Qemu, Bochs, etc.) See the article for more information.
    157 Other operating systems (e.g. [ Windows; *nix; BSD]) can potentially be used as host and/or guest operating system. See the article for more information.
    159 == aos security in real world ==
    160 Some real world examples that are '''protected by using aos''':
    162  * [ Tails: Icedove (Thunderbird) leaks the real IP address] - aos didn't exist at the time that bug existed. Such kinds of leaks are not possible with aos, since the aos-Workstation is unaware of it's external IP.
    163  * [ pidgin leaks the real IP] - aos didn't exist at the time that bug existed. Such kinds of leaks are not possible with aos, since the aos-Workstation is unaware of it's external IP.
    164  * [ Tor Browser Bundle: Firefox security bug (proxy-bypass)] - This vulnerability was circumvented by aos. Any proxy bypass may have only emitted traffic through Tor's TranPort. All that could have been leaked is the IP address of another Tor exit node, which is harmless.
    166 At first glance this site may create the impression that aos is completely insecure and everything is a lost cause. We are upfront with things we could do better and we are still working on and try to consider all possibilities and document all thinkable and future threats. You must judge for your own which risks are acceptable for your use cases.
    168 == Security Overview ==
    169 This page intends to document security philosophy, design, goals and current shortcomings of aos.
    171 This chapter is only a short introduction. Please read the full page.
    173 aos follows the principle of security by isolation. We know that making our currently used systems secure is a lost cause. They are too complex and too large to be trustworthy and verifiably free of any bugs. aos can't solve this but it tries to minimize attack surfaces and limit what danger exploitable bugs in more exposed parts can do, one primary danger specific to Tor is the danger of exposing the public IP address of a system. aos isolates client applications inside the aos-Workstation from discovering the external IP address. Specifically, aos is designed to prevent direct detection of the IP (not more!) even if an adversary has unrestricted access to the aos-Workstation.
    175 Once there is a vulnerability found in Tor (ex: exploiting Tor's ports) or a successful attack against Tor, aos fails.
    177 Same goes for iptables. Aos is a setup based on Linux, iptables, Tor, etc. If any of the underlying projects has a vulnerability, which we can not rule out, of course, aos will fail as well.
    179 There are [ three ways to torify]. Read the link for a comparison of the security.
    181 aos's aos-Workstation has no access to the internet without using Tor. You can look into our setup. It's all Open Source and well documented. IP-forwarding is disabled. The firewall fails "closed": when Tor is disabled, loses connection, or the aos-Gateway crashes, no network connections are possible. Iptables redirects any traffic from aos-Workstation to Tor's ports. Local network connections are dropped. No leaks are possible, assuming the TCB is trustworthy.
    183 aos uses multiple security layers. [[BR]]
    184 1. Applications are configured correctly using latest suggestions (correct application and proxy settings, stream isolation). [[BR]]
    185 2. Firewall rules are enforced and prevent accessing the internet directly, thus leaks are prevented in case some application leaks. [[BR]]
    186 3. Optionally physical isolation is provided. [[BR]]
    187 4. aos's Protocol Leak and Fingerprinting Protection [[BR]]
    188 5. ...
    190 aos was [ tested for leaks] and all went negative. Additionally, Skype, which is known for it's ability to punch through firewalls, was not able to establish non-torified connections. Also Bittorrent doesn't leak the IP (there is an online bittorrent leak tester). which of course should never be used through Tor (because it chokes Tor nodes)t but for leak testing it was welcome. Right now we don't know of any leak tests which leaks the real IP.
    192 [ Protocol leaks], like this the ones listed on [ aos security in real world], Skype, Flash or Bittorrent are impossible. This already justifies to use a "no non-Tor connections possible" approach.
    194 When you go ahead now, and ask in a cracker forum, they probable won't spread a simple method to get the real IP of aos-Workstation. On the other hand, if you run an intelligence service and have 100.000 $ left over, you can announce something like "find a new exploit in Tor's SocksPort and get 100.000 $". Qualified people start looking into it and might find something.
    196 == Hidden Services ==
    197 === Introduction ===
    198 Be sure to read and understand [ Tor: Hidden Service Protocol] (general information) and [ Configuring Hidden Services for Tor] (standard setup, no isolated proxy) first. Note that hidden services are always only reachable using Tor or tunnel services, such as tor2web, ([ be careful]).
    200 You do not need [ SSL], because [ connections to Tor hidden services are end-to-end encrypted by default] (to be exact, only tor-to-tor, see [ Notes about End-to-end security of Hidden Services]). This is handy, as you do not have to bother with self singed certificates or certificate authorities.
    202 An adversary can see whether the service (and presumably Tor) is up and running or not.
    204 === aos specific ===
    205 You can provide any server service, which relies on TCP. Beware of application level leaks, see [ aos's Protocol-Leak-Protection and Fingerprinting-Protection].
    207 Even if someone hacks your hidden server software (thttpd, apache, etc.), the attacker can not steal your hidden service key or bypass Tor, see [ Attack on aos]. The key is stored on the aos-Gateway. Once you cleaned your aos-Workstation, no one can impersonate your hidden service anymore.
    209 = About Computer (In)Security =
    210 A secure and trustworthy computer is a computer that only does what _you_ (think you) tell it to.
    212 Computers are insecure and not trustworthy and there is nothing we can do about that. Computers are "universal machines" (see Von Neumann, Turing). They can be instructed to do anything they can do according to the laws of physic. It's important to understand that a computer can't discern between "good" and "bad" instructions, bits are bits. There are two general problems:
    214 1) There are a lot of people who can instruct a given machine to do something (anything!), we need to trust them all, or verify everything, which is impossible
    216 If you read or write all instructions (kernel, software, firmware) yourself, study the hardware design (so you understand what an instruction actually does) and compare that with the actual hardware and then make sure you are the only one who can access the machine and give it new instructions, you need to trust that other people only give the machine instructions to do things that you want it to do. You can tell it to accept other, external untrusted instructions in a restricted, controlled fashion (like "render that html but other wise don't touch my system") but this is next to impossible to do reliably because of point 2). Otherwise you could never connect that machine to a network or transfer any input from another system to it ("input" and "instructions" has to be understood in a very broad sense, it's not just about executable code, it can as well be media files or hardware devices that are being attached).
    218 The "Trusted Computing Base" (TCB) refers to all instructions and hardware used to restrict a "universal machine" from accepting and acting on (other) arbitrary instructions. It is used to set a certain security policy to enforce that a computer only does what these trusted instructions allow it to. "Trusted" simply means that we have to trust it, not that it's wise to trust it. The TCB tries to restrict what instructions can do but it consists of instructions itself. It can't restrict or police itself. Any flaw whatsoever in the TCB directly results in a compromise of the security of the system.
    220 2) The machines themselves and the instructions are incredibly complex
    222 Even in an ideal world with mathematically verified hardware and software we may think we are giving instructions to do A while in reality the instructions tell it to do B, or also B. Machines can not make "mistakes" but they certainly can do unexpected things... 
    224 We can't give machines instructions in our language (programming language) it needs to be in machine code. The translation is so complex that we need another machine to do that for us, and to create that machine another was used and so on. This expands our chain of trust to basically all machines and humans involved to the first compiler created by an assembler which in turn was created by hand-written machine code.
    226 Hardware is fallible, hardware failure can result in entirely unpredictable results. Cosmic rays "flipping a bit" or just bad memory and extreme temperatures? Look up "Bit-squatting" for an example. Software depends on the hardware to function perfectly, what happens if the most basic assumptions are betrayed?
    228 Another example for complexity, side channel attacks: they are very difficult to protect against and poorly understood by most software developers. E.g. through power or CPU load analysis otherwise isolated parts outside the TCB can influence or eavesdrop on privileged encryption. In other words, determining what is part of the TCB and what is definitely not, is a very hard problem.
    230 If that wasn't enough we also have the problem that circuit layouts, microcode and firmware of most vendors is proprietary. Part because of competition concerns, part because they are afraid of patents... In any case, this makes verification even more difficult that it already is. Further "hardware" (which includes firmware, i.e. software) is becoming more and more capable (=complex and dangerous). Features like Trusted Computing when used to prevent ring 0 access from the user and owner of the computer, EFI that has Internet connectivity and can update itself or Intel RMM which can grant remote access that is invisible to the user and OS combined with a less than perfect track record (e.g. see Intel related research by Invisible Things Lab) doesn't exactly spell trustworthy and 100% dependable.
    232 Conclusion:
    233 The TCB can never really be trustworthy. The source code of every currently usable OS kernel alone is too complex and large to completely audit and make error free, not just for a single human but even for large groups like the "Linux community". But let's assume we solve that (e.g. through using microkernels and formal verification): How do you make sure compiled binaries are actually doing what the source intended? Or, how can you verify that complex hardware and integrated circuits are actually built according to their intended design? For all the verification and auditing processes we are dependent on other complex computer systems that would have to be trusted unconditionally. Bootstrapping trust is a chicken and egg problem. We would have to be able to verify systems with just looking at them with our bare eyes and hands or build/verify all systems necessary to bootstrap a modern compiler and hardware development platform. This may have been possible for the first "computers" in the first half of the last century but not anymore.
    235 Since there's nothing we can do about that, what else can we do then?
    237 We need to design our systems in a way that makes it no longer necessary to trust them 100%. We only need to trust that it's good enough and that it's astronomically unlikely that multiple diverse systems are untrustworthy in the same way.
    239 If you don't want a computer to be able to tell anyone your location or identity better make sure the computer doesn't know either... The aos security design in some ways mimics the security design of the Tor network itself: Don't trust any single entity to be trustworthy. We only rely on the fact that it's unlikely that all entities (nodes, computers) are compromised and colluding. To be precise, that's a goal that isn't achieved yet with aos alone, see [ aos²]. One could also say that the actual TCB of such a "system" (actually multiple systems) becomes the design, arrangement and usage policy which is very well possible for every user to comprehend and verify.
    241 This could be compared to the "Air Gap" used on most high security networks. They assume that the TCBs are not trustworthy and work around that using a simple and easily verifiable policy that basically eliminates the complete attack surface or hardware and software bugs and even protects against most backdoors (for example, a subverted PRNG could still result in weak crypto being exported from the trusted network where it can be recorded and "cracked" by an adversary. A strong pyhiscal isolation based system could then encrypt data twice on different systems using different PRNG implementations to protect against such attacks.)
    243 Physical Isolation in the sense of aos is not a new idea, see [ Verifiable Computer Security and Hardware: Issues by William D. Young. September 1991 (PDF!)] page 18 for a summary. It seems like the idea was rediscovered by aos (independently, and we came up with the same term), to our knowledge aos is currently the only project following this approach in a defined way.
    246 = Our Threat Model =
    247 == The Threats ==
    248 First let's quickly consider all the possible threats we could face. We can put threats against computer systems into five categories:
    250  * 1) Non-technical/non-computer-based and legal attacks
    251 E.g. "rubber hose cryptanalysis", mandatory key disclosure, subpoena, real police work/espionage (done by real humans, not bots), bugs, surveillance cameras...
    252  * 2) Hardware attacks through physical access.
    253 RAM and Hard disk Forensics, keylogger, TEMPEST, Evil Maid attack...
    254  * 3) Backdoors
    255 Intentional weaknesses or additional hidden "functionality" put into your system by a manufacturer, vendor or distributor (hardware or software) allowing remote access^1^ Can be put in anywhere between design/source code, manufacturing/compilation or distribution.
    256  * 4) Vulnerabilities
    257 Coding or hardware design errors that can be exploited to gain remote access^1^ Vulnerabilities and Backdoors in practice can look exactly the same, only the way they are created differ.
    258  * 5) Design flaws
    259 Even in a backdoors-free, error-free system with perfect physical and legal protection (no such thing in reality) perfect security may still be impossible. This is especially true for anonymity systems. While with cryptography a perfect design exists (the one time pad) anonymity isn't binary. You are not either anonymous or not, you only have some non-zero but not-perfect degree of anonymity. Your anonymity depends on hiding amongst others. Anonymity networks require trust and a large and diverse userbase. A perfect security system wouldn't require trusting other parties or depending on such extraneous factors. Any design of a complex (but still usable) system (all computer systems are complex) needs to make tradeoffs. That's why pretty much everything uses non-perfect cryptography instead of the one-time-pad...
    261 #5928 seems to only be about learning the IP address which a Tor client connects to the Internet through. It doesn't mention other information leaks.
    263 ,,^1^ Used in the broadest sense, can be classic remote code execution, privilege escalation, DoS... Essentially they all allow remote parties to send your system instructions that diverge from the allowed security policy
    265 == Attacker capabilities ==
    266  * Legal/Non-technical "attacks" and physical access is expensive
    267 Anything that requires real humans to do work instead of letting computers and algorithms do it is prohibitively expensive against more than a small target group.
    269  * Backdoors (hardware or software) are expensive
    270 It is hard to make one and it's risky. The more you use it the more likely it is it will be caught and closed. Adversaries are not going to waste it on anything but high profile targets. However, well hidden passive "backdoors" are of a concern, they can practically be impossible to detect and remain functional for years. Imagine a backdoor in a compiler affecting the PRNG. The cost for such backdoor is high (for this example an attacker need patience, non-trivial coding and social engineering as well as some crypto skills) but the "ROI" would be great too...
    272  * Software attacks are cheap
    273 A good 0day can still cost a lot and isn't useful for very long once you start using it. But new vulnerabilities are found all the time, new exploits can be written. Compared to physical access and backdoors it is cheap. It can be fully automated against a large target set.[[BR]]
    274 If you are wondering how realistic or important the client application 0day threat is consider pwn2own 2012. A semi-legal but most certainly immoral and reckless company demonstrated how they can exploit every web browser circumventing all state of the art security features (MAC, Sandbox, ASRL, NX, etc). This is not too surprising, we already established how big code bases always have bugs and a subset of those bugs will always be exploitable. The noteworthy news here is that this company doesn't report their findings to the developers, they sell it to governments (and/or the highest bidder) as offensive "cyber weapons" (naturally not their term).[[BR]]
    275 It's only likely that also Tor vulnerabilities are sold behind closed doors. You should act accordingly and never rely on Tor alone if your threat model demands "reasonably strong anonymity" even from not-nearly-global but well funded adversaries.
    277  * Crypto-attacks are enormously expensive
    278 If you know how to break currently used crypto you will try keep this a secret at all costs. Most crypto attacks will most likely require enormous computing power.
    280  * Attacking design flaws: it depends...
    281 The costs can vary greatly but in every case, once you attack a design flaw and it becomes publicly known the target will fix the flaw and will become harder to attack in the future. This can result in an arms race and often neither party wants to go that way. A grave problem for the defender side can be that some systems are so widely used that it becomes almost impossible to mitigate away to a more secure design. The best example for that is the certificate authority system. It's design is flawed on so many levels yet it's relied upon, often solely for all authentication and confidentiality, to this day by pretty much everyone who's ever used a computer. Similarly, a lack of crypto and hash agility in many applications results in a dependence on weak and broken algorithms, not because we don't know any better but because backwards compatibility and some bad apples spoil it for everyone. There's certainly a threshold, were, if an attacker plays it slow and carefully, he can stay just below the radar for a long time and let everyone believe that it's not "that bad yet". For example, a [ collision attack] against SHA-1 (which would affect software updates, version control systems as well as Tor, GPG, TLS and pretty much everything that uses public key crypto) is known to be "within the reach of a powerful adversary" since 2005, with Moore's Law and Schneier/NSA's Law ("Attacks always get better; they never get worse") in play the range of potential adversaries only got larger. SHA-1 will probably be relied on pretty universally until someone publicly demonstrates a collision. Not because we don't know any better, but because to cost of switching are so high.
    283 ==  Our Goals ==
    284  * Hiding our Location and Identity when transmitting information
    285  * Confidentiality, Integrity, Authenticity and Availability of transmitted data
    287 ==  Our Attack Surface ==
    288 Basically any part used by us to achieve our goals can be attacked:
    290  * We need some physical security and privacy. It's obvious that anonymity and confidentiality is difficult or impossible to achieve otherwise.
    291  * Tor, the code, the design, the whole network (see "aos's Tor Setup" below for more)
    292 We also can't look at Tor as an isolated piece of software, we need to consider its whole TCB because if any part of a TCB can be subverted the Tor process can be subverted. The attack surface in case of backdoors is the full TCB, in case of vulnerabilities "only" the network facing parts of the TCB.
    293   * The aos-Gateway Hardware
    294   * GNU/Linux/Ubuntu: kernel, essential userland, apt-get and all software update packages provided by the OS distributor/vendor
    295   * Tor itself
    296   * The build system (gcc...)
    297 Using Virtualization (instead of "PhyIso") increases the TCB significantly. In addition to the above:
    298   * Host Kernel
    299   * Host applications
    300   * Host software updater
    301   * Virtualization software
    302  * We rely that the software we use doesn't more than absolutely necessary reduce our anonymity set through protocol leaks, identity correlation and fingerprinting. For that we also have to rely on the aos-Workstation and the TCB of the applications we use. (for more see
    303 "aos's Protocol-Leak-Protection and Fingerprinting-Protection" below).
    305 For Confidentiality, Integrity and Authenticity we (we all, not just aos...) are still way too heavily dependent on TLS (Transport Layer Security, the "s" in https). Further we depend on:
    306  * The complete Host (Hardware and Software)
    307  * all software in aos-Workstation
    308  * TLS/PKI infrastructure
    309  * In case of hidden services: The full location/identity TCB.
    310  * The "other end", the security of whoever you are communicating with, unless it's symmetric key crypto and you got the only key.
    312 To achieve Availability of information we depend on:
    313  * the upstream internet provider, uptime and connectivity
    314  * Tor network resilience against DoS
    315  * resilience of webservers you connect to against DoS
    316  * Your own system's resilience against DoS
    318 == Applying the threat model to aos ==
    319 First of all, you don't want to end up in the "high profile target" list of any of your resourceful adversaries. Because if you do neither aos nor any other computer based system can protect you.
    321 aos is mostly a software project. There isn't a lot we can do on the hardware and physical side of things. Hardware security would be a much smaller problem if we weren't using monolithic systems where dozens of parts have full system access through DRM (or indirectly though hardware drivers that all run in kernel space). Have a look at QubesOS for state of the art hardware deprivileging. It requires latest gen hardware and software support still needs to catch up, therefore this isn't available in aos yet.
    323 We assume the hardware is trustworthy, we assume the physical location is not compromised. To protect against forensic analysis we recommend to use full disk encryption, wipe the RAM on shutdown. We recommend to use "clean" computers made of parts manufactured by reputable companies and to pay in cash so as to not have hardware IDs leak our identity. Further some pointers:
    324  * DMA is bad, IOMMU is good, avoid attaching untrusted (or any for that matter) devices on Firewire and PCI* interfaces.
    325  * Use open source hardware or at least open source friendly that makes specifications public. Open source means that multiple companies can implement the hardware, the Linus law of "many eyeballs and all bugs are shallow" applies, backdoors are harder to hide.
    326  * simple is beautiful, complexity is the enemy Nr.1 of security. aos-Gateway can run on very simple hardware like the Raspberry Pi.
    328 Crypto is even worse, the only thing we can do is to use [ cascades] of different cipher and hash families. This is slightly more complicated than it sounds and we don't know of any software that does it right.
    330 As established above in "Attacker capabilities" the main attack vector we need to concern (and we can actually do something about) is software attacks.
    332 To protect against software backdoors and vulnerabilities:
    333  * the source needs to be audited, preferably by yourself and many others and should ideally be bug free.
    334 Popular open source projects are your best bet. aos is fully open source, anyone can audit and patch. aos comes with a software updater which allows rapid deployment of security patches.
    335  * if you rely on others (you do), you need to make sure that you get the same code as everyone else
    336 Hash sums + signatures, the more public they are, the better. If completely transparent signing is used (as common in proprietary systems) it's much more difficult to determine that you get the same files as everybody else. By default signing is only concerned with making sure that you get code by someone with access to the key. This protects against 3rd parties but not insiders.
    337 Checksums and signatures of aos and updates are publicly available.
    338  * the code you use should have a good track record, know issues must be corrected immediately
    339 Code that doesn't get checked but has zero known problems is worse than code that has hundreds of known and patched security issues but is constantly being reviewed and worked on. However, a trustworthy code should have very few if any security issues despite having been audited thoroughly. After all, projects that constantly need security patches are constantly insecure. But it's not really about numbers, check the severity of the bugs. Linux needs many security patches but fatal flaws that would affect aos are few and far between (i.e. remote code execution with root privileges). Fatal flaws in user facing applications (like browsers, pdf readers, media players, IRC) are frequent and therefore such software is not be part of the TCB (see below).
    340  * checking the source is not enough, you need trustworthy binaries
    341 analyzing binaries is a lot more difficult than analyzing source code. If you rely on source code auditing you absolutely require a trustworthy compiler (and a complete trusted system to run it on) and use [ DCC]. Similarly you already need a trusted system to check signature and hashes. This is the bootstrapping chicken and egg problem we mentioned earlier. Generally, to address it you need to use at least two different diverse systems that are completely independent (includes their parent build system and compiler) and set up the system in such a way that both would have to be compromised by the same adversary in a compatible way in order to result in a fatal security breach.
    343 If the code base is huge and complex code auditing isn't a realistic strategy, therefore we need to reducing complexity and attack surface by:
    344  * making the TCB small
    345 and
    346  * using privilege separation:
    347 The TCB for identity/anonymity is as small as it gets on a monolithic general purpose OS. It could be smaller (e.g. a custom kernel, busybox, uclibc instead of libc and gnu-utils) but that comes at the cost of maintainability, security updates and ease of use. (and still leaves us with a comparably huge monolithic kernel and a gigantic gcc infrastructure). [[BR]]
    348 Linux/Xorg (with DAC or even MAC) isn't very good with privilege separation (e.g. no trusted path). The strongest privilege separation is offered by using multiple physical computers, that's what we recommend ([ Physical Isolation ("bare metal") aos-Gateway], multiple aos-Workstations). The more practical but less secure alternative is virtualization. For details about privilege separation between IRC/Browser/Clients and Tor see below: [ aos Tor Setup]. [[BR]]
    349 We've thought a lot about making aos yet more secure but with the (free and open source) tools available today it doesn't seem possible. What we'd need is a isolation kernel that would offer some strong guarantees of isolation between the different subsystems and ideally would be verified so you don't have to worry about sophisticated backdoors (apart from the compiler, see "Trusting trust"/chicken and egg), software vulnerabilities and even some hardware backdoors and vulnerabilities (through IOMMU and microkernel design one can put hardware and firmware components, apart from the CPU, out of the TCB).[[BR]]
    350 For Fingerprint/Protocol leaks and the [ CIA Triad] we are depending on the aos-Workstation TCB. This is a hopelessly large TCB/attack surface. For this reason we use yet another approach which can be called "security through non-persistence". That is, you should extensively make use of the snapshot and roll back feature of the virtual machine. Instead of privilege separation within a Tor-Workstation (e.g. by using a Mandatory Access Control framework) which would come at great usability costs we recommend to use the coarse-grained isolation provided through multiple VMs (also see "About grsecurity" below).
    352 To protect against software attacks (vulnerabilities) in particular:
    353  * make software hard to attack
    354 ASLR, canaries, NX, kernel hardening, See the ubuntu section below: [ About Ubuntu]. Note that this makes attacks "harder" but not impossible. Hardening is no replacement for fixing bugs. In a really trustworthy system hardening would not be necessary.
    355  * detection
    356 This is still left to the user. IDS, Log auditing. The usefulness of this approach is limited. It doesn't prevent security breaches. It can only help making future breaches less likely.
    358 To mitigate Design flaws the primary strategy is eliminating single points of failure. Do not rely on Tor alone, use wifi or tunnel through another system running VPN. Do not rely on TLS alone, use GPG as well (and vice versa). Do not rely on a software monoculture, you shouldn't have to rely on Ubuntu/Canonical's infrastructure to never be compromised. We are currently guilty of not following this advice. To lessen the impact of a potential compromise of the update infrastructure (which includes developer machines, build systems, key security and cryptographic primitives like PRNG - remember openssl or Flame?) we do not enable automatic software updates. After all, they are essentially remote root level backdoors (although with some checks in place).
    360 === Notes about securing Confidentiality, Integrity and Authenticity ===
    361 This is no different than in any other computer system without Tor. Use end to end public key encryption, there is not really an alternative to that. But there are alternative implementations: TLS, SSH, GPG... End to end means both ends need to be secure, one end is the aos-Workstation which you can control and secure. In case of hidden services, the aos-Gateway is ALSO part of the TCB!
    363 aos-Worstation isn't specifically hardened because hardening a Desktop system to a degree that makes it actually secure against a serious adversary makes the system unusable. Instead we follow the nuke and restore approach, see below: [ Recommendation to use multiple aos-Workstation VM's and Snapshots]
    365 About Availability: This is most likely the least of our worries. The most resilient approach is probably a distributed data store, like Tahoe-LAFS or Freenet. i2p offers multi-homing built in. For Tor we don't know of any solutions ready for general usage.
    367 ==== Notes about End-to-end security of Hidden Services ====
    368 Hidden services are not really "end-to-end" encrypted, they encrypted only Tor to End. (or "Tor to Tor") The communication between the browser or server and Tor is sent in clear text. This doesn't really constitute a security issue, as localhost (or Workstation to Gateway on an isolated network), is supposed to be secure. But it has some security implications:
    370 With hidden services alone, without TLS enabled, the adversary only needs to compromise aos-Gateway to get knowledge of the content of the connection and the clients identity/location. To compromise the content of the connection, the adversary only needs to compromise either the gateway or the workstation.
    372 With hidden services, and TLS enabled, an adversary needs to compromise aos-Workstation to gain knowledge of the content of the connection. The adversary would have to compromise aos-Gateway as well, to gain knowledge of the client's identity/location.
    374 It is possible to use hidden services and TLS at the same time, i.e. https://****************.onion. There are only a very few hidden services reachable over TLS. For example can be reached over https://ttbmov2dezfs2fln.onion/. But since this only offers benefits to users of aos (and other Tor gateway implementations), there is no demand. It would provide some nice defense in depth as it eliminates a single point of failure.
    376 It would open the question, how would the certificate be verified?
    378 That's simple for private sites, where server and clients know each other. They simply verify it over preshared secure channel, for example, a meeting.
    380 And public hidden services? It is unlikely, that certificate authorities will give out certificates for .onion sites. declined, because .onion is no .gTLD, see #6116. Although you could try asking other certificate authorities, if they offer SSL certificates for people who can prove that they own a .onion domain. You can prove, that you have control over the domain by editing its contents on their request.
    382 But CAs should not be relied on anyway. Look into [ Monkeysphere], [ Convergence] or [ Perspectives Project]...
    384 Hidden Services with aos are still safer than running Tor and the server software on the same host, see [ Hidden Services] for more information.
    386 == Attack on aos ==
    387 Knowledge assumed:
    388  * [ Comparison of different aos variants].
    389  * Unsafe Browser: Tails and Liberte Linux contain a so called Unsafe Browser. The Unsafe Browser does not use Tor. Connects in the clear. It is useful to register on hotspots or to view content in the clear without Tor.
    390  * exploit against physically isolated aos-Gateway: difficult against a bare metal physical isolated aos-Gateway. This is because aos-Workstation can only access Tor running on aos-Gateway. We minimized attack surface, hardening etc. See the whole Security and Hardening page for details.
    391  * TBB stands for Tor Browser Bundle.
    393 Aos protects against root exploits and malware with root rights. This does not mean, risk to get infected with malware. Do not! Like said at other places as well, aos is not a perfect system. It can not be. Aos is not unbreakable. What aos does, it higher the effort for an attacker. The following table shall visualize the various defense layers provided by aos.
    395 || attack || TBB || TBB in a VM || Tails || Tails in a VM || aos Standard Download version host+vm+vm || aos Physical Isolation
    396 || (1) Protocol IP leak || fail || fail || fail || fail || safe || safe
    397 || (2) exploit + Unsafe Browser || fail || fail || fail || fail || safe || safe
    398 || (3) exploit + root exploit + Unsafe Browser || fail || fail || fail || fail || safe || safe
    399 || (4) root exploit + Unsafe Browser || fail || fail || fail || fail || safe || safe
    400 || (5) exploit + vm exploit + Unsafe Browser || fail || fail || fail || fail || fail || safe
    401 || (6) exploit + vm exploit + exploit against physically isolated aos-Gateway || fail || fail || fail || fail || fail || fail
    402 || (7) vm exploit || safe || fail || safe || fail || fail || safe
    403 || (8) vm exploit + exploit against physically isolated aos-Gateway || safe || fail || safe || fail || fail || fail
    404 || (9) exploit against Tor process || fail || fail || fail || fail || fail || fail
    405 || (10) attack against the Tor network || fail || fail || fail || fail || fail || fail
    407 (1) For example proxy bypass bugs, where the application spills the users real IP. See [ aos security in real world], for examples where aos circumvented them. It gets circumvented by aos because aos-Workstation does not know the users real IP address.
    409 (2) Example: user visits a website over Tor with a torified Browser. The website uses known or zero day vulnerability to gain remote code execution on the users machine. Remote cod execution is used to install malware on the users machine. The used vulnerability allows the adversary to get "only" user rights, not root. The adversary could remotely start the Unsafe Browser and therefore find out the users real IP address. This attack gets circumvented by aos, because any applications inside aos, including malware, can only connect through Tor.
    411 (3) Example: user visits a website over Tor with a torified Browser. The website uses known or zero day vulnerability to gain remote code execution on the users machine. Remote cod execution is used to install malware on the users machine. The used vulnerability allows the adversary to get "only" user rights, not root. The adversary gains root through escalate privileges using a second vulnerability. This allows the adversary to tamper with iptables rules, to make non-Tor connections and so on. This attack gets circumvented by aos, because aos's Firewall runs on another (virtual) machine. This attack gets circumvented by aos, because any root applications inside aos, including malware with root rights, can only connect through Tor.
    413 (4) Example: user visits a website over Tor with a torified Browser. The website uses known or zero day vulnerability to gain remote code execution on the users machine. Remote cod execution is used to install malware on the users machine. The used vulnerability allows the adversary to get root rights. This allows the adversary to tamper with iptables rules, to make non-Tor connections and so on. This attack gets circumvented by aos, because aos's Firewall runs on another (virtual) machine. This attack gets circumvented by aos, because any root applications inside aos, including malware with root rights, can only connect through Tor.
    415 (5)  Example: user visits a website over Tor with a torified Browser. The website uses known or zero day vulnerability to gain remote code execution on the users machine. Remote cod execution is used to install malware on the users machine. A second exploit is being used to break out of the Virtual Machine. aos Standard Download version host+vm+vm is broken against this attack. aos Physical Isolation defeats this attack, because the aos-Workstation's host does not know it's real IP address, only aos-Gateway, running on an other physical machine knows it.
    417 (6) Same as attack (5). But the adversary uses an extra vulnerability to break into aos-Gateway. Aos is broken against this attack.
    419 (7) Example: user visits a website over Tor with a torified Browser. The website uses known or zero day vulnerability to gain remote code execution on the host. aos Standard Download version host+vm+vm: fail, same as attack (5). Physical Isolation defeats this attack, same as attack (5).
    421 (8) Example: user visits a website over Tor with a torified Browser. The website uses known or zero day vulnerability to gain remote code execution on the host. The adversary uses an extra vulnerability to break aos-Gateway. Aos is broken against this attack.
    423 (9) Example: user visits a website over Tor with a torified Browser. Tor processes the traffic. The adversary uses a vulnerability to gain remote code execution. The machine were Tor is running always ^2^ knows the users real IP address. Aos is broken against this attack.
    425 (10) Example: end to end correlation attack, but there are much more attacks where Tor is known to be broken against. Any successful attack against Tor on a Tor based anonymity operating system will naturally deanonymize the user. ^2^ ^3^
    427 ^1^ Placeholder. [[BR]]
    428 ^2^ Unless you are using Multiple Gateways. (Optional aos feature in progress.) [[BR]]
    429 ^3^ Aos defeats some attacks against Tor (and components such as Tor Browser), for example, see [ aos's Secure And Distributed Time Synchronization Mechanism] and [ aos's Protocol-Leak-Protection and Fingerprinting-Protection] and the rest of the Security and Hardening page.
    431 == Design Document, innovations and research ==
    432 aos developer proper is also interested in serious design documents. There is only one design documents with respect to Tor, transparent/isolated proxying, isolation and Virtual Machines. Proper has read the old design paper "A Tor Virtual Machine Design and Implementation" from 2009, which can be found at [ DesignDocumentBase]. After reading, proper forked that paper, removed non-essential, non-security relevant stuff and made sure, all considerations from the old design paper, were implemented into aos. The forked paper can be found at [ DesignDocument].
    434 The whole aos documentation, especially [ TorBOX/SecurityAndHardening] and [ TorBOX/ApplicationWarningsAndNotes] supersedes the old design document. Also the [ TorifyHOWTO] is co-maintained by proper.
    436 Also the following documents are being monitored.
    437  * [ Tails Design]
    438  * [ Tails Design: specification and implementation]
    439  * [ Security and Anonymity in Liberté Linux]
    440  * [ Liberté Linux Motivation and Philosophy]
    441 If there are any security/privacy/anonymity updates they will be considered for aos.
    443 The aos project also enjoys asking good questions, providing useful suggestions and creating useful things.
    445 The following list is to keep track of all discussions and to review them in the future again, to see if something has changed.
    447  * Smarm created serious [ LeakTests], which have been [[ scripted] by proper and which are potentially useful for other projects as well.
    448  * [ Tor project trac, Reporter is proper]
    449  * [ Tails-dev Removing SSL CA dependency for HTP]
    450  * [ Modified usewithtor to support setting ip and port by command line parameter by proper]
    451  * #5928 Research: IP discovery through Tor behind isolated network
    452  * #5611 Enhance "Transparent Torification (Requires custom transproxy or Tor router)" in Tor Button.
    453  * Read [ aos/Dev] and also read the archives. We don't just do things. Everyone is invited to add some points and then we try to make the best decision.
    454  * [ tor-talk Tor Browser disabling Javascript anonymity set reduction]
    455  * [ tor-talk Awareness for identity correlation through circuit sharing is almost zero.]; #6102
    456  * [ tor-talk Operating system updates / software installation behind Tor Transparent Proxy]
    457  * [ tor-talk Attack against Tor: Statistic Manipulation Attack]
    458  * [ Tails-dev tails_htp: exit node can fingerprint Tails users until exit node is changed]; [ 2]
    459  * [ Tails-dev better IRC client, include XChat]
    460  * [ Tails-dev separate Tor streams]
    462  * ...
    464 == aos Thread Model not available as pdf or paper version ==
    465 You may skip this optional chapter. Written by aos developer adrelanos.
    467 While I read real papers, like the [ Onion routing design paper] and many others, I can't be coerced into creating a paper "Designing an anonymous operating system" with latex as pdf.
    469 Like Mike Perry, developer of Tor Browser [ said] "I find the pdf format heavy and unnerving from a security perspective.". That also goes for me and I also find the pdf format inconvinient. It would also take me some time to learn latex, pdf creation, formatting etiquette and so on. Time, which I rather invest into improving the design, developing and so on. The "Onion routing design paper" is now also outdated and I rather have an editable, often updated and revised website compared to a paper/pdf.
    471 Tails does also not have a design paper as pdf and still lots of users and developers. Also TrueCrypt had not design paper about plausible deniability and still got reviewed by Bruce Schneier et al.
    473 = aos's Protocol-Leak-Protection and Fingerprinting-Protection =
    474 *** Read Security of aos and aos thread model above first!
    476 aos can not do the impossible and magically prevent all kinds of [ protocol leaks]. However, it does offer best possible protection. It is a multi level protection always trying to prevent the worst.
    478 1. most dangerous leaks are protected
    479  * Your real external non-Tor IP address are covered due to the whole aos design, isolated proxy usage and [ the aos firewall]. ^1^
    480  * The same as above goes for DNS^1^ requests, they are safe. ^2^ [[BR]]
    481  ,,^1^ This does not cover application vulnerabilities and exploits, which escalate from the virtual machine to the host see ***. However, by design, the aos-Workstation does not know it's own external non-Tor IP address. [[BR]]
    482  ^2^ /etc/resolv.conf in aos-Workstation is configured to use the aos-Gateway as DNS resolver, which is routed through Tor. ,,
    484 2. Many aos default applications are already configured, not to leak:
    485  * Using their own SocksPort, thus preventing [ identity correlation through circuit sharing].
    486  * Browser fingerprinting: aos [ includes] and [ recommends the Tor Browser]. Browser fingerprinting is as good/as worse, as you were using the normal Tor Browser Bundle.
    487  * GPG: is configured not to leak your operating system version (no-emit-version).
    488  * XChat: uses [ secure defaults].
    490 3. Many protocol leaks are [ documented] (read!) and [ also workarounds are provided] (read!).
    492 4. aos uses common, non-identifying defaults.
    493  * Desktop resolution is 1024x768 for all aos users. ^a^ ^c^ [[BR]]
    494  ,,^a^ You can check that by running 'xrandr' in console. (Not installed by default.)
    495  * Color depth is the default 24 bit for all aos users. ^b^ ^c^ [[BR]]
    496  ,,^b^ You can check that by running 'xdpyinfo | grep "of root"' in console. (Not installed by default.) [[BR]]
    497  ,,^c^ Note that you can not rely on or similar websites for checking that, because Tor Button changes this values to improve your anonymity. See Tor Button specification, Tor trac for details.
    498  * All aos users have the same list of fonts installed. ^d^ ^e^ ^f^ [[BR]]
    499  ,,^d^ 'fc-list' [[BR]]
    500  ,,^e^ As long you or any additional software packages do not install further packages. [[BR]]
    501  ,,^f^ Robert Ransom suggested, if possible, to share the same list of fonts as Tails. Since Tor Browser does not leak, which fonts are installed anymore ^g^, aos developer adrelanos fails to see the advantage of this. Follow-up inquiry running... [[BR]]
    502  ,,^g^ Only 3 common fonts (monospace, serif, times new roman) for all Tor Browser / TBB users can be detected. [[BR]]
    503  * Internal (virtual LAN) IP address is the same for all aos users.^3^ [[BR]]
    504  ,,^3^ You can check that yourself using 'ifconfig'. ,,
    505  * Time zone is set to UTC.
    506  * User name is set to user.
    507  * [ MAC address] is the same for all aos users.
    508   * aos-Workstation's MAC address is shared among all aos users. That is useful, in case an application leaks the MAC address or in case aos-Workstation got compromised.
    509   * aos-Workstation can also see aos-Gateway's MAC address.
    510   * aos-Gateways MAC address is also shared among all aos users. '''This may have side effects, were are still discussing, see [ Mac address in public networks].'''
    511  * Disc UUID is the same for all aos users.
    512  * Hardware serial numbers which any applications could collect are hidden due to the Virtual Machine.^4^ [[BR]]
    513  ,,^4^ You can check visible hardware yourself with 'sudo lshw' and "sudo lspci". Use 'usbutils' if you installed USB. ,,
    514  * CPU model and capabilities are hidden by Virtual Box "Synthetic CPU" option.
    515  * Unfortunately, the clock speed of your host CPU is visible to all code (applications or malware) inside aos-Workstation.^5^ [[BR]]
    516  ,,^5^ This is due to the design of virtualization platforms (VirtualBox, VMware, etc.). Most virtualization platforms leak cpu model, capabilities and clock speed. VirtualBox (4.1+ if not earlier) can mask at least the model and capabilities of the CPU with the "Synthetic CPU" option. This option is activated by default on aos 0.2.1 and above. Check ''cat /proc/cpuinfo''. If that is a still problem for you another workaround could be to use an emulator, such as [ bochs] or qemu. Unfortunately such emulators are slow. ,,
    517  * Sensor information (cpu temperature, hdd temperature, [ S.M.A.R.T.]) are hidden. ^6^ Fortunately Virtual Box does hide them from the guest Virtual Machine by not implementing them. [[BR]]
    518  ,,^6^ You can check that using 'sudo hddtemp /dev/sda' and 'sudo sensors-detect'.
    519  * All aos users have by default the same set of software packages installed. - If you install software packages yourself, you give up that advantage. See also [ Software updaters] and [ Software installation aoss aos-Workstation].
    520  * Automatic updates are routed through their own circuit (stream isolation) to prevent accidentally leakage of your software packages and versions (if any custom software installed) which then could be correlated with other anonymous activity. See also [ Software updaters] and [ Software installation aoss aos-Workstation].
    521  * Metadata (as explained under [ protocol leaks]) can not be used to de-anonymization, if you follow the following guidelines:
    522    * Always think twice before uploading anything.
    523    * Upload only files, which you, either:
    524      * created inside your aos-Workstation
    525      * downloaded using your aos-Workstation
    526      * carefully scrubbed yourself
    527    * For example, if you want to upload photos or videos, unless you know what you are doing, get an extra device, which you only use for anonymous usage.
    528    * Keep in mind, that even if de-anonymization is not possible, that still identity correlation to the same pseudonym might happen. For example, let's suppose your created a video using any video creation software and you uploaded it to a popular video portal under the pseudonym A. Then you create a another video using the same machine (and same application) and upload it under the pseudonym B. An adversary checking the metadata could correlate pseudonym A with pseudonym B.
    529  * Worst case scenario: contents of your RAM (error reporting ram dump; [ Transparent Proxy Leaks]) would "only" contain the RAM of your aos-Workstation. All your non-anonymous stuff on your Host would stay safe.
    531 = aos in public networks / MAC Address =
    532 Keep care in public networks. Note the following advice.
    534 Source of information: [ Tails 1]; [ Tails 2]. Both worth reading! Thanks to Tails!
    536 Every network interface has a [ MAC address]. The MAC address is only visible inside LAN, not inside WAN. While you are at home, this isn't an issue.
    538 There are cases, were some stupid applications gather your MAC address and send it to a remote server (proprietary license checks use the MAC for hardware fingerprinting). That's not an issue for aos, since all aos users share the same MAC address on aos-Workstation, see [ aos' s Protocol Leak Protection and Fingerprinting Protection] for details.
    540 You have to keep care, if you are going to use aos in public networks (i.e. open WIFI hotspot). The admin might log your MAC address.
    542 Rather the admin might find out, that you are using Tor, depending on your your configuration, i.e. perhaps you are using obfsproxy or you tunnel your traffic SSH/VPN -> Tor and on the adversary's skills.
    544 The MAC address and being a Tor user, might depending on your personal thread model, be a risk visiting that public network (again).
    546 Using a random MAC address is not recommend. While this might sufficiently confuse some adversaries, it won't defeat skilled adversaries. If you are using a random MAC address, it might happen that the vendor id part of the MAC address is non-existent. Even if it were existent, you might up with a vendor id, which has either never been used or never been used in decades. If you are going to spoof your MAC, you have to use a popular vendor id.
    548 The initial second part of the MAC address may be random/unique.
    550 If you are going to use the same public network again, you have to decide, depending on your thread model, if you are going to use the very same MAC address or if you are going to create a new MAC address. In case you suspect, the admin has seen you and logged the MAC, you shouldn't change the MAC, since this were suspicious. If you believe that public network is so public, that no one has seen you, you might decide to use a new MAC address (popular vendor id, random/unique second part) each time you step by.
    552 Unfortunately, we can't yet provide detailed instructions on how to create such appropriate MAC addresses. Research is still ongoing.
    554 Apart from the difficulty creating such an appropriate MAC address, there are also technical hurdles. All the care creating the MAC does not help, if you boot your computer and it instantly connects to the public network and spills your MAC. For Virtual Machine users: your host operating system most likely automatically connects (updates, perhaps time sync). For Physical Isolation users: aos-Gateway automatically connects to Tor after start.
    556 Also if you plug in a wifi stick, it might happen, they automatically try to connect and spill your MAC.
    558 TODO: test and expand, please help!
    559 To change the Mac address in Tor-Gateway or a Debian/Ubuntu host edit /etc/network/interfaces and add "hwaddress ether 00:00...." To automatically randomize the MAC address on boot add "pre-up macchanger -e eth0" instead. To prevent automatically bringing up new network interfaces I think all that's needed is to uncomment "auto eth0", then manually bring up with "sudo ifup eth0".
    561 = Anonymity Network =
    562 == Introduction ==
    563 Tor has been chosen for aos example implementation, because it's the best researched and most used network. Aos developer adrelanos believes Tor is currently the most secure anonymity network legally available to most users. See [ anonlib] for a collection about research papers about Tor and other anonymity networks.
    565 Many users are important, because you can only be anonymous within a big group of people. More secure networks exist in theory, such as the mixminion high latency network, but without enough users, in practice they are less secure. See [ Roger Dingledine explanation] for details.
    567 The [ aos concept] is agnostic about the Anonymity Network being used, see [ other anonymizing networks].
    569 == About Tor ==
    570 Any successful attacks against Tor, does also work against aos and will result in a compromise of location/identity. ^1^
    572 Aos does not try to defend against network attacks, like a massive amount of evil nodes, end to end correlation attacks and so on. We leave that to the Tor developers. Developing aos is already a big task.
    574 If TransPort, DnsPort or SocksPort, which aos heavily relies on, can be exploited, then it's also game over.
    576 There is no known bug (or "feature") to obtain the users real IP address through either SocksPort, TransPort or DnsPort. If there were such a bug found in the future, which is possible, it would be a major bug in Tor. We would hope, that the Tor developers fix that bug. We hope that compile time hardening features will be added (bug #5024 and #5210).
    578 There are other attacks thinkable, which we can not defend against. For example, if an adversary controls your entry node or can observe your ISP and has access to the aos-Workstation. He can simply use "morse" (5 seconds much traffic, 10 seconds no traffic...) And then observe it's incoming connections. Then it's game over as well.
    580 ,,^1^ Unless Tor is combined with other means of anonymization (optional feature).
    582 = Host Security =
    583 == Introduction ==
    584 If the host is compromised so is every VM, Tor and all anonymous communication. The host should only be used to run and manage the VMs.
    586 == Recommendation to use a dedicated host ==
    587 You are advised to use a dedicated host operating system installation. Not in a cloud, that would virtually destroy any additional security! Dedicated within the meaning of using a second/extra host operating system(s), which you never use(ed) for anything else.
    589 == Recommendation to use aos on External Media ==
    590 No one stops you from installing the host operating systems(s) required for aos on external disks such as USB, firewire, eSATA, etc. You can improve security by installing aos's host operating system(s) on a dedicated disk(s). That reduces the risk that any other operating system(s) of yours infecting aos's host operating system. You can remove and hide the aos disk(s) while you're not using them.
    592 Aos on CD or DVD has yet not been worked on, although there is a development discussion.
    594 == Recommendation to use aos with Physical Isolation ==
    595 aos using Physical Isolation, setup using two different computers AND virtualization. This is the most secure Tor configuration to date. Unfortunately, it is difficult to setup. See[ aos/BareMetalHints].
    597 == One VM ==
    598 '''One VM is deprecated.''' It was tested and developed for 0.1.3. The concept worked. It's deprecated now, because it has no maintainer.
    600 Alternatively, you could also use [ one VM instead of two], where Tor runs on the host. It has some security and other kinds of advantages/disadvantages listed in the article.
    602 == aos without Physical Isolation ==
    603 Affects Standard / Download version (host+VM+VM). Does not affect aos with Physical Isolation.
    605 Robert Ransom pointed out: "The main lesson of #6537 and #6538 was that Tor is not designed to keep various sensitive pieces of information secret from other native-code programs running on the same physical processor."
    607 It depends on the implementation details of the Virtual Machine and the processor. It's a difficult topic. We are now aware of any research about this topic. Robert Ransom pointed out as well, that probable no one would bother with this attack and rather use an exploit against the Virtual Machine. Aos developer adrelanos agrees.
    609 Anyone looking into aos solely because of security should really consider using aos with [ Physical Isolation].
    611 == Hardening ==
    612 Aos does not yet improve host security. You are advised to use a secure host operating system.
    614 General hardening recommendations apply: Minimize attack surface, securely configure services (e.g. for ssh: use fail2ban, allow only key authentication), add proactive (compile time hardening, MAC, IPS...) and retroactive defenses (rkhunter, IDS, AV...). This is probably beyond the scope of this guide.
    616 == Physical Attacks ==
    617 To protect against physical attacks use FDE (Full Disk Encryption) and always lock the screen if you leave the system unattended. Keep [ cold boot attacks] in mind. Unfortunately there is not yet a upstream script, to implement wiping the RAM. We can not provide a solution for this attack, this is solved nowhere but partially in Tails and Liberte Linux (not checked), waiting for upstream solution, see [ Wipe RAM panic script].
    619 == Risks through hardware components ==
    620 Thanks to Robert Ransom for pointing aos developer adrelanos to this issue.
    622 Assumption: [[BR]]
    623 an adversary managed to break out of aos-Gateway's Virtual Machine using an exploit.
    625 Hardware components, either built in or extra components, such as CPU or hdd temperature sensors, microphones and cameras introduce risks.
    627 Aos with Physical Isolation is affected. [[BR]]
    628  * Users IP address is still safe, but the temperature sensors can be used for anonymity set reduction. Different CPU or hdd models will have a different sensor information, depending on climate and weather. If you can, you are advised to remove or to obfuscate the sensors result.
    629  * Camera and microphones can be covertly activated by the adversary. At least remove them (external ones) or disable them in BIOS if possible. Better cover them or ideally remove them.
    631 Aos Standard / Download version (host+VM+VM) is affected, although it does not matter: [[BR]]
    632  * Same as above applies. If the assumption is true, the adversary can already find out the users real IP address.
    634 = Operating System =
    635 This chapter applies to the host(s), aos-Gateway and aos-Workstation.
    637 Aos example implementation is currently based on Ubuntu. There are development discussions about switching to Debian, BSD, Alpine Linux or other secure operating systems.
    639 == Recommendation to install latest security updates on all systems ==
    640 Important!
    642 == About Ubuntu ==
    643 While Ubuntu is one of the more [ secure] Linux distributions it's by no means a secure operating system. It is designed first and foremost to bring Linux to end users. It doesn't protect against some of the threat models that some Tor users will have.
    645 Here's an (incomplete) list of things the more paranoid user will have to consider:
    646  * apt-get as currently used in Ubuntu does not protect against a "stale mirror attack" where an adversary provides validly signed but outdated metadata to prevent users from downloading and installing the latest critical security updates. When fetching updates over tor this problem is of a lesser extent because no single malicious exit node will realistically prevent users from downloading updates more than once in a row. Malicious mirror is possible but aos-Workstation uses the main US mirror, any irregularities will be uncovered pretty soon. More of concern is the clear text update of the host operating system. Here it's a good idea to manually check how old the repository metadata is yourself:
    648 {{{
    649 find /var/lib/apt/lists/* -type f | xargs cat | grep "Date: "
    650 }}}
    652   From time to time vulnerabilities that allow installation of untrusted code are discovered in apt. New security features are often implemented in Debian first.
    654  * aos can't protect against malicious code inserted into Ubuntu infrastructure. Ubuntu uses bzr/launchpad which ensures some chain of trust as it requires contributors to sign commits.
    656  * The Ubuntu server kernel comes with everything and the kitchen sink. At any given day the kernel will be vulnerable in one way or the other. It's by far the most patched piece of code in the default Ubuntu Server installation, obviously runs at full kernel privileges and naturally can't be protected with mandatory access control. aos-Gateway exposes the kernel to attacks through its firewall, TCP/IP stack and whatever kernel calls Tor does or could be compelled to do.
    658   [] --kernel reports good kernel protection: GCC stack protector support, Enforce read-only kernel data, Restrict /dev/mem and /dev/kmem access are all enabled!
    660  * Userland protection for Tor is great. Unlike TBB bundles the tor version distributed via the .deb comes with RELRO, canaries etc. and can fully make use of ASLR since it's compiled as PIE. Of course with Grsec the entropy would be higher.
    662 == Harden Software Repositories ==
    663 Many operating systems provide multiple repositories. Since aos's example implementation is based on Ubuntu, you should read [ Ubuntu Repositories] as introduction. In conclusion, the main repository gets most attention and security updates. It would make sense to tweak '/etc/apt/sources.list' and to only use software from the main repository and to only install security fixes, no other updates.
    665 Aos currently doesn't do that by default and it's an open question for research if that really improves security.
    667 [ dpkg-origins] can create a list of all packages and their repository.
    669 == About grsecurity ==
    670 Linux kernel is not a secure OS, Linus himself made it pretty clear that he doesn't think highly of the "security community". His threat model and a Tor User threat model don't have much in common. Good that Linux is open source and if we disagree with a policy or politics we can just patch or fork it... Grsecurity/PaX is the most comprehensive kernel patch providing much needed security hardening both for the kernel itself and for making userland protections more effective.
    672 Sadly no distribution of binary grsec kernel exists.* That means either a packager/maintainer of aos needs to compile them EVERY TIME there is a security update to the kernel (which is pretty frequently) or the aos users themselves need to compile and update their kernels. This is undesirable because kernel compilation is not set and forget, you need a bit of knowledge, it takes a while, especially in a resource restricted VM and you need to keep updated about new releases via mailing lists or similar because your software updater doesn't automatically handle custom kernels (even emerge in hardened gentoo doesn't). All this would most likely only result in users running old, outdated kernel versions.
    674 Further for aos-Gateway and the Identity/Location TCB grsecurity only addresses a subset of security risks: It can mitigate *some* kernel vulnerabilities (and we only really care about the networking stack which is pretty secure judging from its track record). *Maybe* *some* (memory corruption) vulnerabilities in apt-get and Tor that aren't already mitigated by the existing userland hardening done by Ubuntu. It can't protect against backdoors or security issues related to design, policy or yet unknown classes of exploits. We feel that these relatively small advantages outweigh the issues introduced by using a custom compiled kernel. We hope a binary distro will step forward and start using grsecurity. In that case we'll most likely switch aos' aos-Gateway to that distro as soon as possible. (*There's Alpine Linux but they don't package Tor yet:
    676 For aos-Workstation the benefits are even more doubtful. To be effective grsecurity needs to lock down some functions that are needed by Xorg, JIT compilers... but we need those to be working. To solve this we'd have to write a restrictive RBAC policy which is far from trivial. We think accepting that aos-Workstation will be exploitable and acting accordingly (using snapshots and rolling back to clean state) is the right approach for a desktop system.
    678 If you disagree with this assessment or have any suggestions how to improve the current situation please let us know on [ aos/Dev]!
    680 Experts only: There is also [ Hardened Gentoo based aos-Gateway].
    682 = Virtualization Platform =
    683 Aos example implementation is based on Virtual Box. There is a dev discussion about switching to a more secure Virtualization Platform and help is required.
    685 In an ideal world, aos example implementation would support all Virtualization Platforms. Theoretically it could be done using [ libvirt]. Practically  libvirt is out of question. [ libvirt-users Does libvirt abstract each and any vm specific command?] Libvirt does not (yet) abstract some commands aos depends on.
    687 == About VirtualBox ==
    688 VirtualBox is developed by Oracle, a company not exactly know for being very "open". That includes how they announce security issues in their products as well as how they are perceived by the security community and how they will communicate with each other.
    690 VirtualBox is primarily a simple, "user friendly", desktop solution and most certainly not designed with our threat model in mind. I haven't heard of anyone seriously auditing the code and I'd like to recommend a different VM solution at least as an alternative. There's KVM and Xen, open source but not cross-platform. It seems they are still lacking in terms of a reliable "internal networking" feature which aos heavily depends on. (If you know more, please edit this paragraph).
    692 Anyone looking into aos solely because of security should really consider using aos with [ Physical Isolation].
    694 == Harden Virtualbox ==
    695 For an overview on security risks of VMs in general: [ How secure are Virtual Machines really?]
    697 The less features, the smaller the [ attack surface]. Here are some suggestions for features which you can remove and not impact core functionality:
    699  * Disable Audio
    700  * Do not enable Shared Folders
    701  * Do not enable video accelaration
    702  * Do not enable Serial Port
    703  * Do not install Guest Additions
    704  * Remove Floppy drive
    705  * Remove CD/DVD drive
    706  * Do not attach USB devices
    707  * Do not enable Remote Display server
    708  * Do not enable IO APIC, EFI
    709  * Enable PAE/NX? (NX is a security feature)
    711 For the best security you should consider using multiple physical systems, see [ Physical Isolation].
    713 = aos-Gateway Security =
    714 You should never use aos-Gateway for anything other than running Tor on it!
    716 If this machine is compromised the identity (public IP), all destinations and all clear-text (and hidden service) communication over Tor is available to the attacker.
    718 Our first goal in securing the aos-Gateway is minimize its attack surface. By installing a "minimal system" and using static IPs the only attack surface to an external attack (i.e. not physical and not attacks from the host which can never be protected against) is Tor itself. You can verify this with netstat.
    720 Security features that do not prevent exploitation but only restrict what exploits can do, such as chrooting or sandboxing, do not make much sense: A compromise of Tor already results in a compromise of everything the user cares about.
    722 Compile time hardening (see bug #5024) should be done by the Tor package maintainer and is beyond the scope of aos.
    724 Ubuntu is a good choice as a base for the aos-Gateway, Tor is well supported and compared to Debian for example, all the currently used compile time hardening features are supported by default [ Ubuntu Security Features]. More secure and hardened Linux or BSD based options do exist but they require too much work and/or maintenance to be considered for aos.
    726 Having said this, you are welcome to use your own distro. The aos design is distro agnostic. You just won't be able to thoughtlessly copy and paste commands or to use the source without modifications.
    728 There is also [ Hardened Gentoo based aos-Gateway] (unfinished, experts only!).
    730 = aos-Workstation Security =
    731 == Introduction ==
    732 If this VM is compromised all data it has access to, all credentials, browser data, passwords... the user has entered can be compromised. The IP is never leaked but these information can still result in identity disclosure.
    734 Best practice is to create snapshots of the VM and "roll back" after risky activity and whenever the user suspect the integrity of the system could have been compromised, see [ Recommendation to use multiple VM Snapshots].
    736 Aos example implementation is currently based on Ubuntu, see About Ubuntu.
    738 == Hardening ==
    739 Use AppAmor:
    740  * [ AppArmor Profile for TBB]
    742 == Software installation on aos's aos-Workstation ==
    743 You can install your own software packages on aos-Workstation using 'apt-get', as it's based on Ubuntu. This has some advantages and some disadvantages as well. [[BR]]
    744 Advantages:[[BR]]
    745  * Obviously you can install your favorite software packages. Almost any application with a few exceptions listed under [ impossible to torify].
    746  * You are protected from IP and DNS leaks. (Read above for details.)
    747  * You have some, but no perfect [ Protocol-Leak Protection and Fingerprinting-Protection]. [[BR]]
    748 Disadvantages: [[BR]]
    749  * You should still try to prevent any other [ protocol leaks] using the [ TorifyHOWTO] (but most of those most are mitigated by using aos).
    750  * When you are updating using apt-get, you'll leak which software packages and versions you have installed, see [ Software updaters]. This information can not be directly linked to any other activity, such as web browsing, because the aos apt-get uwt wrapper forces apt-get to go through it's own circuit. There are still risks for [ correlation] to the same pseudonym. ^1^ ^2^
    752 You should update using the guidelines below "How to safely update using apt-get?".
    754 Extra care is needed when adding extra custom repositories, especially PPA's (Personal Package Archives). Single developers may be pressured and/or turn malicious more easily than the main repositories.
    756 ,, ^1^ For example, if you announced somewhere, that you a X user and have a specific set of x, y, and z installed, this information may be available to an adversary. If you run apt-get (which goes through it's own circuit) though any exit nodes, mirrors or ISP's controlled by the adversary, it's possible to guess for the adversary, that it's the same pseudonym, which is running it. In that case the adversary gets your list of installed packages, can run stale mirror attack (see About Ubuntu), or can try other attacks against apt-get. [[BR]]
    757 ,, ^2^ Another example, if you run a hidden service with a specific set of server software, let's say apache, mediawiki, phpbb, x, y, z... Similar as ^1^...
    759 == How to safely update using apt-get? ==
    760 1. Stop all your activities. ^2^ [[BR]]
    761 2. Change your circuit.^1^ [[BR]]
    762 3. Update using apt-get after a random delay. [[BR]]
    763 4. Change your circuit again.^1^ [[BR]]
    764 5. Continue your activities later with a random delay. [[BR]]
    766 ,,^1^ One way to do it using [ Arm]: Go to your aos-Gateway and start "arm". Press 'm' for menu, go down to "New Identity" and press enter. [[BR]]
    767 ,,^2^ Maybe not, if you run a hidden service.
    769 == Adding NAT adapter to aos-Workstation / Updates without Tor ==
    770 Obviously the anonymity will get compromised if you add another NAT network adapter to the aos-Workstation. It is quite clear not to do that. If you were infected, it could leak then. Therefore it's recommend to do updates over Tor. It's slow and there are no leaks.
    772 == Adding Host-Only Networking adapter to aos-Workstation / SSH into aos-Workstation ==
    773 One might wish to access the aos-Workstation through SSH. Therefore one could add a second network adapter with [ Host-Only Networking]. Dangerous, don't add another network adapter! Also potentially dangerous if any other VMs are running besides aos-Workstation! The warning of VMware Host Only networking may also apply to aos: "If you install the proper routing or proxy software on your host computer, you can establish a connection between the host virtual Ethernet adapter and a physical network adapter on the host computer. This allows you, for example, to connect the virtual machine to a Token Ring or other non-Ethernet network.
    775 On a Windows 2000, Windows XP or Windows Server 2003 host computer, you can use host-only networking in combination with the Internet connection sharing feature in Windows to allow a virtual machine to use the host's dial-up networking adapter or other connection to the Internet. See your Windows documentation for details on configuring Internet connection sharing."
    777 If you want to SSH or VNC your aos-Workstation, your safest bet could be to run those services using [ hidden services] and to access them from the host using the ordinary torification methods.
    779 == Recommendation to use multiple VM Snapshots ==
    780 Apart from offering protection against hardware serial leaks VMs got another great advantage: the ability to quickly discard and restore a system.
    782 It is recommended that you keep a master copy of aos-Workstation, keep it updated, make regular "clean" snapshots but do not edit any settings or install additional software or use it directly for any activity. Instead make a clone or use snapshotting (but never mix up clean and unclean states!) for activities that require anonymity.
    784 == Using multiple aos-Workstations ==
    785 === Introduction ===
    786 For tasks where you want to use additional software you should use a second (or third) VM, you can make a clone. Consider this more of a pseudonymous than an anonymous environment and act accordingly.
    788 Multiple aos-Workstation VM's isolate different torified clients from each other. For example, an exploit in the browser can not read your IRC identity in another VM. However, keep in mind, if Tor inside the aos-Gateway or your host internet connection goes offline, all aos-Workstations will go offline, and if you were simultaneously using something, an attacker could guess, that you are the same person (i.e. two Tor users in one IRC channel go offline at the same moment).
    790 The most safe thing to do is using only one aos-Workstation for one activity at the same time.
    792 Leaving multiple aos-Workstations running at the same time introduces also new risks. One compromised aos-Workstation can perform various attacks. It's impossible to defeat all those attacks. Depending on the adversary's skills and assumptions and your activity in other aos-Workstations, he could correlate various running aos-Workstations to the same pseudonym.
    793  * An adversary could stress either/and CPU, HDD, RAM, network connection and other aos-Workstations and perhaps also the host would suffer.
    794  * There is no defense against DOSing other aos-Workstations or the aos-Gateway.
    795  * The adversary could try to exploit other aos-Workstations or the aos-Gateway. This risk can be reduced by hardening. aos-Workstation provides an optional (disabled by default, because it can get into the way for other tasks) firewall (under "/usr/local/bin/aos_firewall") to isolate different aos-Workstations from each other.
    796  * A defense against impersonating (i.e. MITM or malicious gateway) other aos-Workstations or the aos-Gateway can be implemented using authentication, this is outlined below.
    798 === How to use more than one aos-Workstation ===
    799 The setup for a second or any additional aos-Workstation is does only differ in one detail. You can simply clone a clean aos-Workstation. The minimal difference: It needs ^1^  its own fixed IP address. If you want to run multiple aos-Workstations at the same time, you should read "Connections between aos-Gateway and aos-Workstation" below.
    801 1. Open /etc/network/interfaces.
    802 {{{
    803 nano /etc/network/interfaces
    804 }}}
    806 2. And change the last octet. E.g. 192.168.0.'''3''' or 192.168.0.'''4'''.
    808 3. Reboot or restart network using
    809 {{{
    810 /etc/init.d/networking restart
    811 }}}
    813 4. Done.
    815 ,,^1^ It only needs its own fixed IP address, if you want to run multiple aos-Workstations at the same time. Give it it's own fixed IP address anyway, because that will stream isolate their Trans-, Dns- and SocksPorts, which is highly recommend.
    817 = Connection between aos-Gateway and aos-Workstation =
    818 == Introduction ==
    819 By aos default, it is assumed, that aos-Gateway and aos-Workstation are connected by (virtual) LAN cable. Wireless technologies are recommend against, because a malware compromised aos-Workstation could jump to other wireless access point and subsequently connect without Tor. Using a (virtual) cable enforces, that aos-Workstation can only connect through aos-Gateway. For the same reason connections to aos-Gateway over internet are recommend against as well.
    821 By aos default, connections between aos-Workstation and aos-Gateway are not authenticated/encrypted. This is because of the assumption above. The connection between aos-Workstation and aos-Gateway is assumed to be secure. ^1^ Adding authentication/encryption by default would also greatly increase complexity of aos, which is what we want to avoid in the first place for reasons explained in earlier chapters.
    823 In case you want to run multiple aos-Workstations at the same time inside the same (virtual) isolated LAN or in case you want to connect to aos-Gateway over insecure networks (internet), you should add encryption and authentication.
    825 ,,^1^ Secure means, you assume that no one on your (virtual) LAN is going to MITM.
    827 == Secure connections between aos-Gateway and aos-Workstation ==
    828 Only applies if you run multiple aos-Workstations at the same time or if you want to connect to aos-Workstation over insecure networks (internet): [[BR]]
    829 A compromised aos-Workstation can impersonate aos-Gateway, perform active MITM attacks or passively eavesdrop. To mitigate that, you need to set up authenticated and encrypted connections.
    831 Adding encryption can be done using OpenVPN or SSH. Using SSH and not OpenVPN, has the advantage, that you an later, still easily tunnel a VPN through Tor. If you don't plan to do this, using OpenVPN is probable easier. The disadvantage of using SSH is, that it's complicated to setup for this use case. You are probable better off using OpenVPN.
    833 === Using additional (isolated) network interfaces ===
    834 A workaround, when using Virtual Box and running everything on the same host: [[BR]]
    835 One can also enable Virtual Network Adapter 3 and 4 and use uniquely named internal networks, for up to 3 aos-Workstations, which are isolated against each other.
    837 A workaround, for aos with Physical Isolation, where all machines in the same trusted place: [[BR]]
    838 That aos-Gateway already requires two network interfaces is a though requirement. (External and internal interface.) You could theoretically also add additional interfaces for additional internal LAN interfaces.
    840 === Using SSH [not tested/recommend] ===
    841 You must not allow [ ssh login].
    843 Each aos-Workstation probable needs its own SSH account, with public key authentication and the SSH private key distributed to each T-W. aos-Gateway and all aos-Workstations need the correct SSH commands. aos-Gateway has to autostart SSH and to continuously listening for connections. And aos-Workstation has to autostart SSH as well and continuously reconnect (in case aos-Workstation started before aos-Gateway or aos-Gateway restarted) (perhaps using autossh or something similar). All aos-Workstations need to use the tunnel IP, to connect to the aos-Gateway. And the aos-Gateway should reject unencrypted gateway requests, and only accept forwarding to Tor over the SSH tunnel. And also answer only over the SSH tunnel. All aos-Workstations must use the SSH tunnel as gateway (redirect network level to socks using tranSOCKS_ev or similar). Perhaps also changes in the aos-Gateway firewall are required. Taking all the into account, it looks like, it's not impossible to use SSH for this task, but it's quite complicated.
    845 You are probable better off using OpenVPN.
    847 === Using OpenVPN ===
    850 Right now only supports two modes/security domains:
    851  * aos-Workstations with the secret key (=trusted) and
    852  * other workstation with no key/vpn configured.
    854 NOTE:
    855  * Transparent proxying doesn't seem to work at all, therefore you need to configure all applications to use socks ports (use [ uwt] for apt-get).
    857 On the gateway:
    858 {{{
    859 sudo -i
    860 apt-get -y install openvpn
    862 # create a new symmetric key
    863 sudo -u user openvpn --genkey --secret /home/user/static.key
    865 # copy key to workstation (Firewall needs to be disabled and openssh-server installed on aos-Workstation for this to work)
    866 sudo -u user scp /home/user/static.key user@
    868 mv /home/user/static.key /etc/openvpn/static.key
    869 chown root:root /etc/openvpn/static.key
    870 chmod 700 /etc/openvpn/static.key
    872 # create server configuration
    873 echo "
    874 user nobody
    875 group nogroup
    876 daemon
    877 dev tun
    878 ifconfig
    879 secret /etc/openvpn/static.key" > /etc/openvpn/server.conf
    881 service openvpn restart
    883 # Edit torrc
    884 # TODO: only selectively change listening addresses. TransPort and optionally other SocksPorts have to remain available,
    885 #       if unauthenticated workstations are to be used.
    886 # NOTE: we are using a hardcoded default IP here, if you are using non standard settings this will have to be edited.
    887 ed -s /etc/tor/torrc <<< $',s/\nw'
    889 # Edit /etc/
    890 # TODO: Put this automatically where it actually belongs
    891 echo '
    892 # Allow openvpn in on port 1194
    893 iptables -A INPUT -i $INT_IF -p udp --dport 1194 -j ACCEPT' >> /etc/
    894 # TODO: replace hardcoded "eth1" with a wildcard
    895 ed -s /etc/<<< $',s/INT_TIF=eth1/INT_TIF=tun0/g\nw'
    897 /etc/
    898 }}}
    900 On the Workstation(s):
    902 TODO: Disable/tweak the new firewall
    903 {{{
    904 sudo -i
    906 mv /home/user/static.key /etc/openvpn/static.key
    907 chown root:root /etc/openvpn/static.key
    908 chmod 700 /etc/openvpn/static.key
    910 # should be in the default installation
    911 apt-get --yes install --no-install-recommends torsocks
    913 echo "
    914 user nobody
    915 group nogroup
    916 daemon
    917 remote
    918 dev tun
    919 ifconfig
    920 secret /etc/openvpn/static.key" > /etc/openvpn/server.conf
    922 # Edit resolv.conf
    923 chattr -i /etc/resolv.conf
    924 echo "nameserver" > /etc/resolv.conf
    925 chattr +i /etc/resolv.conf
    926 }}}
    928 = aos's Secure And Distributed Time Synchronization Mechanism =
    929 For understanding aos's Secure And Distributed Time Synchronization Mechanism, it is required to know Virtual Box's time synchronization features:
    930  * Virtual Box uses the hosts time if it needs to correct the time for guests.
    931  * (Some of Virtual Box time synchronization features depend on guest additions.)
    932  * By default Virtual Box corrects Virtual Machine guests virtual hardware system clock,
    933   * when the they get powered on,
    934   * when they resume from suspension and
    935   * when their clock is more then X minutes off.
    937 Facts: [[BR]]
    938 People have been using:
    939  * the Tor Browser Bundle and Mozilla Firefox in parallel
    940  * Tails inside VMs and Firefox on the host
    941  * Tor Browser inside aos-Workstation and Mozilla Firefox on the host
    943 Other facts:
    944  * Almost no one and no operating system, is using Secure Network Time Synchronization or External Clocks by default. Most systems synchronize the system clock using unauthenticated NTP. An adversary tampering with NTP replies or malicious NTP server makes things even worse. Even if there were authenticated NTP there is a requirement for a distributed trust model.
    945  * A system not using NTP or using authenticated NTP stands out form most other users.
    947 Attacks [[BR]]
    948 A correct system clock is crucial for many reasons:
    949  * Attack (1) Replay attacks ^1^
    950  * Attack (2) Feeding old/outdated/known vulnerable updates and (https) certificates ^2^
    951  * Attack (3) deanonymizing ^3^
    952  * Attack (4) Linking all sessions to the same pseudonym ^4^
    953  * Attack (5) Locating hidden services. ^5^
    955 ,,^1^ Replay old Tor consensus, see [ Tails: Time syncing] for detailed explanation. [[BR]]
    956 ,,^2^ Cryptographic verification depends on system clock, i.e. a clock two years in past will accept certificates/updates, which have been expired/revoked for two years. [[BR]]
    957 ,,^3^ Javascript is enabled in Tor Button by default and javascript can be used to read the client's clock, see for demonstration. Also other applications do leak the client's clock, such as Thunderbird (patch has been proposed by TorBirdy developers) and https. Image the user connects to an adversary controlled webserver with Mozilla Firefox and connects to another adversary controlled websever with Tor Browser. As long as TBB upstream bug #3059 is open, the adversary can link the anonymous and non-anonymous session, thus deanonymizing. [[BR]]
    958 ,,^4^ If the clock is too much off, it's also easy for an adversary's webserver to detect "Oh, that's the Tor Browser user who's clock is X in past/future.", thus allowing the adversary to link all sessions to the same pseudonym. [[BR]]
    959 ,,^5^ For hidden services a correct clock is curial, see [ Hot or Not: Revealing Hidden Services by their Clock Skew]; [ An improved clock-skew measurement technique for revealing hidden services]; [ SkewMask: Frustrating Clock Skew Fingerprinting Attempts] [[BR]]
    961 aos's Secure Distributed Time Synchronization mechanism:
    962  * Aos 0.3.0 and above leave the host's system clock or time synchronization mechanism untouched.
    963  * Aos-Gateway and aos-Workstation are based on Virtual Box and therefore have their own virtual hardware system clocks.
    964  * Most Virtual Box time synchronization features get disabled by aos.
    965   * Guest additions time synchronization gets disabled in '/etc/init.d/htpdate' at run time and
    966   * built in time synchronization features get disabled by '"VBoxManage setextradata "$VMNAME" "VBoxInternal/Devices/VMMDev/0/Config/GetHostTimeDisabled" "1"' at build time.
    967  * When aos-Gateway or aos-Workstation get powered on, they still get their time from the host, but the user is advised to modify the biossystemtimeoffset. ^6^
    968  * After aos-Gateway and aos-Workstation are connected to the Tor network, they use a modified [ tails_htp]. ^7^
    969  * That will reach the design goal, that all clocks, the host's, aos-Gateway's and aos-Workstation's slightly differ.
    970  * Thus,
    971    * Attack (1) is a general Tor problem. It is impossible to solve for aos. It is unsolved in other projects as well.
    972    * Attack (2) gets partially defeated. Aos-Gateway and aos-Workstation are immune. The host is still at risk. This is general problem with all operating systems. See [ Ubuntu Brainstorm Idea #30050: Secure Network Time Synchronization]. This problem is unsolved in other projects as well. Manual workaround: Check your clock manually and read [ About Ubuntu] (stale mirror attack).
    973    * Attack (3) gets defeated, aos adds additional security.
    974    * Attack (4) gets defeated, aos adds additional security.
    975    * Attack (5) is a general Tor problem, which can not be solved by aos and which is unsolved in other projects as well.
    977 When the user powers on aos-Gateway and the host time is too much off, it will not be able to connect to the Tor network. It is advised, when powering on aos-Gateway, to check that the host time is no more then 1 hour in past or 3 hour in future. ^8^ An adversary tampering with the users clock while the user doesn't recognize can't do any more damage to aos than he could do the the Tor Browser Bundle. All that happens is a denial of service. On the other hand, an adversary capable of actively tampering with the traffic between the user and it's entry guard or bridge poses much bigger risks to Tor in general. ^9^
    979 ,,^6^ Developer information: If we needed or wanted to render the hardware clock unusable, we could set Virtual Box '--biossystemtimeoffset' several decades in past or future. [[BR]]
    980 ,,^7^ Stream isolation has been added by [ aos's tails_htp implementation], i.e. people using Tor Browser prevent notifying their exit node, that they are tails_htp or aos users. [[BR]]
    981 ,,^8^ [ source of information] [[BR]]
    982 ,,^9^ General Tor problems, Tor is known to be broken against many active attacks. This can not be solved by aos. When an adversary is capable of running active attacks, tampering with the time leading into a denial of service is the least of the worries. The adversary could also disrupt the service easier. And as for active attacking in general, there are other attacks which are easier to deploy and which pose a greater danger. Not a aos specific problems. [[BR]]
    984 == Readme ==
    985 TODO: [[BR]]
    986 Move to readme for aos 0.3.0 and above.
    988 0.2.1 and below users: restore NTP...
    990 Virtual Box has a feature to spoof the initial virtual hardware clock offset by setting the clock X milliseconds in feature or past.
    991 Syntax:
    992 {{{
    993 VBoxManage modifyvm <name> --biossystemtimeoffset -<milliseconds>
    994 VBoxManage modifyvm <name> --biossystemtimeoffset +<milliseconds>
    995 }}}
    997 It's prudent to add a random delay within the following range.
    998 {{{
    999 VBoxManage modifyvm <name> --biossystemtimeoffset -60000
    1000 VBoxManage modifyvm <name> --biossystemtimeoffset +60000
    1001 }}}
    1003 Pick one example per VM and use random values within the range. (On the host.)
    1004 {{{
    1005 VBoxManage modifyvm "aos-Gateway" --biossystemtimeoffset -35017
    1006 VBoxManage modifyvm "aos-Gateway" --biossystemtimeoffset +27931
    1007 VBoxManage modifyvm "aos-Workstation" --biossystemtimeoffset -35017
    1008 VBoxManage modifyvm "aos-Workstation" --biossystemtimeoffset +27931
    1009 }}}
    1011 Summary:
    1012  * Run Secure Network Time Synchronization after suspend and resume or do not use suspend/resume at all.
    1013  * Modify --biossystemtimeoffset for all Virtual Machines.
    1015 == External Clock ==
    1016 This topic is still under research.
    1018 It might make sense to add an external clock, such as a GPS, or even better an atomic clock. (Can we get an atomic USB clock?) This clock should be added to the host and/or aos-Gateway and/or aos-Workstation.
    1020 Open question: would the GPS/atomic clock be too accurate and would that make aos fingerprintable?
    1022 = DISCLAIMER =
    1023 See [ DISCLAIMER]
    1025 = aos does not (yet)... =
    1026 aos is currently alpha quality software and missing features, some of them security related. Some of the following will probably never get "fixed" or implemented because they are impossible to do in a software only project.
    1028 aos in its current form does not:
    1029  * Encrypt your stuff.
    1030  * Wipe RAM on shut down.
    1031  * Wipe video RAM on shut down.
    1032  * Make weak passwords stronger.
    1033  * Protect against local adversaries, who for example can mount cold boot and evil maid attacks.
    1034  * Will be solved in next version 0.3.0 and above: Automatically protect against time skew attacks (you need to set and check the time of all aos systems manually!).
    1035  * Protect you if you don't [ read] our documentation or do stupid things or change default settings without knowing what you are doing.
    1036  * Automatically apply security updates. This was a conscious decision because automated updates also come with their own set of security problems.
    1037  * Automatically isolate different identities and pseudonyms from each other, you should use [ multiple aos-Workstations]
    1038  * Protect against global network adversaries.
    1039  * Protect against hardware or software backdoors.
    1040  * Automatically protect against MAC address fingerprinting on public networks.
    1041  * Protect against the more skilled software attack, unless you use Physical Isolation.
    1042  * By default, protect you if Tor is somehow broken. You can improve that to some extend and with caveats by chaining Tor with SSH, proxies or VPNs.
    1043  * By default, hide the fact that you are using Tor, though there is an optional feature, [ Hide your Tor usage].
    1044  * Use all the possible hardening options like full PIE and grsecurity. It doesn't use AppArmor profiles for everything.
    1045  * Have [ deterministic builds]. Also Tor itself does not have [ deterministic builds] yet.
    1046  * This list might be incomplete. Please read the rest of this page to get an overview about security, what's in and what not.
    1048 If you want to help us improve the security of aos, please join the discussions on [ aos/Dev] or expand this site.
    1050 = aos² =
    1051 That's just a code name for a *BOX setup "2.0" that may eventually offer strong guarantees of security and anonymity.
    1053 It should address all the current single points of failure:
    1055  * '''CPU:''' Even in a microkernel + IOMMU system the CPU (and to some extend the GPU, this ) needs to be trusted blindly. The system needs to consists of multiple (diverse) CPUs. aos with Physical Isolation already does that. This is just an reminder that software based isolation (through next gen sandboxing and microkernel design) will never be able to replace hardware isolation.
    1057  * '''Software/Compiler''' Even if the TCB is small and verifiable to some extent there is an inherently unsolvable problem: Compilers ("trusting trust"). The only option to improve this I see is to rely on a diverse "polyculture" of software stacks and infrastructure instead of our current Windows and gcc monocultures. (I suppose most .mil and all research microkernels are written on monolithic untrusted "legacy" systems). Alternatives do exist (most likely built with gcc...) but probably not mature enough, though I hear OpenBSD kernel can be built with pcc. clang/LLVM is probably the best bet. This also extends to the build system, workstations and gateways should be built on their respective target platforms, not a single build system.
    1059  * '''Software updates:''' Currently, one single bad update from Ubuntu and it's game over. Software updates are always a root "backdoor", they grant unknown people full remote access to all your systems. This needs to be changed. If the TCB is small and well tested there won't be many security updates and they will be simple, small patches. Deterministic binary builds could make that userfriendly. At least we should not rely on a single organization to provide security updates for all systems in aos (this includes having the same upstream for complicated software, i.e. the Linux kernel...).
    1061  * '''Tor:''' Currently, one serious Tor vulnerability and it's game over. Even with true end-to-end communications, if Tor (or its TCB) is subverted an adversary can find out who is talking and to whom one is talking. aos should route all traffic over at least two strong anonymity networks (not just single hop proxy/VPN/SSH). Further, there should be the option to use a high latency network. This could be as simple as a single hidden service (which would have to be fully trusted to not collude with our "global adversary". A real solution would of course have to be decentralized. The only options so far are remailers (Mixminion...) but those have few users (poor anonymity set) which is probably related to their outdated user interface and experience. However, even with a small number of users, if remailers are routed through Tor they are still more secure than Tor (in this context the resulting anonymity is cumulative).
    1063  * ''' "Protocol leaks", Anonymity set reduction:'''  The current platform of choice (for pretty much everything, including anonymous communication) is the web browser. Browser really suck when it comes to privacy, anonymity or security. Allowing scripting, storing IDs (cookies and more), constantly changing features (html5, webgl, websockets...), [ lack] of strong crypto environment make the web browser one of the worst platforms imaginable for strong anonymity (or security). Why? Because we also lack a credible alternative. One such alternative could have been the now dead or in limbo [ Syndie] ("Syndie's design as an anonymity-sensitive client application carefully avoids the intricate data sensitivity problems that nearly every application not built with anonymity in mind does not.")
    1065 In summary: aos² needs to consist of at least two very diverse systems, different hardware manufacturers, different kernels, different companies/orgs providing support and offer at least two different anonymizing networks. Bonus points for utilizing diverse crypto systems and cascades. Neither system should "know" both who is communicating and with whom.
    1067 = Build Anonymity =
    1068 This does only apply, if you are going to build aos from source, and/or if you are going to redistribute aos and/or if you are going to use Physical Isolation. This is not a aos specific problem. Most projects do not even have a chapter about build anonymity. While building aos, software has to be downloaded. It's a unique selection of software and there is no way to make it not unique. Therefore your ''i''nternet ''s''ervice ''p''rovider (ISP) could guess, that you are building aos. This should not be of any concern in a free country (free by your own definition), if the content of your traffic is not being observed or logged.
    1070 Especially, but not exclusively, in case you want to redistribute aos, you might be interested to hide the fact, you are building aos (i.e. you want to stay anonymous). Therefore we are working on support to build aos over Tor.
    1072 To prevent any kind of personally identifiable or even fingerprintable information leaking from the build system into the aos images, it is recommended to build inside of an already torified Virtual Machine. ^1^ You can build aos inside an existing aos-Workstation, but it can also be built on a headless server and while it is possible to run VirtualBox inside VirtualBox, the part requiring VirtualBox can most likely safely be run on your host, outside of the VM (creating the VM setting and converting the image otherwise doesn't touch the built systems). Using ''vboxmanage "aos-Workstation" modifyvm --acpi on'' and ''vboxmanage "aos-Workstation" modifyvm --ioapic on'' for all VM's, i.e. for the build_aos-Workstation and the ones you build, speeds up the VM inside the VM a lot. That is already the default for aos Virtual Machines since version 0.2.0.
    1074 It's also recommend to build in an already torified Virtual Machine, because that prevents leaks from the build system, which could help an attacker (with root access to the aos-Workstation), to gather identifiable information about that build system, that could ultimately lead back to your identity.
    1076 It's also possible to build directly on the host and torify all connections the scripts make, but we don't know what other leaks there may be possible (e.g. hostname, dhcp, resolv.conf...).
    1078 We know it's not the best solution to run a VM inside a VM. Virtual Box inside Virtual Box works, but if we change to another virtualization platform later, that may be no longer possible.
    1080 ^1^ Yes, this creates a bootstrap, chicken or egg problem. To solve it you can either download already existing aos binary builds or if you prefer to build form source, build a minimal torified machine yourself first while running any network traffic over Tor. Any help required with that? Contact us.
    1082 = Further hints and readings =
    1083 There are [ a few threads] on the Tor Talk Mailing List about the security of aos / transparent proxy. "[tor-talk] Operating system updates / software installation behind Tor Transparent Proxy"; "[tor-talk] Obtain real IP behind Tor transparent proxy; was: Operating system updates / software installation behind Tor Transparent Proxy"; "[tor-talk] Risk with transparent proxy mode [was Re:Operating system updates / software installation behind Tor Transparent Proxy]" - Everything fine so far.
    1085 This page, 'Application Warnings And Notes' explains a lot security related things you should be aware of. Also see the whole page [ Security And Hardening] for tips how to improve the security. [ aos-Workstation is firewalled] also explains #OptionalFeatureNr.3# (Even more restrictive firewall rules.).
    1087 == Application specific warnings and hardening instructions ==
    1088 [ aos/ApplicationWarningsAndNotes]
    1090 == Trusting aos ==
    1091 [ aos/Trust]
    1093 == anonymous 3G modem ==
    1094 Improves anonymity. See [ anonymous 3G modem].
    1096 == anonymous wifi adapter ==
    1097 Improves anonymity. See [ anonymous wifi adapter].
    1099 == Leak Testing ==
    1100 In your own interest, you should do the additional [ aos/LeakTests], to check everything is properly set up.
    1102 == Other projects similar pages ==
    1103  * [ Tails's warnings]; some things apply to aos as well