wiki:doc/TorBOX/Dev

Version 1446 (modified by proper, 5 years ago) (diff)

UWT issues

Whonix Homepage

  1. What This Is About
    1. Archive
  2. OPEN CRITICAL TASKS
  3. OPEN ENHANCEMENT AND LESS CRITICAL TASKS
    1. [BUG] [USABILITY] Clock does not show local time
    2. [Feature] Multi Language Support / Tails Greeter
    3. [PACKAGEING] FlashProxy bridges
    4. datefudge
    5. wprivoxy
    6. [DOCUMENTATION] various topics
    7. [SOURCE CODE] Tor Browser startup script upstream patches
    8. [USABILITY] [SECURITY] kubuntu-low-fat-settings
    9. [SECURITY] Whonix Internal Updater
    10. [SOURCE CODE] [PACKAGING] UWT merge into torsocks or get into Debian
    11. [BUG] UWT issues
    12. [SOURCE CODE] no longer hardcode user folder
    13. [SECURITY] secure, censor resistant, distributed project metadata
    14. [SECURITY] Better Blog
    15. [SECURITY] First Time Connection Wizard
    16. [SECURITY] Usability Improvements
    17. [FEATURE] [PACKAGING] Icedove (Debian version of Mozilla Thunderbird) …
    18. [SOURCE CODE] [PACKAGING] get tails_htp into Debian
    19. [SECURITY] TorChat .deb
    20. [FEATURE] TorChat Pidgin Plugin
    21. [FEATURE] Whonix (USB) installer
    22. [OPTIONAL FEATURE] Whonix host additions
    23. [SECURITY] Pin check.torproject.org and torproject.org SSL certificates
    24. [SECURITY] Pin check.torproject.org and torproject.org CA SSL certificates
    25. [FEATURE] Vidalia by default/Graphical Gateway [OPEN]
    26. [SECURITY] MAC address in public networks [OPEN]
    27. [SECURITY] Encryption/Authentication between T-G/T-W [OPEN]
    28. [OPTIONALFEATURE] Multiple Gateways [OPEN]
    29. [SECURITY] Deterministic builds [OPEN]
    30. [OPTIONALFEATURE] Freenet Support/"FreenetBOX" [NEEDS INFORMATION]
    31. [OPTIONALFEATURE] I2P Support [WAIT/LOOKING for contributors/more …
    32. [OPTIONALFEATURE] Portable VirtualBox (like portableapps.com) [LOOKING …
    33. [SECURITY] Research: IP discovery through Tor Proxy [LOOKING FOR …
    34. [OPTIONALFEATURE] Proxies as Tor replacement/"ProxyBOX" [WAIT for …
    35. [OPTIONALFEATURE] VPNs as Tor replacement/"VPNBOX" [WAIT FOR FEATURE: …
    36. [OPTIONALFEATURE] Read Only/Portable/Live System [LOOKING FOR CONTRIBUTOR]
    37. [SECURITY] VirtualBox replacement: Xen, KVM, libvirt [OPEN]
    38. [SECURITY] Wipe RAM panic script [OPEN]
  4. CLOSED TASKS
    1. More closed tickets…
    2. [SECURITY] flashplugin-nonfree get-upstream-version.pl security …
    3. [SECURITY] [PACKAGING] Empty Tor Package [DONE]
    4. remove wpolipo [DONE]
    5. [SECURITY] Include rawdog to fetch Whonix News (Blogs) [IMPLEMENTED]
    6. [INFRASTRUCTURE] Our bug tracking system [WEBSITE] [ANSWERED]
    7. [SHELLSCRIPTS] Move to file separated source [INFRASTRUCTURE] [DONE]
    8. [FEATURE] Feedback collector [ANSWERED]
    9. [BUG] uwt wrapper localhost connections broken [FIXED]
    10. [BUG] [SHELLSCRIPTS] default color profile for gnome-terminal [FIXED
    11. [SECURITY] [ENHANCEMENT] Switching Operating System [DONE]
    12. [SHELLSCRIPTS] Ubuntu unattended (automatic) installation debootstrap …
    13. [SECURITY] Setting correct time (NTP/HTP) [DONE]
    14. [INFRASTRUCTURE] Whonix 1.0 website [DONE]
    15. [SECURITY] Evaluate *BSD as a replacement for either t-w or t-g [DONE]
    16. [LOW SEVERITY] [FINGERPRINTING] /dev/disk/by-id unique ids [FIXED]
  5. Related Tickets
    1. Tor
    2. Vidalia
    3. obfsproxy
    4. Analysis
    5. TorIM
    6. Infrastructure
    7. GPG
    8. Ubuntu
    9. Debian / Ubuntu
    10. Debian
    11. Tor Browser
    12. torsocks
    13. Tor Check
    14. TorBirdy
    15. Virtual Box
    16. Arm
    17. KDE
  6. wiki editing
  7. Similar Projects
  8. people talking about Whonix
  9. Our Shell scripts and Build Documentation
  10. Questions

What This Is About

This site is for proposing and discussing (new) features or simply to ask questions relating to set up, usage and security of Whonix. Please do not delete comments. You are free to discuss anything. Feel free to reopen discussions, if you have points to add. Always add your opinion if you think something important has to be said, no matter how old the thread is. Different opinion can remain available forever on the /Dev pages. Sometimes a feature request is rejected because it makes no sense, is impossible or whatsoever. Because someone else in future might come up with the same idea, it's nice to have it already discussed.

Please tag each discussion and move completed tasks to the bottom.

Terminology:

  • Whonix W - WW - Whonix-Workstation
  • Whonix-G - WG - Whonix-Gateway
  • tpo - torproject.org
  • RP Raspberry Pi

Related Tickets in the Tor core affecting Whonix.

Archive

Closed discussions are archived.

Feel free to reopen, copy back here then.

OPEN CRITICAL TASKS

Issues that directly affect the security, privacy and anonymity Whonix users with default settings go here.

OPEN ENHANCEMENT AND LESS CRITICAL TASKS

[BUG] [USABILITY] Clock does not show local time

  • (adrelanos) People are confused with the clock being set to UTC. Tails and Liberte Linux also haven't solved this issue. We have to set local time to UTC, because some applications leak it. Can we somehow patch the clock to show a local time zone while leaving local time in UTC?
  • (adrelanos) It might be possible to configure the clock in the kde task bar. Time zone in kde clock can be changed without root rights and without affecting /etc/localtime, thus the user can have it's clock show what he wants. It looks like this is either configured in /home/user/.kde/share/config/plasma-desktop-appletsrc and/or /home/user/.kde/share/config/ktimezonedrc.
  • (adrelanos) To add this, first some kind of Whonix Greeter is required. See ticket Multi Language Support / Tails Greeter.

[Feature] Multi Language Support / Tails Greeter

  • (adrelanos) Can we fork Tails Greeter so the user can choose which language packages to install once Whonix-Workstation has been imported?

[PACKAGEING] FlashProxy bridges

  • (adrelanos) A user asked how to use Whonix with Flash Proxy. Waiting for feedback on #8092: make a deb of flashproxy and get into Debian.
  • (adrelanos) No one working on it. Waiting for contributor.

datefudge

  • (adrelanos) Should we add datefudge? I think adding the package can't hurt. It doesn't do anything when not in use.
  • (adrelanos) Should we add some wrappers? Or at least document it? For example for git or gpg? Example:
datefudge "2013-01-01 10:23" gpg --clearsign testfile
gpg --verify testfile.asc 
gpg: Signature made Tue Jan  1 10:23:00 2013 UTC using RSA key ID 713AAEEF
gpg: Good signature from "adrelanos <adrelanos at riseup dot net>"
  • (adrelanos) It could add some privacy to when commits / gpg signing has been done.
  • (adrelanos) If we don't wish use the example form the man page "datefudge "2007-04-01 10:23" command", we could also set the time to something less accurate.

wprivoxy

  • (adrelanos) Perhaps create wprivoxy? Similar to wpolipo?

[DOCUMENTATION] various topics

[SOURCE CODE] Tor Browser startup script upstream patches

  • better comments + no apostrophes: #7266
  • obeying TB_STANDALONE=1 (set in /etc/environment by anonymity distribution) by only starting Tor Browser, not Vidalia
  • Maybe add UILocale functionality?
  • add -new-link functionality
  • add -no-remote functionality

[USABILITY] [SECURITY] kubuntu-low-fat-settings

  • (adrelanos) Get kubuntu-low-fat-settings into Debian. UPDATE: or not. It's not easy to get it into Debian and would also require to change how it add itself to kde paths.
  • (adrelanos) I have a git branch kdelowfat where we simply add those configuration enhancements to /usr/local/share/whonix/kde/. Still need to figure out which settings should be applied to Whonix. See https://sourceforge.net/p/whonix/wiki/Dev_KDE/

[SECURITY] Whonix Internal Updater

  • (adrelanos) Updating Whonix from user perspective is still a mess.
    • (adrelanos) They need to somehow backup their data, download huge images, delete the old images, import new images, get operating system updates, releases are infrequent...
    • (adrelanos) If the torbrowser script breaks or they update they signing keys, manual instructions have to be provided as a hotfix, which involves terminal commands.
  • (adrelanos) The updater should contain two branches, stable and development.
  • (adrelanos) By the way, projects such as Whonix hosted on sourceforge.net are allowed to host an apt repository as long it's hosted in the file release system. (For example sonar has one.])
  • (adrelanos) How? a) Either Whonix must come closer to Debian, i.e. convert all Whonix configuration files into .deb packages and then host a repository on sourceforge. After installing Debian in a virtual machine users could even add the Whonix repository and run "apt-get install whonix-gateway" and get all the files they require. Disadvantage: porting Whonix to other operating systems becomes much more difficult.
  • (adrelanos) b) A wrapper around git. The Whonix News File could include the latest recommend versions (testing and experimental). The git wrapper would checkout that version and overwrite all configuration files, which are changes in Whonix source. Difficulty: what if configuration files get deleted/moved or packages get removed? The developers would have to carefully add the required commands to it.
  • (adrelanos) dpkg-maintscript-helper may be useful for deleting or renaming configuration files if we decide to go the .deb way.

[SOURCE CODE] [PACKAGING] UWT merge into torsocks or get into Debian

  • (adrelanos) Depending on #8053 "add stream isolation support to torsocks) uwt becomes redundant or should be packaged for Debian.

[BUG] UWT issues

  • (adrelanos) "sudo chmod -x /usr/local/bin/curl" is required, (i.e. deactivating the uwt Steam Isolation wrapper)
    • (adrelanos) before "apt-file update" runs successfully.
    • (adrelanos) before running "sudo apt-get install flashplugin-nonfree" runs successfully.
    • (adrelanos) before running "update-command-not-found".
  • (adrelanos) It's probable the same root cause.
  • (adrelanos) Fortunately there is progress in #8053: "add stream isolation support to torsocks".

[SOURCE CODE] no longer hardcode user folder

  • (adrelanos) Currently Whonix build scripts assume to be build as user "user" and the Whonix source code being in /home/user/Whonix. This should no longer be hardcoded.

[SECURITY] secure, censor resistant, distributed project metadata

[SECURITY] Better Blog

  • (adrelanos) Next Whonix version should include a way to keep users informed about latest Whonix news. Therefore at least an SSL version for unregistered users is required.
  • (adrelanos) Whonix Important Blog and Feature Blog can only be viewed over SSL for people logged into sourceforge.net. Related Whonix Stay Tuned documentation.
  • (adrelanos) Find or host a free blog with rss or atom support, SSL support or as a hidden service.
  • (adrelanos) The blog service must tolerate the topic "Whonix" and be reliable.
  • (adrelanos) sf.net blog supports fetching RSS/Atom feed URL from external feeds, so sf.net community team remains happy and continues with occasionally promotion stuff (they tweeted Whonix etc.).
  • (adrelanos) A blog without advertisements should be preferred, if possible.
  • (adrelanos) wordpress.com: whonix.wordpress.com is "already account taken" but the domain says "authors deleted the blog". No support for free accounts. What a shame, otherwise wordpress.com could have been an acceptable choice. - Correction: looks like there is staff support in the forum.
  • (adrelanos) https://anonymousoperatingsystem.wordpress.com/ (old, registered long time ago when Whonix was still called aos) has proper SSL. https://anonymousoperatingsystem.wordpress.com/feed/ itself has no proper SSL. But "/usr/bin/curl --tlsv1 --proto =https https://anonymousoperatingsystem.wordpress.com/feed/" works.

[SECURITY] First Time Connection Wizard

  • (adrelanos) Related to: #7197 "Adapt Tor installer to allow users to avoid connecting to the public tor network"
  • (adrelanos) Related to: #2905 "Adapt Vidalia UI to allow users to avoid connecting to the public tor network"
  • (adrelanos) When Whonix-Gateway starts for the first time, it should offer the following choices:
    • Connect to the public Tor network (like Whonix 0.4.5)
    • use (private) (obfuscated) bridges (textual feature)
    • hide your Whonix usage (textual feature)
    • hide your Tor usage (textual feature)
  • (adrelanos) Dialog (or similar) could be used to implement this as a console version.
  • (adrelanos) DisableNetwork 0 from the Tor Manual could probable be used.
DisableNetwork 0|1 

When this option is set, we don’t listen for or accept any connections other than controller connections,
and we don’t make any outbound connections. Controllers sometimes use this option to avoid using the
network until Tor is fully configured. (Default: 0) 

[SECURITY] Usability Improvements

[FEATURE] [PACKAGING] Icedove (Debian version of Mozilla Thunderbird) + TorBirdy

[SOURCE CODE] [PACKAGING] get tails_htp into Debian

  • (adrelanos) Whonix's Secure And Distributed Time Synchronization Mechanism depends on [http://sourceforge.net/p/whonix/wiki/Dev_timesync/ tails_htp). Let's get it into Debian.
  • create an upstream github repository
    • done
  • add patch, perhaps option to deactivates Virtual Box guest additions time sync (the few lines of code are already in Whonix)
  • add patch, to run htpdate every hour at a random minute for continued time synchronization
  • add patch, to use /usr/bin/curl instead of curl to circumvent uwt wrapper, because htpdate uses socks settings.
  • make sure it could work in plain Debian without Tor, with Tor, in Tails and in Whonix
  • talk about it with the Tails developers
  • give the Tails developers git write access
  • create a .deb
  • get the .deb into Debian
  • (adrelanos) Created a repository: https://github.com/adrelanos/sdwdate

[SECURITY] TorChat .deb

  • http://packages.debian.org/wheezy/torchat
  • http://packages.debian.org/sid/torchat
  • (adrelanos) patch TorChat upstream so it supports Tor on external machines (if some configuration option is set) - there is a patch on github already - not checked if it's related
  • (adrelanos) patch TorChat upstream so it supports environment variables
  • (adrelanos) patch TorChat upstream so it supports blocking and/or multiple instances
  • (adrelanos) if the patches won't get accepted upstream in TorChat, fork TorChat on github and in meanwhile add the patches there
  • (adrelanos) polish the .deb so it gets accepted into Debian
  • (adrelanos) Whonix users can now use the .deb either form github or even Debian repository

[FEATURE] TorChat Pidgin Plugin

  • (adrelanos) Once the TorChat Pidgin Plugin is stable enough and available as .deb it should be included into Whonix documentation or even be installed by default.

[FEATURE] Whonix (USB) installer

  • (adrelanos) The Pre Install Advice recommends to use a dedicated host operating system on external media just for running Whonix. Even when not using Physical Isolation, this improves security a lot. Users should be more encouraged to do it.
  • (adrelanos) The Whonix installer could install a host operating system to a USB disk and download the Virtual Machine images.
  • (adrelanos) The host operating system on the USB disk should be fully encrypted.
  • (adrelanos) I am not aware of any tools running on existing Windows/Linux/Mac, offering to install Debian on an encrypted USB hdd.

[OPTIONAL FEATURE] Whonix host additions

  • (adrelanos) Vidalia 0.3.x to control Whonix-Gateway, ssh shell into Whonix-Gateway, sshfs into Whonix-Gateway, check for stale mirror attack (see About Ubuntu on Security and Hardening page) and Wipe RAM panic script would be some useful additions, which Whonix could provide for the host operating system.
  • (adrelanos) Backup of hidden service keys on Whonix-Gateway is also difficult.
  • (adrelanos) Host firewall progress: https://github.com/adrelanos/Whonix/tree/untested_adre/host

[SECURITY] Pin check.torproject.org and torproject.org SSL certificates

[SECURITY] Pin check.torproject.org and torproject.org CA SSL certificates

  • (adrelanos) In meanwhile until pinning the SSL certificate gets solved we could also pin the certificate authority "--capath /invalid/ --cacert /usr/share/ca-certificates/mozilla/DigiCert_High_Assurance_EV_Root_CA.crt".
curl --verbose --tlsv1 --proto =https --capath /invalid/ --cacert /usr/share/ca-certificates/mozilla/DigiCert_High_Assurance_EV_Root_CA.crt https://check.torproject.org
  • (adrelanos) Should ask torproject.org how long they want to stick with with that CA.

[FEATURE] Vidalia by default/Graphical Gateway [OPEN]

  • (adrelanos) Looks good: Vidalia on the Tor-Gateway I think we could attract more users, if the Gateway were graphical. More people know Vidalia, it's easier to use compared to arm and more popular. What about making that default? CLI-only Gateway could be optional. Arm can remain installed.
  • (adrelanos) Would require some minor tweaks. 1) Reduce default screen to 640*480 (just to please Vidalia, xterm, arm) and the VM window must not be scrolled. 2) poweroff / restart / start vidalia right click menu 3) autostart vidalia
  • (anonymous) That pretty much doubles the TCB. Put more users before security? We had that discussion some months ago... If you had a look at "Whonix²" on the security page you'll know that my vision is incompatible with this proposal. But, as I said then, I won't stand in the way as long as the more secure custom setups (=build from source, "Whonix-Pi") are still working and maintained.
  • (adrelanos) Yes I want this and Short: I don't put security over more users. Long answer: Example: Mixminion vs Tor. Similar applies here. Mixminion is a high latency remailer, with cover traffic, protection against traffic confirmation (end-to-end correlation), theoretically more secure than Tor. The problem is "theoretically". They couldn't attract enough users and without enough users it's equally (in)secure as Tor. That's why they decided, to no longer work on Mixminion. Whonix also needs also lots of users, to 1) get press/publicity 2) more developers 3) more research and audits. 2) and 3) will result in more security. The graphical gateway feature in T-G script can be a function, which is easy to out comment before using the script. First we attract loads of users, get them interested and informed and the ones who want more security and easily harden Whonix.
  • (anonymous) I'd argue that the Mixminion vs Tor decision was ultimately short sighted and wrong. Mixminion could have been significantly improved and had attracted more users by building in bidirectional communication right from the start and creating a proper front end. Further, by building Mixminion into Tor or on top of it, the choice would again have been high, high vs low, low. As an alternative to short-sightedness one could let the conspiracy guys speak. I'll leave it at that for the off topic. Your argument on Whonix misses the point that we are building on the strength of Debian/Linux and Tor. Realistically we will get the most security improvements by improving the upstream projects. For example. he number of actual Whonix users will always be small compared to the number of total Linux users. You last line however is a good one. Hence, no further objections from my side ;)
  • (adrelanos) Vidalia "default" features (it might be impossible to support all of them): start Tor; stop Tor; new identity; network map; bridges; modify torrc permanently (comments get lost!)
  • (adrelanos) Vidalia also has some feature "[Tor] Changed=True", which I do not understand yet. It might modify Tor temporarily, expand torrc permanently or modify Tor through ControlPort once Vidalia started.
  • (adrelanos) Vidalia features in Tails lack after short glimpse: start Tor; stop Tor. Have they modified Vidalia or is that an option?
  • (adrelanos) Harder than I though. For testing "sudo apt-get install --no-install-recommends vidalia tor tor-geoipdb" (to prevent installing unpatched torsocks)... Will end up with a defunct Vidalia, since Tor is run as service/daemon on startup as root and drops to user debian-tor. Vidalia expects, by default, Tor to run under the same account as Vidalia. We can't run Tor as user "user", because by Whonix design, only user debian-tor may establish clear connections. User "user" can run apt-get and DNS over Tor. The X server, Openbox and Vidalia should (must?) run as user "user". I run into permission problems. Tails runs Tor under a different user account and runs Vidalia as the desktop user. There is a solution. Not sure if Vidalia is suited for Whonix.
  • (anonymous) I suppose you either need HashedControlPassword/CookieAuthentication or run vidalia as debian-tor
  • (adrelanos) Running as debian-tor works. Do you know how to fix the following error...
    No protocol specified
    No protocol specified
    vidalia: cannot connect to X server :0
    
  • (adrelanos) When not using gksudo, kdesudo or similar?
  • (adrelanos) There might be also security consideration when running Tor and Vialia under user debian-tor. Might be safer to run Vidlia in it's own user account. But these considerations do not severely apply to Whonix. With TBB everything, TorBrowser, Tor and Vidalia are running under the same account. For better security the whole X can be removed.
  • (adrelanos) And even if I set /etc/tor/torrc's permissions to let anyone edit it and owner to debian-tor, vidalia still complaints about not being able to write to /etc/tor/torrc.
  • (adrelanos) Really hard for me. Not sure if I can get it done in time... Tails patches Vidalia. #4716 and #6209 are blocking bugs. Problem is, Tor is managed as a service, starts system wide, starts as root, drops to debian-tor. Vidalia expects Tor to be installed not-system-wide. The start/stop Tor button will not work as expected, they use different torrc's.
  • (adrelanos) Tor will listen to the "user" instance, i.e. user debian-tor. When Vidalia (running as debian-tor) wants to restart Tor, Tor will not start and complain "you already start me as debian-tor, don't set user debian-tor then". I will have to look further into this...
  • (adrelanos) One thing could work: let Vidalia manage (=start/stop) Tor. But I don't like that solution either. Autostart as service were no longer possible, custom autostart were required, removal (or not installing X, Vidalia were more complicated)... Perhaps no good idea, when Tor gets updated, it will enable the default autostart hooks again.
  • (adrelanos) Maybe I have a solution... All files (i.e. cached-certs, cached-microdescs, control, lock, state, torrc.orig.1, cached-microdesc-consensus, cached-microdescs.new, control.authcookie, log, torrc) will be placed in /home/user/tor. Vidalia, X and Tor run under the same user account.
    • (anonymous) as long as tor alone, without x and vidalia works just the same it's OK for me.
  • (anonymous) For most users, tor will "just work" in the background. People who want to tweak it should know what they are doing, they then can install vidalia if they want to themselves. As a default options it really only makes sense if everything works seamless and logically. Does tail achieve that? And second question: is it worth the effort to merge their changes into Whonix?
  • (adrelanos) Still not sure if it makes sense to add Vidalia. Yes, it looks nice, has an integrated torrc editor... But... One drawback with Vidalia 0.2.15 remains... As soon as you edit torrc with Vidalia (i.e. add non-obfuscated bridges, all comments in torrc get lost, i.e. comments how to add obfuscated bridges get lost.). I'll look into Vidalia 0.4... Update, there is no 0.4, only 0.3.x. I'll look into that one.
    • (anonymous) well, that's a bug and should be reported.
    • (adrelanos) #5475 will be fixed in Vidalia 0.3.2-alpha. Update: the torrc editor in 0.3.2-alpha is good.
    • (proper Vidalia 0.2 can not be used. Not being able to edit torrc is a blocker.
  • (adrelanos) Functions which must be tested. All tests using 0.3.2.-alpha. (Only tested locally, no image build yet.)
    • Tor running as User "user".
      • Impossible. IRC: proper: "service tor stop" and "service tor status" do not work when User in torrc is anything else than debian-tor? (ubuntu precise, Tor v0.2.3.17-beta) expected? known bug? <not sure allowed to post name> proper: That's a security feature, to keep whatever can write to tor.pid from tricking root into killing processes running in other user account
    • cli: sudo service tor stop
      • Working
    • cli: sudo service tor start
      • Working
    • Vidalia: connect to existing Tor (started on startup as service)
      • Working
    • Vidalia: start Tor (if closed with sudo service tor stop or Vidalia stop tor)
      • Impossible.
      • After sudo service tor stop... Trying to start Tor with Vidalia will fail.
        [Warning] Error setting groups to gid 118: "Operation not permitted".
        [Warning] If you set the "User" option, you must start Tor as root.
        [Warning] Failed to parse/validate config: Problem with User value. See logs for details.
        [Error] Reading config failed--see warnings above.
        
    • Vidalia: stop Tor
      • Impossible.
      • When Tor is autostarted (as service), or started with sudo service tor start... If you try to terminate Tor using Vidalia, the output will be: "Vidalia was unable to stop the Tor software. Vidalia has not started Tor. You need to stop Tor through the interface you started it.".
    • Vidalia: edit torrc
      • Working.
    • Vidalia: tor log
      • Working.
    • Vidalia: add (non-obfuscated bridges)
      • Not yet tested.
    • Vidalia: add obfuscated bridges
      • Not implemented yet. There is somewhere a ticket.
  • (anonymous) (old TODO): openbox menu entries, autostart X
  • (adrelanos) This ticket is outdated. Vidalia 0.3 won't come. No one working on it anymore and because it's C/Qt based, it seems unattractive/unlikely that someone will take over. It's more likely someone is going to create a python rewrite of Vidalia.

[SECURITY] MAC address in public networks [OPEN]

  • (adrelanos) We need to add instructions how to change mac addresses on bare metal, since it can't be done with VirtualBox. UPDATE, not exact, see below.
  • (adrelanos) Tails MAC address; Tails macchanger
  • (adrelanos) When using Whonix's bare metal Tor-Gateway in public networks, it might not be wise to use a fixed MAC, because Tor-Gateways's MAC address is public knowledge. That reveals the fact, the user is a Whonix user. Affects anonymous wifi adapter. Update: Also affected anonymous 3G modem.
  • (adrelanos) And a google search told me, that our current MAC addresses are unique to Whonix. No other results for them. We should pick two popular network cards.
  • (anonymous) MAC addresses don't work like that, they are supposed to be unique, there are no "popular" addresses out there. What we need to do in the case of public networks is randomize on reboots.
  • (adrelanos) Randomize without asking on reboot is not good, like Tails pointed out, that can warn admins. We have to educate Whonix users about this issue and they have to make that decision.
  • (adrelanos) The default MAC address for non-public networks should include a popular vendor, followed by the "unique" part.
  • (anonymous) Well, if we use a non-unique MAC this isn't really so much of an issue because you still have some deniability. If using standard VBox Whonix on public networks we need to tell users to change the MAC on the host!
  • (adrelanos) Yes, a NIC from a popular vendor is just a minor thing. That's only a minimal improvement, in case some stupid application collects your MAC (for licensing stuff) and sends it somewhere.
  • (adrelanos) The issue in public networks is more complicated. The first part of the MAC has to be a popular vendor and the second part to be random. (by Tails design) If they are twice in the same public network, they (depending on their threat model) shouldn't change their MAC. Changing the MAC inside the VM is of no help within public networks. MAC has to be changed on the host, that's the MAC the public network gets to see. Bare metal = host. They won't need special instructions.
  • (adrelanos) Started documenting, Whonix in public networks / MAC Address. UPDATE: may be revised. Sufficient for Whonix 0.2.0.
  • (anonymous) Even according to Tails doc Whonix can do automatic randomization; it's not a live distro and therefore not suited for public PCs, the worry about non existing vendor IDs is therefore a lesser too. What we need, for 0.2, is a script that will configure Ubuntu/Debian to disable auto starting of interfaces at boot and another script that can be run automatically, if so desired, to change the MAC address of all attached NICs. I think Backtrack is configured that way.
  • (adrelanos) This is a hard one. And the macchanger scripts would have to be applied on host (hard, startup scripts are operating system and even distro specific) or for bare metal, on T-G. Neither Whonix nor Tails are ready for this kind of adversary in public networks. We outlined that in hardening and may add a link to the readme as well. Imho for now we can't do much more than documenting. When not used in public networks, we don't have to tamper with the host's MAC (and should not, in order not to break working setups).
  • (anonymous) this does not apply to t-g on bare metal, we control everything. Also currently we assume that Whonix is built and run on debian/ubuntu and scripts for this can be made cross distro and cross version compatible. I think there should be an optional function in the tor-gateway script for this
  • (adrelanos) I am okay with a optional function, but I wouldn't know how to implement it.
  • (anonymous) t-g on "bare metal" (no matter whether it's a VM itself or not) always needs a changed mac address, we should use the same as for the VM (and a 3rd for host if t-g runs in vbox?) Apparently it can be added in /etc/network/interfaces as "hwaddress ether 00:00...."). That should be default for bare metal. 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". Then in addition we should provide a script to randomize, optionally on boot: add "pre-up macchanger -e eth0" to the interfaces file. TODO: documentation, -baremetal flag for t-g.sh.
  • (adrelanos) "t-g on "bare metal" (no matter whether it's a VM itself or not) always needs a changed mac address" - Why?
  • (anonymous) As I understand it if one uses bridged mode on the t-g and connects via Ethernet the t-w will be able to see both MAC adresses, the virtual VBox one and the physical of the host. Though I did not tested that.
    • (adrelanos) T-W should be only able to see eth1's MAC (internal network: Whonix). T-W should not be able to see eth0's MAC (NAT or bridged). If that were the case, out setup were broken. Why should T-W see eth0's MAC? Everything T-W does will either be filtered or redirected into a Socks-, Dns- or TransPort. If that were the case, this were worth a bug report against Tor client. We should see if your assumption is actually true before implementing it (for that reason).
    • (anonymous) Not so fast. We got a bare Metal Whonix with a t-g in vbox and a t-w in vbox. The virtual eth0 of the t-w in bridged mode directly connects to virtual eth1 on the t-g (bridged mode) That's how it's supposed work. But in reality t-g connects to the physical NIC on the client host which is connected to the physical NIC on the gateway host, which is connected to the virtual eth1 on t-g. Who says t-w has no way of finding out the MAC of either physical NIC? I very much doubt that, there are all these broadcast and arp things going on. Now if we use NAT for both VMs what do they see? Only a virtual NIC of the Vbox NAT device, what's the MAC of that, can it be changed? Looks like 10.0.3.2 is the virtual gateway with 52:54:00:12:35:02 which isn't unique. good. So, should we switch to NAT now? But maybe I'm wrong and t-w can't read physical MAC addresses?
      • (anonymous) Do you have a bare metal set up to test this on? I'm pretty sure if using bridged networking the t-w can actually directly connect to both systems the t-g and its host (as if it was directly connected to two different NICs). Consequently if that's true, the host allowed forwarding and t-w was misconfiguration or rooted one could circumvent tor.
        • (adrelanos) No, I don't have a test environment yet, hopefully soon.
    • (adrelanos) Okay, that all sounds quite scary. I haven't yet completely wrapped by head around it. Anything switching away from bridged networking sounds fine.
      • (anonymous) note: that the host could potentially forward and bypass traffic doesn't depend on bridged being used or not. The t-g host needs to be secure in every case. bridged mode really only has implications on MAC fingerprinting.
  • (adrelanos) eth1's MAC on T-G (internal network) should really be changed to "0800272fcf44", but fixed. Then T-G VBox were equal T-G bare metal.
  • (adrelanos) And while we are at it, anything against using uppercase for the MAC's? VBox converts to uppercase anyway.
    • (anonymous) Linux tools default to lower case, if I copy and paste that's what you get :)
    • (adrelanos) Shouldn't we convert to uppercase anyway?
      • (anonymous) If you want to, it's just cosmetic
      • (adrelanos) Not solely cosmetic, it prevents confusion if anyone cares to check. This part closed. Whole thread not.
        • (anonymous) if you say so :P Add to documentation and then let's file it for now? This isn't high priority to automate.
        • (adrelanos) Well, no, I am of course not happy with the outcome of the whole thread / problem with MACs. What is done, is the part of discussion about using uppercase for the MACs in build documentation. You said it's solely cosmetic and and didn't disagree with uppercase. I'd prefer uppercase to prevent confusion ("build documentation said low but in fact in is big, is that alright?")
  • (adrelanos) Any suggestions for a fix for Whonix 0.2.0? Any suggestions for a long term fix?
    • (anonymous) "add to documentation" = I think we should just document the changes needed to /etc/network/interfaces and leave it to the user to do it manually. Long term, T-G should probably auto-detect if it's run directly on bare metal or in bridged mode and always spoof the MAC address, disable eth0 networking on boot and offer a script to randomize. ... Further we need to take care of USB wifi/mobile network sticks.
  • (anonymous) basic documentation is done. not much more I can do without a baremetal/Pi test set up.
    • (adrelanos) See bold above.
      • (anonymous) I know what I wrote ;) Short term goal done, 0.2 tag removed.

[SECURITY] Encryption/Authentication between T-G/T-W [OPEN]

This is mainly useful when using multiple physical Whonix-Workstations.

  • (adrelanos) While I made the Mobile device page, it came to my mind to combine it with Whonix. They could connect to T-G over OpenVPN and be transparently proxied. On the other hand, Orbot already supports transparent proxying as local redirection. Apart from the more complicated setup (router port forwarding, dynamic dns in many user cases), OpenVPN and a connection through the internet would be required. The only advantage were, that Tor is not running on Android, that it's running on a second machine. I haven't looked into Orbot, but I don't think that would be more secure than Orbot's local redirection. Once the mobile device is compromised it could jump onto any network anyway. Opinions on the security? And should we support that anyway? (There are also devices out, were Orbot is not available, but OpenVPN is.)
  • (adrelanos) We shouldn't add OpenVPN by default, as it would give up one of Whonix's advantages: Tunneling Proxy/SSH/VPN through Tor (Tor -> Proxy/SSH/VPN)
  • (adrelanos) Due to the recent question this is still interesting. One who uses multiple T-W's with only one T-G, might suffer from a single infected T-W. We have to keep in mind, that an infected T-W can choose any internal IP it wants. An infected T-W can also contact another T-W. A firewall for T-W only accepting connections from T-G's IP wouldn't help either, as it's easy to impersonate any IP's in LAN. An infected T-W impersonating T-G and forwarding to the real T-G would be an active mitm and fatal. When using virtual machines, the user would have the chance to setup multiple isolated virtual lans. Should we provide instructions how to do so? However, that is no option for bare metal. Can we somehow effectively prevent IP conflicts and/or use authentication?
  • (anonymous) I've added some relevant links and hints.
  • (adrelanos) We have too less documentation there. Using SSH is not impossible, but looks very complicated. I added a brief overview, about necessary step to the article. Using that in practice, actually giving instructions and testing looks very time consuming. OpenVPN may be a more realistic choice, it also requires creating and distributing keys (at least ca directive has to be distributed. If we are not going to support connecting to T-G over a untrusted cable (see my first message in this thread), what we should probable do, as it makes no sense anyway, we also do not need encryption. Only authentication. I wonder if there are simpler solutions available?
  • (anonymous) I could need some testers here. It seems to be working now, to quickly test you can use e.g. `links2 -socks-proxy 10.8.0.1:9100´, dig or edit the TBB and xchat proxy settings accordingly. As I understand it, multiple workstations can be securely added by creating additional per client keys and put new server.confs into /etc/openvpn on the gateway. I don't know OpenVPN well enough to be sure that this actually achieves our goal: prevent t-ws form impersonating t-g, eavesdropping on not ent-to-end encrypted traffic and messing with stream isolation. I know that by design no solution can actually prevent DOS, side channel and direct communications between compromised t-ws if using a LAN behind t-g and not just point to point connections. But these are comparably minor issues.
  • (adrelanos) You made some good points about DOS and so on, which I added. Very interesting. I am going to test, at least after Whonix 0.2.0 has been released. If we can implement this a generic way, automated (or simply with long passwords which have to be entered twice), without breaking anything (what I doubt, we'll at least break OpenVPN functionality on T-W), that could even be the default configuration. Authenticating and/or encrypting T-G - T-W is a fine thing. I am still wondering if there are easier methods than OpenVPN, because we don't 100% require encryption, only authentication.
  • (anonymous) TODO: test, improve, especially with multiple t-ws TODO: MAC address conflicts?
  • (adrelanos) https://sourceforge.net/p/whonix/wiki/Connection%20Between%20Whonix-Gateway%20and%20Whonix-Workstation/

[OPTIONALFEATURE] Multiple Gateways [OPEN]

  • (adrelanos) Currently we have only one Tor-Gateway. To push forward the tickets "Support for proxies as Tor replacement [ProxyBOX]", "Support for Freenet [FreenetBOX]" and "Support for VPNs as Tor replacement [VPNBOX]" it would help, if we were able to use multiple gateways. I am personally not going to connect to single proxies, JonDonym oder VPN's directly, since I don't want to give up my anonymity as a Whonix developer while doing so.
  • (adrelanos) But I'd be interested for example in a two gateway solution. Tor-Workstation -> VPN-Gateway -> Tor-Gateway. The VPN would be tunneled through Tor, i.e. user -> Tor -> VPN. As soon that is working, it would be possible to change the order, i.e. connect to the VPN first, then connect to tor, i.e. user -> VPN -> Tor. Or to drop one or another gateway, i.e. for example, Workstation -> Proxy-Gateway. Or to do other interesting combinations, such as, Tor-Workstation -> VPN-Gateway -> Tor-Gateway -> another VPN-Gateway.
  • (anonymous) Note that doing that makes mitigating id correlation pretty much impossible (you'd have to run multiple VPN instances on the second gateway).
    • (adrelanos) I don't think so. We have to look at, at least two different ways. Adding something behind Tor, i.e. connection scheme like Tor -> VPN, presses everything into the same pseudonym, adds a permanent "exit".
    • (adrelanos) As long as Tor is the last one in the chain, i.e. connection scheme like T-W -> VPN -> ... -> VPN -> Tor, circuits and exits can still change. To establish such a connection scheme, the gateways have to be chained the other way around, i.e. T-W -> Tor -> VPN -> ... -> VPN. Even IsolateSocksAuth were still supported. T-W would still communicate with Tor's Socks-, Dns- and TransPorts. Tor would have to connect through those additional hops (in this example, VPN's). Tor would havet oconnect through all those VPNs and from the last VPN, finally connect to the Tor network. In the end the connection scheme would look like T-W -> Tor -> VPN -> ... -> VPN -> entry guard or bridge -> middle node -> exit node. Identity correlation can still be prevented.
      • (anonymous) Sure, that's true. I was replying to your explicit example Tor-Workstation -> VPN-Gateway -> ..., not the whole post.
    • (adrelanos) Thanks for asking. That's difficult to describe. Unless my brain totally messed up, it should work like that, not tested yet. I like to start documenting this. At least the theory, discussed right now. Do you know a generic term for proxy/VPN/SSH?
      • (anonymous) I don't think there exists a proper term. Anonymity network (redirects to proxy server on wikipedia), anonymizer, anonymizing forwarding gateway, anonymizing proxy. Proxy can be used as a generic Term, at least SSH, real proxies, I2P and Tor are associated with it. VPN not so much because usually it refers to private networks, but I don't see why an anonymizing VPN server shouldn't be a proxy.
  • (anonymous) Would be interesting if it just works, i.e. do two (or three) t-gs in a row still work (not that we should do that, it's tor over tor). I would like to know what secret sauce Tor is using for its transparent proxy feature. Everything else related to transparently proxying seems to require ip_forwarding, DNAT... Resources: SSH (only supports tcp, you need to tunnel dns over that somehow) http://tomatousb.org/forum/t-326180/poor-man-vpn-with-ssh-transparent-proxy-only-tcp https://github.com/apenwarr/sshuttle Theoretically these should also just work. Or not? To this day Tor's transparent proxy function amazes me. AFAIK it's absolutely unique. Tor must keep track of all packets sent to it and then send them back to the correct source IP (local host, t-w client) even though the source is not the destination IP. In other words, implement ip_forwarding in user space. Or it's SOCKS on steroid. Maybe a tor dev can give us a better explanation. Anyway, duplicate this functionality with other privacy/anonymity solutions like VPN, SSH, IPSEC, looks a bit more complicated than the transparent tor setup, they work some layers down on the OSI model.
    • (adrelanos) There are other applications, which also implement as TransPort, with no requirement for DNAT or ip forwarding. One of them is redsocks, documented in Whonix/OptionalConfigurations#TransparentProxying and Whonix/OtherAnonymizingNetworks#ProxiesasaTorreplacementProxyBOX. Supporting proxies should be easy, once the skeleton for multiple gateways is ready. And SSH can been seen as an "extension" to proxies, since SSH can offer a socks5 proxy. Once an account for SSH has been setup, allowed communicate "in the clear" (perhaps to the next gateway), redsocks/iptables can be used to redirect all traffic into redsocks's TransPort. No ip forwarding required. I don't know yet how to forward the traffic from AnyBOX to a VPNBOX to WAN, perhaps that VPNBOX really requires ip forwarding.
  • (anonymous) I haven't looked into it but if redsocks is fully transparent, Tor is probably doing a similar thing and traffic on trans_port is internally routed to an internal SOCKS port. This also means, if they drop that functionality (which came up at one point), there's still a way around that. What do you mean by AnyBOX->VPNBOX? VPN doesn't seem to support SOCKS interface so we can't use redsocks. Therefore we'd need forwarding, is that what you meant?
    • (adrelanos) redsocks is fully transparent and can do even more. It requires iptables to redirect TCP and/or UDP (!) traffic to redsocks's "TransPort's". redsocks can forward that traffic to http (supports due to nature of http proxy, only http, no SSL or other services), http-connect, socks4(a) or socks5 proxies. One minus for redsocks: does not offer a DnsPort yet. Afaik DnsPort is unique in Tor. The non-DnsPort with redsocks is a non-issue, if the Tor is the last chain in the connection scheme, since the proxy(or ssh) would only have to forward TCP and Tor would keep care on resolving DNS.
      • (anonymous) if it's t-w <-> "redBOX" <-> t-g you probably don't want let DNS bypass your second proxy and undo much of the additional security you wanted to gain.
        • (adrelanos) Is the example a connection scheme or "physical" box order? Anyway, I answer both.
        • (adrelanos) Connection scheme: T-W -> Proxy (redBOX) -> Tor... Or the same as physical ordering: T-W -> T-G -> redBOX. DNS is a non-issue here, since the redBOX simply has to forward TCP to the Tor network.
        • (adrelanos) The other way around... Connection scheme: T-W -> Tor -> Proxy (redBOX). Or same as physical ordering: T-W -> Proxy (redBOX) -> T-G... Transparent Proxying is an issue here, since no DnsPort is available on redBOX. redBOX could only forward it to a known (=you know the IP) DNS resolver (such as OpenDNS). The exit IP's who connect to OpenDNS may change but OpenDNS still could correlate all DNS requests to the same identity. This is not recommend anyway, since the last proxy in the connection scheme can correlate a lot stuff.
          • (anonymous) I meant the latter.
      • (anonymous) Isn't having a local tcp enabled dns listerner fully transparent, i.e. you iptables redirect all dns from t-w tojust like t-w does with the dns port.
        • (adrelanos) This won't work. redsocks has no DnsPort. redsocks can forward UDP (port 53) traffic to a public DNS server (example: DnsCrypt by OpenDNS). This is because socks proxies support hostname resolution, not DNS. If the second part in the physical ordering, i.e. T-W -> T-G is not given, DNS will be an issue.
          • (anonymous) But it will be transparent. transparent just means that the client (other OS or local application) doesn't have to care about being proxied. Sure, DNS to a single provider is a usually bad, but with redsocks you are already using a single exit provider for ALL and full pseudonymous connections, that's much worse than just domain names.
          • (adrelanos) Yes. Well connection scheme like T-W -> Tor -> Proxy/SSH/VPN is not recommend anyway. There aren't much useful use cases, perhaps "plug" that thing in (if we can make it "plugable") to access websites, which otherwise ban Tor or if, in their threat model, the Any is less likely to sniff/manipulate the traffic.
          • (adrelanos) Connection scheme like: T-W -> Any -> Tor, i.e. "physical" ordering like: T-W -> T-G -> redBOX is a fine thing. The missing DnsPort on redBOX won't matter. Tor won't know who you are behind the Any, it's an additional hop and even might circumvent when Tor is censored and even might obscure the fact, you are using Tor.
    • (adrelanos) "What do you mean by AnyBOX->VPNBOX?" With "AnyBOX" I wanted to create a generic term for "some box", either T-W or any other kind of other gateway.
    • (adrelanos) "VPN doesn't seem to support SOCKS interface so we can't use redsocks. Therefore we'd need forwarding, is that what you meant?" Yes. If we are not going to find a better/other solution.
  • (adrelanos) About the multiple gateways "skeleton" I talked about above... If T-G is 192.168.0.1, a ProxyBOX should be probable "192.168.0.1 - 1 something". Perhaps a MultipleGateway should be 192.168.0.199 198 and on. I don't think chaining multiple T-G's in a chain as an exercise is hard. Once that exercise is working, new combinations are possible.
  • (anonymous) I don't think that's "correct". I'd use |t-w 192.168.3.2 eth0| <-> |t-g 192.168.3.1 eth1; 192.168.4.2 eth0| <-> |AnyBOX 192.168.4.1 eth1; 192.168.1.2 eth0| <-> |physical router/modem: 192.168.1.1 publicIP wan0|. We probably should replace our default 192.168.0.* and with a higher number because it is widely used on LANs already and can confuse and complicate setups. You'd need to change the eth0 settings on t-g for that, but otherwise it should just plug in. When changing the order (t-w>anybox>t-g) the IPs have to be changed accordingly but otherwise it should just work.
  • (adrelanos) Agreed with everything and that's how I liked it to be. We can start a new draft, it's perhaps best placed as Multiple Gateways under OtherAnonymizingNetworks.
    • (anonymous) I don't think we can do a generic anybox, every solution requires different networking and firewall settings. I'd just start with a "redBOX" and then try to chain all 3 in different order.
    • (adrelanos) Yes. Would still be nice if we could call it "Chaining Multiple Gateways" or so and if some changes were generic and some dependent on using proxy, ssh or VPN.
  • (adrelanos) This whole discussion can be converted into documentation. I think we recognized, to prevent confusion, it's useful to always describe the connection scheme and the "physical" ordering (that term may be exchanged). And let's call Proxy/VPN/SSH Any or let's make a new term "the AnyAnonymizer" or the "AnyProxy"?
    • (anonymous) I like AnyProxy - got the "An" for anonymitym, though we need to explain that term. I'd also change "connection scheme" to routing scheme or better yet routing order.
    • (adrelanos) Some other ideas: AnyProxy (your idea), AnProxy, AnyAnProxy (Anonymous Any (=proxy/SSH/VPN) Proxy), AnAnyProxy (Anonymous Any Proxy), AnPSVproxy (Anonymous Proxy/SSH/VPN Proxy) or PVS-proxy (Proxy VPN SSH). I'll agree with any of them. We define all terms at the beginning of the article. Also agreed with the term routing order.

[SECURITY] Deterministic builds [OPEN]

  • (adrelanos) We should check if Gitian can be used with Whonix. Deterministic builds (Gitian) should ensure, that the binaries are created from the source we claim. Others should be easily able to check that. If Gitian works with Whonix, we should update the build documentation accordingly. I fear, to be able to use Gitaian we first need to solve the fully automated builds ticket.
  • (adrelanos) Since the scripts download and install the newest operating system security updates, this would cause different hashs. If we are going for this one, we'd need somehow to keep care of this.
  • (anonymous) these hashes are known and archived on ubuntu.com and mirrors. Really, this is a non issue for Whonix as long as no binaries are compiled. The configuration is already deterministic, easily in a certain time window but even beyond that through setting up a custom mirror. Installing all security updates asap is absolutely necessary, that shouldn't be changed.
  • (adrelanos) I also wouldn't know how to check all the hashes in the next 15 minutes. We also could explain, how to do that. It's probable best to put this ticket on wait. First fully automated builds and a build machine have to be sorted out, perhaps also still a package is needed. It's nice to note for later but already the second step before the first one.
  • (anonymous) that feature is nearing completion, should be moved.
  • (adrelanos) Ok. I hope it's compatible with debboostrap. Too late now. Let's research that when it's done.
  • (anonymous) I agree that there's the fundamental issue that we build always a current image, with the latest security updates. But I think that's what we want and shouldn't be changed just to for this sole reason.
    • (adrelanos)
  • (anonymous) Basically to compare you could take the binary, update it, then build a new image from source. Then you hash all files in the two mounted images (like cd && find . -type f -print0 | xargs -0 shasum|sort>../outputfile) and diff the outputs. If binaries and system config files differ you need to investigate, cache and tmp are usually safe and are mostly deleted by the scripts anyway.
    • (adrelanos) Perhaps if Whonix has more users/devs later we also ship custom complied applications.
    • (adrelanos) Whonix is a very security sensitive project, just like bitcoin. Not sure if it must be Gitian or if any other methods work for us. I am only convinced that it's a Nice To Have, to prove that the binaries we ship are made from the source that we claimed at some time. That also becomes more interesting if we get our own build machine for more frequent builds. So if we can develop a script to verify our work, we should go for it. Anyway, I lack the technical expertise to implement it and I expect this topic to come up later again, if we get more users.
  • (anonymous) building and diffing (before ever booting them up, or you'll see some more log and chache files) two T-G images on two different systems but on the same day (so we don't get different apt-get updates) yields following results:
    /var/cache/ldconfig/aux-cache
    /etc/console-setup/cached.kmap.gz
            look harmless, cache files naturally differ
    
    /boot/grub/locale/en_AU.mo en_CA.mo en_GB.mo
            sometimes there, sometimes not, looks harmless
    
    /etc/apt/trustdb.gpg
            must be harmless (a single byte at the beginning differs)
    
    /boot/initrd.img-3.2.0-25-generic
            needs to be unpacked and compared again:
            mkdir /tmp/unpackinitrd
            cd /tmp/unpackinitrd
            cp /mntpoint/boot/initrd.img-3.2.0-25-generic .
            gzip -dc < initrd.img-3.2.0-25-generic | cpio -i
            results: it's console-setup/cached.kmap.gz (again)
    
    /var/lib/initramfs-tools/3.2.0-25-generic
            sha1 of the initrd
    
    /lib/modules/3.2.0-25-generic/modules.dep
            because of vesafb.ko? seems related to building on virtualbox vs on bare metal?
    
    /etc/shadow
            different hash of the changeme password, random seed? Doesn't matter you should change it immediately anyway.
    
  • (anonymous) Based on this I conclude that when building T-G there are no leaks from the host and the build is deterministic except for above files. I don't say this with absolute confidence, tests by other users should first confirm this. T-W was not tested.
  • (anonymous) I guess we *could* disable all update repositories in sources.list while building and get a more easily verifiable deterministic build system but because Tor is so slow binary builds should really come with all updates available preinstalled. Again, ubuntu archive contains all the files to check manually. It's more work but certainly possible. Contrast that with the real difficulty of verifying compiled code vs its source... I forgot: Imagine there's a vulnerability in wget or apt-get, we should better patch that really quickly before using the vulnerable code to build our "secure" Whonix. (In case of apt-get we are pretty SOL in any case).
  • (adrelanos) Since Whonix is now based on Debian Wheezy and the images are build using grml-deboostrap... I still have no idea if I build Whonix on day A and someone else builds it on day B, to verify it's build from the same source. grml-deboostrap with naturally download and install the most recent versions while the build from day A lags behind. Old Debian packages can be downloaded from http://snapshot.debian.org/.
    • (adrelanos) For example let say sha256sum /usr/bin/nano
      20ad0bc144d5f1d1f93e2f0afbc4b43b2fce3a2acf9ade751d6cf5d9bba34b4f  /usr/bin/nano
      
be68e133b5e81df41873d32c517b3e5950770c00fc5f4dd23810cd635abce67a 1572388 nano_2.2.6.orig.tar.gz
4b341f6747f81e07e256baf11d1127b15d51012164dd1b05f0cd5fee87d9e1f1 30095 nano_2.2.6-1.debian.tar.gz

[OPTIONALFEATURE] Freenet Support/"FreenetBOX" [NEEDS INFORMATION]

  • (anonymous) Freenet could also be installed on t-g and accessed from t-w. UPDATE: or not...? There's the option to have more locked down webinterface that doesn't expose admin/debug/... functions
  • (adrelanos) (Freenet homepage: with www has SSL error. Use the version without www, no SSL error.)
  • (anonymous) AFAIK Freenet in opennet mode isn't quite as secure as i2p and Tor, then there's the problem how to configure it securely, there's some kind of proxy support in Freenet but how mature and how secure?
    • (adrelanos) You mean fproxy?
  • (anonymous) Not sure what it's called. I meant like that freenet proxy web site you posted, you enter keys and download stuff. Only the website would run on t-g, not a remote server. I know there's such a feature already built into Freenet webui.
    • (adrelanos) Well, a freenet gateway. Like a i2p inproxy. That's very useful, unfortunately, I searched extensively, and there are no more working freenet gateways.
  • (anonymous) Ideally we'd tunnel it over something, i2p supports udp but then we could only reach other freenet nodes also running over i2p. i2p is said to get a data store that's similar to freenet but more secure than opennet.
    • (adrelanos) You mean, run i2p on T-G and run Freenet on T-G or T-W? Both options seem possible. I know fproxy may run on another computer. What I haven't found yet, are any proxy/socks settings in freenet, do you have a reference for that? Or do you mean transparently tunnel it?
    • (anonymous) Transparently tunnel it. But as I said, it's pointless because you could only connect to i2p (or onioncat) users and freenet is small and slow enough as it is.
      • (adrelanos) Well, if we could still access the whole freenet content and not only the i2p fraction, that still would make sense. Regardless of speed, it can run in background and continue downloads. If it's only 3 times slower I would still interested to see what content they offer.
    • (adrelanos) New idea: Tunneling UDP over Tor. (See topic below.) If we get this done, we can use it for freenet. Freenet security settings: lowest possible, highest speed (like for i2p); (reason: Tor offers already security).
      • (adrelanos) Freenet over Tor works, if you have a VPN behind Tor, which does not block UDP/freenet. This is done.
  • (adrelanos) About the idea with the FreenetBOX, where Freenet is running on Tor-Gateway. Freenet is a background process and the browser is only used to access the webinterface. When freenet were to run on T-G, the cache and all downloaded files were also stored on T-G. The only real advantage, users were encouraged to use the Tor Browser and if they follow any links on freesites to normal internet, they were protected by Tor. If the Tor-Workstation can't access the downloaded content it would be pretty pointless. How it could access it? Afaik you can't download through the browser, the browser only tells freenet what to do. We'd need to enable T-W access on T-G's freenet download folder. And the question again, if the freenet webinterface could be locked down enough to prevent T-W from getting the external IP address.
  • (anonymous) doesn't really belong in wait, if we want new contributors we can't hide this here...
  • (adrelanos) Not looking for contributor yet. Later maybe. The current status is "needs more information" to my previous questions. We could contact the Freenet guys, if they are interested and to get the answers.

[OPTIONALFEATURE] I2P Support [WAIT/LOOKING for contributors/more mature upstream]

  • (anonymous) i2p could only used in addition, not as a replacement for tor: apt-get needs tor, there are no i2p mirrors for any distro. IRC is covered, web not really, i2p eepsites are too limited. i2p would need to run on t-g, i know it's possible but it's not just a simple "apt-get install i2p".
    • (adrelanos) Indeed only as an addition. I also see now way to use it as a replacement. I2p has outproxies (http, https, socks). Unfortunately, there are only a very few of them and those are very unreliable. It would be next to impossible to use them for reliable operating system updates. On the other hand, if it were to work, i2p is designed for such big file transfers.
  • (adrelanos) I made myself familiar with i2p inside T-W, at least inside there, I feel safe. New site: OtherAnonymizingNetworks (also about i2p inside T-W). Also the topic i2p on T-G stays interesting.
  • (anonymous) gpm and links/links2 works for quick web interface interaction on t-g.
    • (adrelanos) Good idea.
  • (anonymous) I've tested i2p in t-g, older CPU, 256 MB RAM should suffice, with Tor and i2p active it hardly goes over 120 MB (non-cache) RAM. But I was pretty disappointed by the performance of i2p. Firewalled but with >10 peers eepsites are considerably slower than .onion sites. There are some servers that have both an i2p and an onion address which I used to test. It's not so much throughput (I tried well seeded torrent and it was pretty acceptable) but latency and stability of the connection are a problem: frequently it would time out and complain about congestion/server down (while the server was fast and working over the tor address). Contrast that with their "Designed and optimized for hidden services, which are much faster than in Tor" http://www.i2p2.de/how_networkcomparisons All inproxies I found are dead: i2p.us i2p.to i2p.tin0.net "eepsite darknet" is much smaller than the "onion darknet", the whole thing after all these years still feels more like proof of concept than a viable alternative for at least a subset of the things people use the clear net for. The only interesting thing is torrents/p2p but I only found one tracker with a small community. Basically I pretty much lost all interest in i2p again. It could be a replacement for Tor if 1) performance was at least as good, 2) there were a lot or stable and fast outproxies, java is no longer a counter argument and if 1 and 2 were fixed I'm sure content and users would follow. But without these two it would only be an addition to tor, significantly make Whonix users more discoverable and vulnerable but not bring any features except for torrents. All in all not worth the investment currently.
    • (adrelanos) Interesting test and opinion. We also don't need scripting support everywhere, we don't have that for all optional configurations as well. A small explanation of the steps is sufficient. Anyway, if we are not motivated enough, we don't have to add it. The least we can do, is informing them in their forums about the possibility. Would be a waste, if someone creates a clone of Whonix for something which is very similar. After posting in their forums we will see if someone contributes.
  • (adrelanos) Contacted i2p.
    • (adrelanos) Barely any interest.
  • (anonymous) there's proxy support, by default only listening on localhost, config at .i2p/i2ptunnel.config We should ask on the forum if their proxy support fits our threat model (i.e. can be reasonably trusted to not leak or disclose the external IP to T-W.
    • (adrelanos) Small clarification for any other readers. They do not have proxy support in sense of tunneling over http or socks. (Source: Google site:i2p2.de socks) They only support a http proxy for "reseeding" (bootstrapping). (Source google cache: trac.i2p2.de/ticket/22) However, as I have already described, transparently tunneling i2p over Tor works. And what you said above is still valid, but another kind of proxy support. i2p were to run ton T-G and T-W would access that proxy that i2p provides for the browser to access .i2p domains.
    • (anonymous) But they do, http proxy on 4444, it proxies http over false.i2p outproxy and eepsites are resolved. there's a separate https proxy. What they don't have is a transparent proxy, dns proxy...
  • (adrelanos) Minimal interest/help from the i2p community. We have i2p over Tor and inproxies, sufficient for me alone. If we are not going to implement it, it won't happen. I propose new status: CLOSED / STALLED. We do not reject the feature. If someone wants to do it, fine, otherwise, not going to happen.
  • (anonymous) doesn't really belong in wait, if we want new contributors we can't hide this here...
  • (adrelanos) Agreed.

[OPTIONALFEATURE] Portable VirtualBox (like portableapps.com) [LOOKING for contributor]

  • (adrelanos) Whonix can be equally as easy to use like the Tor Browser Bundle. There are adjusted versions for portability, such as vbox.me. Also when you google it, you find a lot of stuff about portable virtualbox. It would allow us to configure a package of Virtual Box portable, including T-G and T-W. The user would only have to start both and were done.
  • (adrelanos) Can we trust vbox.me/? (Did not look into it yet.)
  • (adrelanos) UPDATE: coderman implicated that we should make the final package as easy and secure as possible. Secure in meaning of, there should be no buttons were the user can potentially harm himself. (Such as adding a NAT/bridged network adapter to the T-W.)
  • (adrelanos) Another option would be the Virtual Box core combined with PhpVirtualBox. Drawback: we also would have to deploy a webserver which PhpVirtualBox needs to function. Advantage: hacking PhpVirtualBox (disabling dangerous buttons) should be easier.
  • (adrelanos) Or we can control VirtualBox through the command line interface only. A (compiled) windows batch file or linux shell script could be sufficient to start the T-G.ova and the T-W.ova, thus hiding most virtual box controls.
  • (anonymous) doesn't really belong in wait, if we want new contributors we can't hide this here...
  • (adrelanos) Agreed.

[SECURITY] Research: IP discovery through Tor Proxy [LOOKING FOR CONTRIBUTOR]

  • (adrelanos) See torproject.org trac ticket #5928 for details.
  • (adrelanos) Since May 2012, the Whonix project has neither the developers, time nor skill to do the research. Waiting for contributor.
  • (anonymous) doesn't really belong in wait, if we want new contributors we can't hide this here...
  • (adrelanos) Agreed.

[OPTIONALFEATURE] Proxies as Tor replacement/"ProxyBOX" [WAIT for feature: Multiple Gateways]

  • (adrelanos) I spitted up the JonDonym related part. JonDonym is just another local http (free) or optional local socks (premium) proxy. Getting proxy support done, automatically also gets JonDonym support done.
  • (anonymous) let's merge with the other ticket?
  • (adrelanos) Can do.

JonDonym

  • (adrelanos) JonDonym over Tor guide is written (JonDo inside T-W). That one was easy.
  • (adrelanos) JonDonym also supports tunneling UDP, only for premium users, what is a shame.
  • (adrelanos) JonDonym can be used as a Tor replacement. While JonDo is less secure, won't expose IP to T-W.
  • (anonymous) Not really interested in "supporting" (=recommending) a commercial system. Is the "free version" capable enough for a real replacement (overlooking the security/trust issue)?
    • (adrelanos) Answered in the wiki article now.
  • (adrelanos) Theoretically it would be possible to tunnel Tor through JonDo-free (torrc: ReachableDirAddresses *:80; ReachableORAddresses *:443).
    • (adrelanos) That wouldn't make much sense. If one wants to do so, they recommend the other way around. Tunneling JonDo trough Tor.
  • (adrelanos) Contacted JonDo.
    • (adrelanos) That was fast. We got two answers by JonDo admins. Friendly, helpful.
    • (adrelanos) Updated the Whonix JonDonym wiki topic.
    • (adrelanos) Still waiting for their announced wiki article "how to use JonDonym as transparent proxy".
    • (adrelanos) They posted help how to use JonDonym with transsocks.
    • (adrelanos) Still in contact. Their developers answer all questions and are helpful. It looks like Whonix and JonDonym are compatible. Free users may be able to use services on port 80/443 and premium users everything. JonDonym may replace Tor, of course only optional. Let's see what comes up. Maybe they come up with their own JonDoBOX some day, add new features, review, etc. Both projects profit.
    • (adrelanos) With free cascades: some progress Whonix/OptionalConfigurations#TransparentProxying. I've been able to connect to http on port 80, but not be able to connect to https on port 443. That's a strange issue. When using JonDo as http proxy, http and https are supported. When using the http proxy as transparent proxy (with help from privoxy) https gets broken.
    • (adrelanos) Contact with their devs stalled. Over all development of that feature stalled as well. TODO: I should try with redsocks.
    • (adrelanos) Everything with free cascades... redsocks has to be set to http-relay ip 127.0.0.1 port 4001. Both, redsocks and jondoconole running under user account redsocks. Iptables redirect into redsocks, redsocks to http-relay. http-connect will not work. Viewing http sites works, viewing https sites does not work for some reason. Redsocks output: "accepted, malformed request came, httpr_toss_http_firstline, dropping client". Update: asked their devs explicitly if they are interested in allowing free users to use transparent proxying. If there is no response, that will be a "no" and I don't think ever find out how to do it (for https, http works).

proxies

  • (adrelanos) Also added a proxy section. Thanks to the JonDo devs, we have almost complete instructions for using any socks proxy as Tor replacement. Not done yet, documentation needs to be tweaked and needs testing.
  • (adrelanos) There has been some progress. Whonix/OptionalConfigurations#TransparentProxying is about additional transparent proxying through an extra proxy (user -> Tor -> proxy) on T-W but as soon that works well, it can be used as a replacement for T-G as well. Biggest remaining open issue is, that I haven't found out how to remotely resolve DNS through a proxy, while there is no DnsPort and while not using a public DNS resolver. I am not sure that is possible at all. Asked on redsocks mailing list.
  • (adrelanos) transocks_ev is a similar redirector for trans2socks. The transocks_ev readme mentions DNS but it's not done. I mailed the author and he told me, that transocks_ev does not support UDP and therefore no DNS yet (Mai 2012).
  • (anonymous) progress? roadmap?
  • (adrelanos) Quite some progress, 1; 2. Roadmap: Not a high priority. It works within T-W. I am afraid to do more thoroughly testing on a standalone ProxyBOX-Gateway (i.e. ProxyBox-Workstation -> ProxyBOX-Gateway). That is because I don't want to connect to anything, without using Tor. I therefore postponed that feature, until multiple gateways are documented. And that can be done after Whonix 0.2.0 release.

[OPTIONALFEATURE] VPNs as Tor replacement/"VPNBOX" [WAIT FOR FEATURE: Multiple Gateways]

  • (adrelanos) The VPNs are far more widespread than Tor. VPNs are good for people with lower anonymity needs and are faster. We already provide documentation, to tunnel VPNs through Tor. Tunnel Tor through VPN needs revision. Solution might be to modify route with pre-up (delete default route). I am currently searching the answers. VPNs can be added to Other Anonymizing Networks. Not sure how that could be done best, can we avoid enabling IP forwarding? How to call it? The term VPNBOX would have been nice, it's already taken on Google.
  • (anonymous) VPNBox is, VPNBOX isn't ;) Hereby I officially declare, on the 18th April 2012 AD, VPNBOX was "taken" by the Whonix Project. We won't sue you if you "steal" our name but know that it's bad for your karma. So, I think we've got that covered.
  • (anonymous) About the technical aspects, I can't help with that. I needed to do my research myself first. One question though about VPNs, you wrote "It has the additional effect of making all your different kinds of traffic look similar to an eavesdropper." What do you mean by that?
    • (adrelanos) Actually I only reformated (newlines) an existing text, without reading it, because the preview of that page was messed up for this reason. The text is there since ages. The text is not so important, do with it whatever you decide.
  • (anonymous) Why would anyone be interested in a VPNBOX? The design has two big advantages: security and making it easy to use arbitrary applications anonymously. The first one doesn't apply because someone who's using only a VPN already expressed to not really care about security that much. The second doesn't apply either because VPN can be easily set up to transparently tunnel any application (it's even easier than Whonix because of UDP support).
    • (adrelanos) Not sure, no one is interested. There are even companies who sell snakeoil list (ex: killing applications on VPN breakdown, already described in other anonymizing networks article). Additionally VPNBOX offers good protection against IP leaks, even when the Workstation gets rooted. It would be a nice service to document or provide a preconfigured safe setup. Finally it's supposed to find more developers and users. If other developers take up our idea and start JonDoBOX, i2pBOX, VPNBOX, also Whonix would ultimately benefit (more features, more audits, etc.).
  • (anonymous) doesn't really belong in wait, if we want new contributors we can't hide this here...
  • (adrelanos) Not looking for contributors, at least not more than for any other ticket. For the same reasons (fear of connecting to it without Tor), I am waiting until multiple gateways are done. Low priority. Can be done after Whonix 0.2.0.

[OPTIONALFEATURE] Read Only/Portable/Live System [LOOKING FOR CONTRIBUTOR]

  • (anonymous) Live CDs have certain advanatages which in some user cases make them better suited despite all their issues. How to: http://myhowtosandprojects.blogspot.com/2008/07/live-cd-from-your-in-installation.html
  • (adrelanos) Do we need a real Live CD (why?) or is it sufficient to disable persistence, i.e. all changes to the hdd go to the RAM and are cleared after poweroff and restart.
  • (anonymous) true, live cd's are no longer the portable OS of choice (usb/sd is). how to: https://help.ubuntu.com/community/aufsRootFileSystemOnUsbFlash
  • (adrelanos) Do you propose Whonix-Workstation's operating system should be optionally a Live OS or do you propose whole Whonix as Live OS?
  • (anonymous) I'd propose an OneVM based system which can on boot up be instructed to either act as a client to another PhyIso Gateway or to start Tor on the host itself. If we only care about Whonix-Workstation (which already got non-persistence covered) we haven't solved the actual issue: the host would still save data to the disk which we have to worry about. If a PhyIso gateway is used it probably doesn't have to be read only, it only has to mount tor cache and log dirs in tmpfs and not use a swap (which we don't and isn't necessary).
  • (adrelanos) Design decision: using Tor cache or not using Tor cache
    • (adrelanos) If using Tor cache you can make of Tor's "long term brain" which enables essential security improvements in Tor's core: entry guards. Without cache there are no entry guards. That's the typical Live CD approach. I don't know if Tails with its new persistence feature for USB does store the Tor cache.
    • (adrelanos) Hard to decide... Depends on someone's individual threat model. Do you rather expect your adversary to use malicious entry guards or would you rather hide the fact, that you used Tor/Whonix from hdd analysis.
      • (anonymous) It's not about hiding that you use Tor. You aren't going to swallow CDs or even SDs, that's obstruction and destruction of evidence. If the storage media holding the tor executable is encrypted you haven't solved anything. You'd have to download tor itself, anonymously, into RAM - without having Tor available. That's simply impossible. The goal of the proposed enhancement is primarily protecting communication data.
    • (adrelanos) To get both: we could simply start Tor with new entry guards, download our old Tor cache from a hidden service storage (stored there in encrypted form), decrypt, put in cache, restart Tor, use old entry guards. That's probable difficult to implement. But a worthy goal. That anonymous encrypted storage could also contain other configuration files and hidden services.
      • (anonymous) If that's built into Whonix the next question is going to be: give us the key to your "cloud". The entry guards are not the problem, they are pretty public (ISP/VPN sees them), we can store them unencrypted (or encrypted and hand out the keys). I'm only worried about cache files that could reveal whole circuits or even destination addresses. Tor devs would have to fill us in on the details here. Entry guards are only a protection against weak adversaries which usually do not have the legal and physical force that necessities such precautions. Strong adversaries already control or can monitor your permanent "entry node" (ISP), I'd guess they wouldn't care either way, if anything, more stable and predictable circuits make timing, end to end and tagging attacks easier.
      • (adrelanos) Recent discussion with better solutions: tor-talk Location-aware persistent guards
  • (adrelanos) You essentially propose Whonix to be Amnesic. There are different levels for being amnesic.
    • (adrelanos) One easy thing we could and should do either way: encrypt the USB HDD. People in sane areas who do not get forced to give out there passwords can not be proven, they have used Whonix. Those who have used obfsproxy or other means of hiding Tor use can not even be proven to have used Tor. Next points assume password has been given out.
      • (anonymous) In the standard Whonix encryption is already recommended and left to the user (as we do not control the host OS). It can also already be installed to external medias without having to change anything. (SD, USB, eSATA)
      • (adrelanos) If we are going to deploy a read-only medium, we should probable deploy the whole host and apply encryption by default.
        • (anonymous) Uh, I think you will notice that is impossible. One can't preinstall a "secret" key...
        • (adrelanos) Only option: Doing it like the Tails USB creator. An installer creates and encrypts the device.
    • (adrelanos) We can prevent getting any activity in Whonix-Workstation to be ever written on disk.
      • (anonymous) unless enforced by hardware, software can still circumvent software write blocks. Whonix threat model includes remote code execution as root. SD cards have a write lock, CD/DVD-R are save too. For everything else you'd need something like tripwire from a trusted medium.
      • (adrelanos) No. Only Whonix-Workstation is not to be trusted in our threat model. The Whonix-Gateway and Whonix-Host are trusted. If they enforce, that all written changes go to the RAM, no read-only hardware is required. (Although recommending read-only devices for a defensive in depth is a good idea.)
        • (anonymous) I', talomg about Physical Isolation. The VM based isolation between Host and Workstation is weak. If the latter is compromised the former can be relatively easy too. The notion untrusted is not really accurate any more, it's more of a security redundancy: still offer security if one of the two is comromised (I'll expand on that on the security page, essentially neither T-G nore T-W are fully trusted or untrusted, it's more like 50:50). The host is a bit more trusted and should guard hardware serials but that's it. Offering a tamper resistand host is still very desireable.
    • (adrelanos) We can prevent writing to the whole USB disk (once installed) and hide (from local hdd analysis (!)) Whonix ever got started. (This disables Tor cache and entry guards! Unless we use the workaround I described above.)
    • (adrelanos) We can also torify the Whonix-Host traffic to prevent any kind of Whonix-Host specific network fingerprint.
    • (adrelanos) Conclusion: if we include all those levels... When they use obfsproxy (assumed it does its job or other means), they can use all features (entry guards, hidden services), it can not be proven they used Whonix/Tor and if they reveal the password it only proves they installed Whonix at some point.
      • (anonymous) It's in the name, "obfuscation", it's not a "stegoproxy" (which I doubt is possible at all for bi-directional channels). All the schemes to hide the fact that you use tor are weaker than tor itself. Against strong adversaries they can only help with your perceived security (false sense).
      • (adrelanos) obfsproxy is not perfect. If it were easy to detect, hosting Tor based on private obfsproxy bridges were pointless, but it's not. There are great developments in this area, like SkypeMorph or the system, where the webserver/ISP helps, connection looks like normal http, unfortunately forgot the name. Kinda perfect stenography. That's up to the obfsproxy/transport plugin people. Talking about strong adversaries makes no sense, you could argue that whole Tor has no point then.
        • (anonymous) Yes, that's my point. My personal interest in Whonix is fixing that... (see Security page). Something like SkypeMorph is a lot more interesting than the obfusproxy (although skype crypto is broken so the implementation is broken too and there's ample room for timing and traffic ananlyis that would probably reveal it's hidden use). However, such methods require a friend to friend network (like Freenet darknet), there is no such infrastructure for Tor yet - though there is no reason it wouldn't work. The real problem is, you are hiding traffic in encrypted traffic. In restricted environemts all encrypted traffic (but whitelisted destinations like banks and .gov) may be blocked completely. A strong stego solution should still work, e.g. post to flickr, youtube... but such methods are always high latency and one-directional and therefore incompatible with Tor.
        • (adrelanos) If I understand correctly, skypemorph could also be implemented as a plugin for obfsproxy and if not, obfsproxy needs to be updated. See https://www.torproject.org/docs/pluggable-transports.html.en for even more stuff in development. I don't find the another promising one again, it would look like you connect to a legitimate website (anypage.com) and with help of the website server's ISP providing stenography and some magic you get forwarded to the Tor network. If I remember correctly it required some ISPs (or websites) to cooperate.
  • Latest statements: https://sourceforge.net/p/whonix/wiki/FAQ/#will-there-be-a-whonix-live-cd-or-dvd and https://sourceforge.net/p/whonix/wiki/FAQ/#is-there-something-like-whonix-live

[SECURITY] VirtualBox replacement: Xen, KVM, libvirt [OPEN]

  • (anonymous) Ubuntu/Linux has been "rock solid" for me, except for the occasional kernel panic caused by VirtualBox. And where there are bugs, there are security bugs. Xen is definitely capable: http://wiki.xen.org/wiki/Host_Configuration/Networking and we could borrow from Qubes-OS (which probably is the most similar project to Whonix in terms of threat model and design). I'd put KVM as the second choice, we are already far too reliant on the Linux kernel (i.e. single points of failure) and it doesn't help with reducing the TCB. But both are stop gap till something like Genode.org becomes usable.
  • (adrelanos) I agree, in long term we have to move away from Virtual Box. The VirtualBox Kernel Driver Is Tainted Crap says everything about their skills. After all the years they still require re-compilation of modules if the kernel has been updated. Imagine there was a kernel update and Virtual Box can no longer be started, iirc that happened in past. Although they have a good feature set and user interface.
  • (anonymous) Actually recompiling is necessary because it's out of tree. It's out of tree because the kernel driver is crap.
  • (adrelanos) If we switch to Xen or KVM we loose support for hosting Whonix on top of Windows. That would cost a lot users.
    • (anonymous) users who don't really need Whonix, or they wouldn't even think about hosting on a proprietary system that phones home with hardware and serial numbers. The "switch" can be optional or additional too.
    • (adrelanos) Every Windows user is at least a user compared to no user. As I often said, last time under "better Marketing", more users leads to more reviews, more press, more developers, more progress etc. We easily disposed Windows as build platform, let's not easily dispose it as host platform. People start mostly with Windows and somtimes switch to Linux when they get to know it over time. Most Tor users are probable Windows users but everyone is required for a good anonymity set.
  • (adrelanos) The createvm script contains within the functions general_setup, gateway_specific and workstation_specific the commands, which Whonix depends on. Some are unusual and might be unique to Virtual Box, such as synthcpu and GetHostTimeDisabled (no ultimately complete list).
  • (adrelanos) Not really what this ticket stands for, but... Rudimentary Support for Whonix in VMware has been documented.

Xen […]

  • (adrelanos) We have to research, if Xen is really suited for Whonix. How long will Ubuntu/Debian support Xen? In past I read that it is "somewhat difficult to integrate Xen into a distro". It were stupid if we move to xen and then everyone dropping xen.
  • (anonymous) Xen is "industry standard" see xen.org for who is using it... It won't get dropped, there's room for more than one. http://wiki.xen.org/wiki/Category:Ubuntu
  • (adrelanos) virt-manager is the only graphical user interface I've found for Xen. A desktop operating system over VNC is a real blocker. It works but is tiresome and any kind of multimedia does not work well either. Do we agree, that we need a replacement for VNC? We can try out SDL and see how 2D and 3D performance is. There is also Xen VGA Passthrough for full 3D, but I am not sure if it were secure.
  • (adrelanos) See Qubes OS.

Qubes OS [OPEN]

tar -xvf Whonix-Gateway.ova
Whonix-Gateway.ovf
Whonix-Gateway-disk1.vmdk
  • (adrelanos) Open questions... How to convert the .vmdk to Qubes OS (Xen) compatible images?
# qemu-img info Whonix-Gateway-disk1.vmdk

qemu-img convert Whonix-Gateway-disk1.vmdk -O raw Whonix-Gateway.img

# qemu-img info Whonix-Gateway.img
  • (adrelanos) Can .img images be used inside Qubes OS or do they use some other format? I expect them to work.
  • (adrelanos) How to create the VM description file with internal network?

KVM [OPEN]

  • (adrelanos) KVM is good because it's in the kernel.
    • (anonymous) KVM is also bad because it's in the kernel. see qubes-os docs for why they chose Xen over it.
      • (adrelanos) So it will be Xen...
  • (adrelanos) Which user interfaces exist?
  • (adrelanos) We should make a list off all features we need from KVM backend and from user interface (virt-manager). List the missing pieces. Track/create (if not already) the approprieate bug reports and feature requests.
  • (espes) Note 'KVM' can refer to just the kernel tech or qemu-kvm, which was a fork of qemu using the kernel driver but has recently been merged into mainline qemu.

Qemu [see status]

  • (adrelanos) STATUS: Unless someone researches it, not going to happen. If someone finds out documents will be gladly added. Default Virtualizer will stay Virtual Box. Might accept alternative Qemu builds if someone willing to maintain those builds. Open for development discussion. An anonymous user reported in the forum, that it's working.
  • (espes) Slow (but fast enough?, self-contained, portable) without optional KVM backend.
    • (adrelanos) Needs Testing. Maybe fast enough on fast systems?
  • (espes) Probably more secure than VirtualBox (no rotten kernel module)
    • (adrelanos) How does the Accelerator KQEMU affect security?
    • (adrelanos) How is public scrutiny compared with Virtual Box? Do they have any enterprise or any other kind of customers?
  • (espes) Probably less secure than a hardened bare-metal hypervisor (Xen, ESX, etc)
  • (adrelanos) Deployability? How difficult is it for users to download and install everything?
  • (adrelanos) Usability? How difficult is it for users to start, stop (, clone, delete, import, snapshot) the VMs? Graphical user interface?
  • (adrelanos) Implementation: the Whonix build process initially create .img images, which seem to be useable by Qemu. There is not so much left to support Qemu. Only the start command telling how much ram, which image to use etc. I think the most difficult part could become configuring the internal network between WG and WW.
  • (adrelanos) General advice when trying to develop this: Try first to get an internal network without using Whonix, afterwards(!) apply the things you learned to Whonix.
  • (adrelanos) Term for search engines: qemu internal network
  • (adrelanos) Might be related: https://blog.cryptomilk.org/2007/07/12/qemu-kvm-internal-network-setup/

libvirt [IMPOSSIBLE]

[SECURITY] Wipe RAM panic script [OPEN]

  • (adrelanos) We recommend Linux for the host anyway. We also should provide and recommend a panic button. Upon pressing the panic button, the content of the RAM has to be securely wiped. (To ensure that any full disk encryption keys from RAM are lost and cold boot attacks are impossible.) Tails and Liberte Linux implemented it.
  • (adrelanos) How I wish it to work: you start the script shortcut on the host, ram and master keys get deleted, system crashes, clean shutdown takes too long. Resources: arch forum; google: site:www.saout.de/pipermail/dm-crypt/ cold boot attack ; tails
  • (anonymous) Tails and Liberté use kexec, they've researched it and I think we should follow. Both could be faster but they are the most thorough, erasing even most of the kernel memory. If the hardware supports it: http://www1.informatik.uni-erlangen.de/tresor
    • The idea is nice. It's only a kernel patch. If it doesn't get supported upstream it's a bit difficult to make use of as kernel is updated.
  • (anonymous) Tails and liberte do it differently and a quick glance over their sources didn't make it obvious to me how to make a simple stand-alone implementation. I could need help here.
  • (adrelanos) Difficult to understand and implement for me, as it needs a custom initramfs and I haven't learned that yet. And we should recommend to implement it on the host, not so much point implementing it in VM. Tails implemented quite nice features, they always wipe at normal shutdown and also have panic key (bootmedium removed). The latter may not be possible for use (may be installed on internal hdd), therefore we should provide a panic button/script. Also here it would be better, if that feature were supported upstream "apt-get install wiperam" or something like that. Maybe it would help if there were a real project, someone else proving a project for this - haven't found one yet beside a lot forum discussion.
  • (anonymous) check gentoo and arch wiki for how to do things manually in linux. Ubuntu/Debian automate a lot of tasks but when you are trying to do custom things they often get in your way and make it more complicated. We should ask Tails if they are interested in upstreaming their work or releasing it as a standalone .deb. After all this isn't just useful for Tails and other Tor projects but everyone who uses FDE.
  • (adrelanos) Tails-dev Ram Wipe Script Upstream, any progress? Bad news. "No progress so far. It's still in my low-priority personal todo list." ... "But anyway, given the current state of relative brokenness of this feature, I'd rather see it *fixed* first, else it does not make sense to seriously talk about packaging."
  • (adrelanos) It's a part of host security. Nothing we have to solve. Adding some hints to hardening.
  • (anonymous) this is important, let's fix this. Since there's been zero progress, we need to make more noise...
  • (adrelanos) I don't feel I am skilled enough to implement it myself. This issue has not been fixed by the whole security community. I wouldn't know how we could. It's not related to Whonix, it's interesting for a much wider community using FDE. Dunno why such great things like wipe ram script and TRESOR are not already in upstream. Making noise... Well, good idea, we can post a feature request to Ubuntu Brainstorm, ask askubuntu, ask serverfault, Update: superuser.com. One at a time. Let's prepare a message. Update: Please edit the message at will. If it's done I'll post it, post a link here and delete the draft.
  • (adrelanos) Update posted first one: http://askubuntu.com/questions/153245/how-to-wipe-ram-on-shutdown-prevent-cold-boot-attacks
    • (adrelanos) There has been an answer. Looks somewhat too small/easy. Btw: there is no registration required.
      • (anonymous) It doesn't free any kernel memory as booting into a new small kernel via kexec which is what Tails/Liberte is doing. Still, much better than not doing anything.
  • (adrelanos) I think this one will be a hard one, if no one from Tails or Liberte Linux implements it. Most people in the forum discussion have not really seen the cold boot attack demonstration and don't know how long contents of the RAM can really be extracted. Therefore most people argue that this feature is nonsense. And if the undecided ones google, they find old discussions prior the cold boot attack demonstrations and think it's pointless. We really gotta ask a good questions to attract interest.
  • (adrelanos) Moved to non critical tasks due to lack of discussion and since it's not really the core of Whonix. Encryption is host security, we recommend it but are not an encryption project. Don't worry, after 0.2 we can continue making noise by posting it somewhere else.
  • (adrelanos) Waiting for result on http://security.stackexchange.com/questions/18975/wipe-ram-on-shut-down-to-prevent-cold-boot-attack and finally maybe posting on Ubuntu brainstorm.
  • (adrelanos) http://brainstorm.ubuntu.com/idea/30076/

CLOSED TASKS

Can be moved soon into the archive.

More closed tickets…

Most closed tickets already have been moved to the Archive.

[SECURITY] flashplugin-nonfree get-upstream-version.pl security concern [DONE]

[SECURITY] [PACKAGING] Empty Tor Package [DONE]

  • (adrelanos) Create an empty fake Tor package with no content. It's useful for example to satisfy TorChat dependencies, who knows which else and to prevent some cases of Tor over Tor.
  • (adrelanos) Done: https://sourceforge.net/p/whonix/wiki/DummyTor/

remove wpolipo [DONE]

  • (adrelanos) Remove wpolipo. Put wpolipo in it's own git repository. Not in use for anything. When discussing wpolipo, privoxy was rather recommend. So perhaps create wprivoxy? -> New ticket.
  • (adrelanos) Done. It's still inside but does not do anything because no ports are defined.

[SECURITY] Include rawdog to fetch Whonix News (Blogs) [IMPLEMENTED]

  • (adrelanos) Related documentation: rss.
  • (adrelanos) rawdog (available in Debian repos) should be included to fetch Whonix News (Blogs), because it has no cookies, no scripts, thus no fingerprinting issues and it can run through SocksPort (stream isolation) using uwt wrapper. It basically fetches rss, creates html files. Those html files could be opened by default when Tor Browser gets started.
  • (adrelanos) Done in untested_adre git branch will come in 0.5.x.

[INFRASTRUCTURE] Our bug tracking system [WEBSITE] [ANSWERED]

  • (anonymous) It's getting messier all the time, our high level tags don't make sense for everything. Links break constantly whenever tags are added/changed, the TOC truncates titles so we can't search tags quickly for an overview. I can't think of a simple workaround, we need a real bug tracking system eventually.
    • (adrelanos) Yes. We'll get one with (trademarkdomain user disappeared). I don't know any temporary fix. Should we ask tpo if they give us a trac component? A good temporary solutoin should be able to be easily imported to (trademarkdomain user disappeared).
  • (anonymous) For now, I want to deprecate the wait category because it's not really meaningful. tagging for Whonix releases is much more useful. Another thing we could do is to add category/release tags in front of the titles. Status tags can remain where they are. What do you think?
    • (adrelanos) You made some valid comments to the waiting tickets. I'll answer them and answer again here.
    • (adrelanos) You can tag like crazy. :) It won't help me, it won't hinder me. Feel free. For example time sync can be tagged as Whonix 0.2.0. I can't get it done in time so or so. I don't think removing the waiting category is of any help, but you are free to do it as well. If you feel better, if it helps the workflow, why not.
    • (adrelanos) Ok, after seeing it, I must correct myself, it's useful.
    • (anonymous) CLOSE? nothing we can do about till the domain is ready.

[SHELLSCRIPTS] Move to file separated source [INFRASTRUCTURE] [DONE]

  • (adrelanos) I wanted to propose that after Whonix 0.2.0 but I think it's perhaps better to do it earlier. With torcheck and the problem to escape ' within ' ' it demonstrates, were the limits with one big shell script per VM are. It's possible to correctly escape it, but that makes the source less readable. Other than that, there are currently only two people who read and edit the script, proper and anonymous. I won't go as far as saying others can't understand it, but the effort must be high to get into it.
  • (adrelanos) I propose moving the files, i.e. the ones we paste using for example echo '...' > /etc/tor/torrc to separate pages/files. Not sure if that also hits the borders of "wiki development" or if something like git is required.
    # Not complete yet, only for demonstration.
    ~/torbox_source_0.2.0/
    ~/torbox_source_0.2.0/tor-gateway.sh
    ~/torbox_source_0.2.0/tor-workstation.sh
    ~/torbox_source_0.2.0/tor-gateway/etc/torboxfirewall.sh
    ~/torbox_source_0.2.0/tor-gateway/etc/tor/torrc
    ~/torbox_source_0.2.0/tor-gateway/etc/resolv.conf
    ~/torbox_source_0.2.0/tor-gateway/usr/bin/leaktest
    ~/torbox_source_0.2.0/tor-workstation/usr/local/bin/uwt
    ~/torbox_source_0.2.0/tor-workstation/usr/local/bin/apt-get
    ~/torbox_source_0.2.0/tor-workstation/usr/local/bin/gpg
    ~/torbox_source_0.2.0/tor-workstation/usr/local/bin/...
    # HARDCODED!
    ~/torbox_source_0.2.0/tor-workstation/home/user/.gnupg/gpg.conf
    ~/torbox_source_0.2.0/tor-workstation/home/user/.config/openbox/menu.xml
    ~/torbox_source_0.2.0/tor-workstation/usr/bin/arm.sh
    ~/torbox_source_0.2.0/tor-workstation/etc/network/interfaces
    
    # Perhaps there is also some shared code? Like delete_logs.
    ~/torbox_source_0.2.0/shared/delete_logs
    
    • (anonymous) I'd go with a "build_torbox" script in the root which creates tmp build directories and calls the other scripts, then sub-dirs for t-w and t-g and shared. We need separate scripts for building the basic debootstrap chroots and converting to VMI, configuring the chroot and finally to create the Vbox VMs.
      • (adrelanos) I guess VMI=VDI (virtualbox disk image)? Otherwise sounds good. The "build_torbox" script should support "build" and "clean" (delete temp dirs). Perhaps also do only one build step and/or repeat another one to ease debugging.
  • (adrelanos) Perhaps https://trac.torproject.org/projects/tor/wiki/doc/TorBOX/torbox_source_0.2.0/ or https://trac.torproject.org/projects/tor/wiki/doc/TorBOX/Dev/torbox_source_0.2.0/, i.e. https://trac.torproject.org/projects/tor/wiki/doc/TorBOX/torbox_source_0.2.0/tor-gateway/etc/torboxfirewall.sh.
  • (adrelanos) Not sure how to handle the >> files. To get this started we could still leave them in the tor-*.sh scripts.
  • (anonymous) Absolutely. But we need something better than trac to handle them, i.e. git. When (trademarkdomain user disappeared) comes online we could use a self hosted one like Tails does, or we use github (like Liberte).
  • (trademarkdomain user disappeared) Yes, I'm happy to implement an installation of Git on the (trademarkdomain user disappeared) server for our dev needs.
  • (anonymous) Great!
  • (anonymous) As long as we have no source repository we should keep as few scripts as possible for obvious usability reasons. Right now we have 5 scripts (t-g, t-w, t-debootstrap, t-chroot, torcheck). Any more absolutely required?
  • (adrelanos) Agreed and dunno for now.
  • (anonymous) 7 now, collected here: https://trac.torproject.org/projects/tor/wiki/doc/TorBOX/Dev#OurShellscriptsandBuildDocumentation
  • (anonymous) CLOSE? nothing to be done right now
  • (adrelanos) Done in github devel branch.

[FEATURE] Feedback collector [ANSWERED]

  • (adrelanos) We could add a small application on T-W where the user would only see a small text box and a send button. The feedback would be send to us. E-mail would make sense, but any other suitable method will do. There are open questions about user privacy. Should we encrypt that message? Should we normally send over the Tor network or should we add another layer of protection such as remailing? Or simply send over Tor and tell the user to switch circuit afterwards? How do we answer the users? Are there existing applications for this task or would we have to develop it ourselves? Does this make sense at all?
  • (anonymous) I really think that's overkill neither Tor nor Ubuntu has that, why should we - we just configure the two?
  • (adrelanos) Agreed. Update: Reopened. We have 173 download of Whonix 0.1.3 through sourceforge.org and barely any user feedback. Tails has [whisperback, you can see it in action if you get a recent Tails version. Unfortunately, whisperback requires a SMTP relay. Apart from that, they have a git repository for whisperback and after changing the messages, it could be used as a drop in replacement (still needs more research).
  • (trademarkdomain user disappeared) A feedback collector is a good idea. However, I think doing it over email is a bad idea. This increases chances of interception and it makes it very hard for all developers and/or community to receive & review the feedback. I think the best way to implement it would be via HTTP through the (trademarkdomain user disappeared) website, where it goes into the database. I assume that there would be an obmenu item to initiate the feedback form. Either we could have a form on the desktop submit to a (trademarkdomain user disappeared) processing script in the background (extra feature development & maintenance), or we could simply open up a standard feedback webpage on the (trademarkdomain user disappeared) website in the browser that everyone uses, whether coming from the desktop or web (simpler, one unified solution to maintain & pull from). Also, by launching a webpage in the browser, people can have more certainty about where the feedback is going, compared to an uncertain form overlayed on the desktop that goes out into the ether. So, I'd probably vote to simply open a standard (trademarkdomain user disappeared) feedback webpage like that. Could be done via SSL or Hidden Service in the TorBrowser.
  • (adrelanos) About interception: I was going to ask if we could host a hidden mail relay (only relaying to (trademarkdomain user disappeared), no outside targets). That way no interception is possible. I was only going to ask, if I would not have found an alternative to the mail relay. I was thinking about using remailers and encrypted posting to usenet. Whisperback from Tails looks very pretty, here is a https://tails.boum.org/doc/first_steps/bug_reporting/whisperback.png screenshot]. Thanks for joining this thread. Most features can be implemented over http and a hidden service. I think the Tails threat model for having an application for that is, that not even the server host can read the gpg encrypted reports. (The "add gpg key" field is allow the Tails developer to send back an encrypted answer.) Not sure we have such a threat model? If we had we could gpg encrypt inside the browser using a locally stored website. Most discussion should got into public areas anyway.
  • (trademarkdomain user disappeared) Hmmm... Interesting. I like the idea of initiating feedback from the desktop, even if just linking to the website. However, I don't like the idea of doubling the infrastructure of an issue tracker, both for the double maintenance as well as having similar types of postings end up in two separate systems/places. So, to me, it seems more ideal to somehow integrate this desktop feedback into the central issue tracker system. This would also likely allow for better inter-developer workflow for processing the feedback properly (every approved developer gets to see it, no overlapping responses, accountability for responses, etc). Beyond integration with existing issue tracker infrastructure, the challenge seems to be handling private non-public feedback/issues, and secure notification/transport of responses for private feedback/issues. So, overall, ideally looking for... Tracker Integration + Shared Developer Processing + Private & Public + Secure Transport. Does this sound accurate?
  • (trademarkdomain user disappeared) And, if so, is private feedback/issues that important, if we can offer anonymous public feedback/issues?
  • (adrelanos) Yes, having two systems sounds complicated and I am not sure we have the manpower yet. Let's make it easy but at least make it. One website, one issue tracker, one forum, one wiki, done so far. A website link can still be added, but it shouldn't encourage posting duplicates. If anyone really needs encrypted bug reports, they can mail be personally using my gpg key, I don't expect that to happen often.
    • (trademarkdomain user disappeared) Agreed.
  • (adrelanos) Tails reason to have the feedback collector as application is sending anonymized hardware data to Tails develoeprs and not to the open public. Since Whonix delegates hardware support to the host operating system and does not have so strong requirements to safe space and kernel modules, it might not be necessary to use their tool.

[BUG] uwt wrapper localhost connections broken [FIXED]

  • (adrelanos) I deactivated the wget uwt wrapper, because connections to localhost were broken. That may not be needed often, but if so, it leads to errors where the source is hard to find. The same goes probable also for the ssh wget wrapper and perhaps others.
  • (anonymous) can't we add an exception? "IF localhost use wget, ELSE use wrapper"?
  • (adrelanos) Good idea. I added an check not to use torsocks when 127.0.0.1 or localhost is inside the parameters.
  • (adrelanos) Not sure if anything else is still broken. uwt might still not be a generic solution for applications which internally decide to connect to localhost, not sure if git does this.
  • (adrelanos) Removed [0.2] tag until I or someone else finds a new issue.

[BUG] [SHELLSCRIPTS] default color profile for gnome-terminal [FIXED

  • (anonymous) It currently defaults to black fonts on black background, not good.
  • (anonymous) I'm thinking of replacing it with xterm, the other terms just always suck one way or the other. gnome-term is nice, good features, but slow and got a horrendous config system. ~/.Xdefaults for xterm, run "xrdb .Xdefaults" to apply. xterm isn't "user friendly", but anyone who uses the terminal should be knowing what he's doing anyway. But at least copy and paste should be a bit more obvious for windows/mac users... If someone fixes the gnome-term .config that would be appreciated.
    xterm*background:   white
    xterm*foreground:   black
    XTerm*utf8: 1
    XTerm*eightBitInput: false
    XTerm*eightBitControl: false
    XTerm*eightBitOutput: true
    
  • (adrelanos) I am happy with any quick fix for Whonix 0.2.0. xterm lacks features, such as an tabbed interface but it's ok. The geeks are free to install a replacement.
  • (anonymous) so xterm config doesn't really work as I hoped either. It's going to be urxvt, if only temporary (apt-get install -no-install-recommends rxvt-unicode)
  • (anonymous) workaournd implemented but ticket is not solved, urxvt is no replacement for a user friendly terminal that at least supports copy and past with mouse context menu (and tabs would be nice too).
  • (anonymous) I think the roxterm segfault has been fixed in precise. If it's stable we got our replacement!
  • (anonymous) roxterm still crashes, so does terminator. Gnome-terminal is still the best option.
  • (anonymous) right now, it defaults to xterm, even with urxvt installed. UPDATE:or not
  • (adrelanos) Please try:
    USERNAME="user"
    sudo -u $USERNAME gconftool-2 --type string --set /apps/gnome-terminal/profiles/Default/foreground_color "#FFFFFFFFFFFF"
    
  • (adrelanos) Already added to the script. If it works for you, we can close this one.
  • (adrelanos) Unfortunately will not be fixed in [0.2]. When I found the command above it worked, but it didn't work within the script. Maybe gnome terminal has to be started at least once, closed and then the command will have an effect. Needs testing.
  • (adrelanos) Not one gconftool-2 command is required, it's three. Hopefully fixed in latest git devel branch.
  • (adrelanos) Now fixed, because no longer using Openbox.

[SECURITY] [ENHANCEMENT] Switching Operating System [DONE]

  • (anonymous) why would this benefit us:
    • the ova is about half the size!
      • (adrelanos) Interesting...
    • Debian uses validuntil in apt, for T-W this isn't problematic because a evil exit can't persistently prevent you from updating.
      • (adrelanos) Valid, important point.
    • Tor/Tails/Torouter all have an affinity to Debian
    • Makes Whonix more diverse and harder to exploit both at the same time
    • we could use debdelta, and Debian likely will get delta updates before Ubuntu
      • (adrelanos) Do we need that? T-G can make updates over apt-get in clear anyway (beside the hide Tor usage people).
  • Cons?
    • Security: Debian Squeeze doesn't offer much security features compared to Oneiric but for T-G it doesn't matter: Tor itself doesn't make use of compile time hardening and all we care about is whether tor can be exploited or not, additional root or kernel exploit is meaningless for our threat model.
    • (adrelanos): Once I check Debian, the standard installation has open ports, that is very disgusting. I am also not aware of any minimal/server distribution. We also care if iptables can be exploited but I haven't checked if that was compiled with hardening features on Ubuntu. And I also don't know if explicitly the kernel could be exploited or if only the Tor/iptables code is involved.
    • (anonymous) Debian has a minimal server install, of course no open ports. I used the "Expert Install" and the installation process fits our requirements better than Ubuntu. I used http://cdimage.debian.org/debian-cd/6.0.4/i386/iso-cd/debian-6.0.4-i386-netinst.iso
      iptables is part of the attack surface, but it's not far fetched to assume that this is one of the most scrutinized and audited parts of the kernel. Also, Ubuntu security features are largely user space, except for some grsec based patches. But unless you really use a full hardened kernel this doesn't make that much of a difference. Ubuntu and Debian kernel are both "easy" to attack compared to a grsec kernel and if ( a big if I hope) there's a vuln in netfilter either will be reliably exploitable, grsec only maybe. (In case it wasn't clear, iptables is just a front end, the firewall and networking code is a part of the kernel)
  • (adrelanos) Every day for a few moments I think about switching to BSD or some specially hardened Linux Distro. =) Seriously. I am always looking for the most secure thing. You think that is feasible? Anyway, your answers make sense. Since you do most of the work for the binaries, it's your decision. I am NOT against Debian. After all in a minimal installation the difference to Ubuntu is minimal. All online support for Ubuntu does most of the time also apply for Debian.
    • (anonymous) I'm strictly against using OpenBSD (security updates are painful enough but they aren't signed, that makes this OS completely unusable in our threat model). Let's revisit this when Wheezy comes out which hopefully closes the security gap with Ubuntu.
  • (adrelanos) What about Hardened Gentoo? (Liberté Linux uses it.)
  • (anonymous) answered here: https://trac.torproject.org/projects/tor/wiki/doc/TorBOX/SecurityAndHardening#WhonixThreatModel Would be nice but too much work. I looked into using the liberte scripts but that still would result in a "deployment only" image, i.e. live cd/usb +persistence - no security updates available except for downloading and installing a new image. We can't support that (releases would have to happen about 1-3 a month). Alternatively building images with emerge available: kernel still needs to be compiled manually from hardened-sources, that just sucks and glsa doesn't notify about kernel vulns and updating non-kernel packages with emerge can't be compared with apt-get or windows update, you need to read the warnings and notes, update /etc, sometimes things fail (portage snapshot signature, compilation, perl, python, gcc updates can be non-trivial...)
  • (adrelanos) Ubuntu dropped support for non-PAE CPU's. It's about time to switch the operating system. Otherwise people with older hardware are unable to use Whonix 0.2.0.
  • (anonymous) CPUs not having PAE probably won't be able to run two VMs with acceptable speeds either... I don't think this got high priority. Revisit when wheezy comes out, I don't know of any other option that fits all our feature and security requirements.
  • (adrelanos) Will be still a long time until wheezy comes...
  • (adrelanos) debian.org/CD/verify How would we get the signing key for the iso releases? Update: no regular way. Really. Other than meeting the devs in person. For squeeze I found an awful workaround:
    # Tested on Ubuntu Precise.
    apt-get install debian-keyring
    gpg --homedir ~/gpg_debian --import /usr/share/keyrings/debian-role-keys.gpg
    gpg --homedir ~/gpg_debian --verify SHA512SUMS.sign SHA512SUMS
    sha512sum debian-6.0.5-i386-CD-1.iso
    
  • (adrelanos) Not sure if Debian is the right choose. They don't seem to care too much about security...
    • (adrelanos) Virtual Box guest additions (OSE) are preinstalled on default squeeze installation. While I find this nice and convenient it does not suite our threat model. Shouldn't be of concern, since we install a custom system anyway.
    • (adrelanos) No TLS authenticated source for their CD signing keys. WOT (web of trust) only. It's a sink or swim.
    • (adrelanos) They recommend downloading Debian using jigdo. The jigdo homepage is a link to a third party. Nothing against jigdo noble efforts, but that page does not offer TLS or gpg signatures for jigdo. We don't have to use jigdo. This demonstrates bad security practices.
  • (adrelanos) Switched to Debian. Main reason were licensing issues with Ubuntu. On security page this is outlined in details.

[SHELLSCRIPTS] Ubuntu unattended (automatic) installation debootstrap vs preseed [DONE]

  • (adrelanos) That's the missing link before we can have fully automated builds. Looks feasible to implement for me.
  • (adrelanos) I found a tutorial, which is pretty straight forward, explaining how to install Ubuntu unattended. There is an updated Ubuntu 12.04 example-preseed.txt. Preseed is the recommend way in the Ubuntu 12.04 Installation Guide.
  • (adrelanos) Alternatively, there is also the FAI (Fully Automatic Installation) project, but the learning curve seams way too flat to me.
  • (adrelanos) Advantages of automatic installation:
    • (adrelanos) When it's done, it will be much easier, faster, secure and motivating to make new binary builds.
    • (adrelanos) More secure, because we eliminate the possibility to setup the wrong settings.
  • (adrelanos) Disadvantages of automatic installation:
    • (adrelanos) Who knows preseed syntax and unattended installation (possible less security reviews).
    • (adrelanos) Requires additional software for building Whonix, such as DHCP server, TFTP server. We have to configure them leak free: they may listen on localhost only. - If that's hard to configure, we simply use iptables as firewall and block all incoming ports. That may be unpleasant for people who want to build themselves and have server ports open. We recommend a dedicated build machine already.
    • (adrelanos) It requires the net installation (netboot.tar.gz).
    • (adrelanos) Optionally, hiding the fact, you are building Whonix could be difficult, when using netboot.tar.gz.
    • (adrelanos) More complex build script. It will be more difficult to manually build Whonix. After adding the command line commands for using VirtualBox by command line, it's already harder to figure out, which VirtualBox gui options to choose to do the same. Should we maintain two versions? Manual creation of VirtualBox VM's and manually choosing all options for Ubuntu installer?
  • (adrelanos) I'd like to hear some opinions, also open for alternatives...
  • (adrelanos) An alternative to preseed could be to manually create the image. Mount the image, chroot into it. I have no experience in that field. Dunno if that makes more sense. Debootstrap
  • (anonymous) I found no helfpful docs on how to do that. I don't know how it could be possible. The problem is we needed to directly access the virtual disk in order to install grub to it. The only way I found is to use a nother VM, mount the drive there and run grub-install. That doesn't really help us... The most promising option I think is to remaster the install CD to include a preseed file and auto start syslinux: http://g0blin.co.uk/programming/ubuntu-preseed-virtualbox-and-hetzner-eq4-virtual-machines/ We could already include the scripts too and copy them somehow to the target systems so we don't need ssh and port forwarding.
  • (adrelanos) Nice link. The most complicated thing with preseed.txt is getting the CD to read it. He remasters the CD instant of using a DHCP and tftp server. Tempting. I did already struggle with tftp package bugs and the DHCP/tftp setup is overly complex.
  • (adrelanos) grub-install should not be a problem. Linux is very flexible. With wubi you can even boot from NTFS (an image gets booted from a file, loop device). Once an image is mounted, there should be no relevant difference from a real hdd. UPDATE: Image generator example, looks easy.
    • (anonymous) I don't see how that helps with building a vdi from a chroot "folder", the OpenWrt-ImageBuilder archive already contains grub stages and squashfs and everything nicely prepared. The script itself may look easy at first glance but it's just a wrapper for the OpenWrt scripts. If we can mount the vdi from the chroot, that would work. But that doesn't seem possible (vdfuse is not in ubuntu); vditool is gone, qemu-ndb doesn't work for me. There most be a working solution... Another way would be to create raw or other image that can be mounted and then convert that to vdi. Update: got it working, nbd software was missing.
  • (adrelanos) We have several options. 1) Remaster the CD, 2) preseed 3) mount, Debootstrap/Multibootstrap or similar. We should compare simplicity, flexibility, leaks, distribution agnostic (easy switching to another distro), and which solution is the least hackish (also supported in a few years). If you could help with any of the methods, that were of course also a strong point.
    • (anonymous) remastering and preseed is distro specific but pretty much every big distro offers similar functionality. preseed with netboot just doesn't sound that secure, chrooting and building that way is the most flexible but definitely more complicated. It's also slow if done over Tor because it fetches everything via network each time you build it as opposed to use packages supplied by the install iso.
    • (anonymous) https://trac.torproject.org/projects/tor/wiki/doc/TorBOX/Dev/Debootstrap I have no further interest in messing around with GRUB, I spent several hours (testing it is a chore, even with VMs) on trying to get it working but to no avail. I think we need to look into transforming a loopback into a vdi but I don't even know if grub2 will handle that. I always just get "/dev/something does not have any corresponding BIOS drive." when running grub-install. Is there no frigging command line anymore? grub-legacy should work but I fear support is going to be dropped by most distros, If it wasn't for the updating issue I'd just go with syslinux and create isos,
      • (adrelanos) VBOX supports VDI, VMDK, VHD, and some HDD (forget about HDD) as disk file images. Perhaps this can be of any help.
  • (adrelanos) Maybe of any help: VMBuilder; Setup Tor DA with KVM; ubuntu-dev-week-vmbuilder
  • (anonymous) Didn't look into it (some links seem dead, vmbuilder only mentions KVM) but from http://ebroder.net/2009/08/04/installing-grub-onto-a-disk-image/ : "For various reasons, I wasn’t able to use the multitude of VM installers already out there, but one thing I noticed is that most of them don’t actually install a bootloader..."
    • (adrelanos) All links up again. Yes KVM and only less important virtualizers only. After switching to Virtual Box command line, I would rejoice trashing that work. But I'd switch to a better supported virtualizer anyway. KVM is build in linux kernel and more supported. We just haven't researched if it's suited for Whonix (hide hardware serials etc.). And also the userinterface virt-manager is not so pretty. Supports only VNC and no "direct output". Looks like KVM is more suited for servers but not as client operating system, browser through VNC is not so much fun.
  • (anonymous) Debootstrap can be used to build Vbox images but we need to investigate host related leaks. Liberte for example can apparently be built behind tor by setting a proxy variable (didn't test it, the whole build takes ages). Does that take care of resolv.conf, dhcp and so on?
    • (adrelanos) Very good questions. How will we find out? Shall we ask the debootstrap devs?
  • (anonymous) I don't like the idea of building vbox in vbox because of performance reasons but also how would one bootstrap such system? The very first t-w one builds needs to be built outside of a t-w...
    • (adrelanos) I understand your concern, those are valid. Performance is indeed poor. It's a real waste of time. Development were faster if they run faster. Bootstrapping is also complicated. The existing devs already have a working Whonix, but new ones? Two solutions: 1. we find a packager who does not require to stay anonymous (low probability) or 2. provide instructions to build a minimal build system manually (as we had in past). Update: Building manually will be easy as soon we move to more file separated source.
  • (anonymous) with debootstrap at least one doesn't have to run nested VMs for the heavy lifting. VBox is only needed for configuring the VM settings and then exporting the already prepared vdi.
    • (adrelanos) Yes. Good. Controlling things inside VBox would have been a mess anyway.
  • (anonymous) basics are done and working. Missing stuff: debconf dialog for certain packages, virtualbox scripting and export. that can all be found in TODOs directly in the script. ticket can be closed?
  • (adrelanos) I can't yet fully understand the new scripts you created. Not your fault! I just have to to read more manuals etc, there are a lot changes in a very short time. Thanks for that work. This is no criticism.
  • (adrelanos) That said, can you update BuildDocumentation as well? Imho now it's not clear how to build. I think the manual installation followed by a T-* script should be deprecated. BuildDocumentation should walk through the automated build method.
  • (adrelanos) I am not sure debootstrap is the right way to go. I spend hours without significant progress. There are too much strange bugs. /var/run not mounted on shutdown/restart (ok, thats maybe minor). dpkg-reconfigure -a hangs on adduser (can always press yes/no, but change will not be recognized). This bug is so seldom, you don't even find it on google. Even if reported, I expect it to be ages until fixed. We're attempting what vmbuilder did when jeos was still an active project. That project is now inactive and full of blocking bugs. (I couldn't get build virtualbox images, perhaps someone else can get it.) When the project was still current, they had way more developers (some with @ubuntu mail address). Debootstrap/chroot is (almost) equally hard as linux from scratch and this is far outside my skill set. ubuntu-vm-builder (python-vm-builder) also supports building kvm, vmware server, vmware 6 or xen images. Some of those formats are probable working better than virtualbox format. I tried building a vmware server image (vdmk) and simply used it for Virtual Box. I couldn't imagine that beside the disk format and the description file, the content of the image differs. That's wasn't a good hack either, also dpkg-reconfigure -a is broken and even apt-get update will show hdd kernel errors. Imho we can't do the "vmdebootstrap thing" our self. There are some alternative projects. https://gitorious.org/vmdebootstrap http://wiki-oar.imag.fr/index.php/Kameleon maybe others. I'd like to carefully choose the best one of them. I am willing to switch to KVM and/or Debian Squeeze (if in mid term update to Wheezy might work) right away if necessary.
  • (adrelanos) And even if we get vm-de-bootstrap or our own debootstrap or anything else running... It's still a custom hack. As soon the system makes any trouble you have some custom hacked up installation. Very very few people go this way = very badly supported, very hard to find solutions. Perhaps we should go back to preseed, that's virtually using the installer without user interaction. The system will be a "standard" one.
  • (adrelanos) I am trying this (with kickstart only, preseed might be broken for Ubuntu 12.04, still investigating). New plan:
    build script will run the following scripts... Easy to enable/disable steps for debugging.
    https://trac.torproject.org/projects/tor/wiki/doc/TorBOX/Dev/Build
    download and verify cd https://trac.torproject.org/projects/tor/wiki/doc/TorBOX/Dev/GetISO
    modify iso (preseed / kickstart) https://trac.torproject.org/projects/tor/wiki/doc/TorBOX/Dev/ModifyISO
    create vm / start vm / install vm (without network card) https://trac.torproject.org/projects/tor/wiki/doc/TorBOX/Dev/CreateVM
    mount virtual hdd / ChangeRoot / leave chroot / unmount virtual hdd
    https://trac.torproject.org/projects/tor/wiki/doc/TorBOX/Dev/ChangeRoot
    T-G script https://trac.torproject.org/projects/tor/wiki/doc/TorBOX/Dev/TGScript
    T-W script https://trac.torproject.org/projects/tor/wiki/doc/TorBOX/Dev/TWScript
    export vm
    cleanup/clean
    
  • (adrelanos) This is probable are more realistic plan and much easier to implement.
  • (anonymous) about dpkg-reconfigure: if you report such bugs on launchpad, I doubt you'd get much feedback. Debian cares a bit more and since it's the upstream for 'deb'ootstrap I think there are good chances it will be fixed. The debian iso as well as Ubuntu server are actually using debootstrap too... It's probably just some missing package. Nothing really broken either, the configuration is still set. /var/run could be a mtab/fstab problem. What other bugs are there? The debootstrapped images work, there can only be minor problems and they can all be fixed. Really, installing via iso and debootstrap is the same thing techincally. Just one of the two is muuuch faster.
  • (adrelanos) Dunno, don't remember very well anymore. The dpkg-reconfigure bug, the "console-utilities console-tools console-data something broken" bug, and 'locale' returned an error, "Scroll wheel in VM" bug. Perhaps that was it. Unfortunately, I really was unable to fix them. That's why I worked on the preseed method, btw I am almost done and can build and release them. Creating images with debootstrap without running something in VMs is certainly more elegant. Using preseed has the advantage that that VM never gets access to /dev/..., therefore less likely to leak information into VM.
  • (adrelanos) Removed [0.2] tag because I am going to release 0.2 using preseed method.
  • (adrelanos) I am currently testing Kameleon. Although it's from 2010, first impression is very good. Looks like it needs to run on Debian to create a Debian VM, but switching to Debian might be a good idea so or so.
  • (adrelanos) Another interesting similar tool for this purpose: Oz is a tool for automatically installing guest OSs with only minimal up-front input from the user.; Playing with oz-install; on github.
  • Done. Switched to grml-debootstrap/chroot. Perhaps in future to kameleon if the adduser bug with "dpgk-reconfigure -a" is gone.

[SECURITY] Setting correct time (NTP/HTP) [DONE]

Resources

  • (adrelanos) Just as collection of related links.

Liberté Linux

Tails

VirtualBox

Torproject mailing list

tlsdate

Authenticated NTP Guides

tlsdate

  • (adrelanos) Compiling is easy.
    git clone https://github.com/ioerror/tlsdate.git
    ./autogen
    ./configure.sh
    make
    make install
    
  • (adrelanos) tlsdate does not support connecting to hidden services, or are there any hidden services with SSL?

htp

  • (adrelanos) Unfortunately, there are no Debian/Ubuntu packages. The htp website has only incomplete with a selfsigned certificate. I downloaded it three times through different exists and each time got the same hash sums. The should make tampering by an exit node unlikely, but still the network before htp's webserver could have been permanently manipulated. We could compare the binaries/packages with Tails, since they also use htp. We could also compare the binaries/packages with the upstream distros, which include htp. Or we could download it from another distro as rpm and then extract or convert it, htp is simple, without lots of dependencies.
mkdir htp
cd htp

wget http://www.clevervest.com/htp/archive/c/htpdate_1.0.4_i386.deb
wget http://www.clevervest.com/htp/archive/c/htpdate-1.0.4.tar.gz
wget http://www.clevervest.com/htp/archive/perl/htp-0.9.3.tar.gz

sha512sum *
721423a92012dda1121257585f9f48149fcd51757fb9807a15af72606390bf99a30c1e047bf0f104d8b1eccc9d752aa64f1b41029a3044fd09508c47298481c0
  htp-0.9.3.tar.gz
1012412fd7475057f7489f69b41844b306d9bce411ff472a55c47237ae5776c4e49bf5aa1dbf1ab42bad6fee2d95f752092fc97529a69438e93b04ce339aad07
  htpdate_1.0.4_i386.deb
062d0fc9619312ad87dd0e508400bd6f3d64e0a7fab3bb58c55ccdbfb171030dc25f5909b0ca6d37b28e39eeb67c020e6b1c67017f8c16ef54c0e5f671bc2fb1
  htpdate-1.0.4.tar.gz

Compilation and installation is easy.

make
make install
  • (adrelanos) Tails uses forked version of htp. Search for git.

tordate by Tails

tordate by Liberte Linux

Whonix

Ubuntu

Discussion

  • (anonymous) TODO: We need to add a section about this to the main site. Having correct time is very important. Tor needs it to function correctly and on Tor-Workstation clock skew can be used for fingerprinting attacks. Usually VMs get the time from the host but there's a bug/issue with VirtualBox: when you pause or "save" a VM and later resume it the time will be off. Tor-Gateway can get ntp update without a problem but it seems you need to do so manually (run ntpdate-debian). On Tor-Workstation we can't use ntp because it uses UDP which is blocked. We could run an ntp daemon on Tor-Gateway but this increases attack surface, another option is to use htp (which needs to manually be installed through tor or offline). Best alternative: always shut down all VMs and rely on the host to keep correct time. Links: http://dee.su/liberte-security (toward the end of Network Security) and https://tails.boum.org/ikiwiki.cgi?P=ntp
  • (anonymous) time zone fingerprinting: should Tor-Workstation be set to UTC? Also: keymap fingerprinting. Belongs to Tor-Workstation installation.
  • (adrelanos) tails's solution
  • (anonymous) Tails has the requirement of not leaking clear text comms at all. We don't. We can't because host and gateway aren't torified. As long as we can trust our host (we have to) and its mechanism to keep the correct time we don't need to tackle this at all. There might be an interesting attack vector however: ISP level adversary can see we are using Tor and can see (I'm assuming this) unauthenticated ntp plain text traffic. He MITM's that to introduce an artificial clock skew. He also operates a bad exit/(web)server where he can read out local time of connected clients (JS injection, clear text time stamps...). Success. This is not a problem with TBB which takes care of that, but with other services (irc, mail?) and of course if he gets code execution on the Tor Workstation (this is within our threat model. Therefore we should use authenticated time syncing on the host or on *both* VMs. A cleaner solution is to do it in the VMs because it's self-contained. Virtualbox may override the guest time, it doesn't seem to without guest additions more tests would be necessary, maybe useful https://forums.virtualbox.org/viewtopic.php?t=8535 )
    Edit: After each shut down and consequent start up (but not after a restart), the time is synced with the host and the virtualbox forum thread found no solution to that either. On Tor-Gateway the time can be set before tor is started but on Tor-Workstation there is a time window where an adversary controlled time skew could leak. It would "only" affect the first 10 minutes at worst I think (after that a new circuit is built). Tails doesn't seem to take this into account at all.
    To sum it up, we have two options: authenticated htp on host or authenticated htp on both VMs. Any alternative, things I'm missing? I don't like it because there is no ubuntu package for tail's htp. I think the reasons for choosing htp over ntp apply to us as well. How bad is the clock skew anyway. Can't you just verify out of band (i.e. you mobile/radio clock)? Sub-second skew is unreliable because with clock drift it changes and second level can be verified with our human imperfection.
  • (adrelanos) ISP should be definitely part of our adversary model.
  • (adrelanos) I am not sure if we also should forbid non-Tor emissions, that'd be interesting for (follow up).... Therefore I created a new topic about this. If yes...
  • (adrelanos) Time synchronization should be anonymously routed through Tor, authenticated, best if encrypted (if possible), and rely on a massive amount of servers (no single point of failure).
  • (adrelanos) No solution should exclusively rely on the host and/or VirtualBox. Whonix may be installed on bare metal (physical hardware) as well, see front page for details.
  • (anonymous) why should we hide the fact that we update our time? We don't have (or can) hide that we are using a computer and it's only natural to want to use time servers. Only, if we use htp it would be a tell tale that we are using Whonix because AFAIR pretty much no one is using it. Maybe use HTP over TorSOCKS in Tor-Gateway? Tor would fail if host time is completely off but that's a pretty improbably scenario and can be fixed manually. I really wonder why OS vendors aren't interested in providing NTP with authentication (in a trustworthy, decentralized way), then this would be a non-issue. Think of it, you could use clock skew to make a revoked TLS certificate look valid (OCSP is broken). Successful forensics also often requires trusted time stamps, there clearly is demand.
  • (adrelanos) Why should we hide the fact that we update our time? -> interesting thread on the mailing list about this issue Authenticated NTP (after reading what Tails said) might not have enough (trusted) servers. The time problem is a real mess.
  • (adrelanos) I don't find the information again, but I saw somewhere on the Tor mailing list, that a future version of Tor will have a feature to request the time over Tor.
  • (anonymous) Too bad the question about possible risk went unanswered (the tails wiki about this doesn't quite convince me). I've tried tails_htp and it's a simple perl script with a ton of (mostly small) dependencies. There's a time out value (5 sec by default) so delay attacks are minimized by what damage they can do. It's crude. But as I asked above I don't know the real world implications of small time skews. Let's hope this problem is tackled in Tor itself because it affects all Tor users (including those using only TBB, if time skew is problematic wrt consensus replay). If it's not solved by them and small time skew is not a risk, we should do htp. Best over tor because exit nodes are less persistent than your ISP...
  • (adrelanos) Unfortunately Tails does not offer apt repositories (deb packages), that would be great, it's on their ToDo list but it's questionable if and when they offer it. In meanwhile we would have to advise the user to download htp from their site and install it manually.
  • (adrelanos) interesting thread on the mailing list about this issue click on "by subject", then you'll see that page. I missed it first, but there is an answer from Roger, perhaps we should rely on it.
  • (anonymous) The reply by roger to me says very clearly that this is not ready, not tested, less safe. We must be conservative and err on the safe side. The goal of Whonix is to offer stronger protection than Tails or TBB. I'm not sure about the whole htp approach either because it depends on TLS and TLS depends on a somewhat correct time too. Bootstrapping trust is always a very tricky problem. Think of what is the most trustworthy source of time? I think it's actually the hardware clock if it doesn't get changed by networked software without notifying the user... Better educate the user to check out of band with mobile/wrist watch to get an acceptable time (and more importantly date, for that he doesn't have to rely on any 3rd party) so TLS and tor can do their thing, for second/sub-sec skew htp is unreliable so we are still left with the unauthenticated ntp. We can't really do better than to wait for ntp auth to mature or for tor to tackle this upstream. I vote we tag this as (WAIT) and add a disclaimer on the front page.
  • (adrelanos) Yes, why do not let the user manually check and if needed adjust the clock. I asked on the list How accurate does need the clock to be?
  • (adrelanos) Does Ubuntu (full, not server) after installation use authenticated or unauthenticated NTP?
    • (adrelanos) Can't really believe it, but I found no reference, that Ubuntu uses authenticated NTP. This is a major hole, I think they want to defend against MITM, but as soon as NTP changes the date back, revoked SSL certificates can be reused.
      • (anonymous) No OS I know of uses authentication for time sync (neither free nor commercial systems)
    • (adrelanos) I thought about suggesting to use authenticated NTP on the host or Tor-Gateway. Here are one two tutorials how to use authenticated NTP. I have not found yet a list with public ntp servers supporting authentication. Because authenticated ntp is the exception, it would be likely, being a Whonix user, we should socksify it, when using on the host Tor-Gateway. But damn it, NTP can not be socksified, it needs UDP, which Tor does not support. So NTP does really not work here.
      • (anonymous) We can't do authenticated NTP and neither can Ubuntu or Tails. The client side isn't the problem. It's the servers. We'd need a pool of independent servers (to not place all eggs in one basket) and they need to be public and allow us to connect to them. Once the server side is up we can do NTP in plain text on the gateway (or host) with no problem (because then we wouldn't be the only ones using it) but unlike Tails on the Tor-Workstation we have no way to use NTP at all as you noted.
        Regarding the ML post, you should've asked how accurate it needs to be as in <5 sec. If that's no problem we can use htp (however, what about TLS needing correct time?). As an "interim solution" please have a look at my shell script.
  • (adrelanos) A helpful answer for my question.
  • (adrelanos) And a brand new solution - ioerror / tlsdate. I have not looked into it myself, just wanted to share the news.
  • (adrelanos) Liberté Linux, new for me, good first impression, also uses HTP, just sharing, also haven't looked inside.
    • (anonymous) thanks. If we set the time with tlsdate through a single exit node or directly through the ISP either may mitm attack with a forged certificate. What I'd like to see was tlsdate with monkeysphere, certificate pinning, convergence or something like that and a larger pool of queried servers. At any account, it's still called an experimental hack. If we don't want to not send it over tor we still have the problem of how the set the time before fetching the directory consensus. Again I'm left with the notion that the best thing to do is to set the date (and hour) manually with another clock, bring up Tor and then use an authenticated and decentralized method to set minutes and seconds. The sub-second skew apparently is of no concern because neither the htp nor tlsdate authors mentioned anything. Still, so far tlsdate meets these requirements best, but only as a secondary time source.
  • (anonymous) I think it's time to solve and close this ticket... --> (adrelanos) Agreed.
    • We need to WAIT for upstream (Tor) to really solve this in a user friendly way and tell us what is safe and what isn't. Until then we should: --> (adrelanos) Agreed.
    • 1) Disable ntp on all Whonix systems, it either is useless (T-W) or opens us up to attacks (Host, T-G). --> (adrelanos) Agreed.
    • 2) Advise users to manually make sure the time is correct. --> (adrelanos) Agreed.
    • 3) Optional step to use tlsdate/htp as a secondary source once Tor has started. On T-G we need to configure them to use the socksport. -> (adrelanos) Good.
    • 1) and 2) I could do right now (it's already in the shell script comments). For 3) I'd be inclined to wait for tlsdate to mature a bit more. I'm not comfortable recommending either (at least on T-G/host) for security reasons. -> (adrelanos) Okay, what about recommending htp from Tails?
  • (anonymous) ioerror didin't talk too favorably about it (https://lists.torproject.org/pipermail/tor-talk/2012-February/023275.html) and I tend to agree, hence no recommendation either.
    • (adrelanos) Good link. The author is one of the core people and he says "Tor users generally need accuracy to the hour in the local system clock." - Which means, we don't have t care about seconds.
      • (anonymous) As a response but also as a summary of the whole discussion (tl;dr)
        Tor needs hour level accuracy to work before tor is started (i.e. we can't use tlsdate/htp over tor to set the correct time for tor). For this we'd need a replacement for NTP. That's tricky because it needs to be 1) decentralised, 2) authenticated, 3) shouldn't make tor users stand out in ISP logs. Basically these requirements make an implementation next to impossible. The two solutions: a) our "solution" of manually setting the time according to a trusted source and b) Tor changes its design so it doesn't need a correct time to start working.
        We do need second level accuracy as well, to prevent fingerprinting. This can be done after tor has been started (i.e. we can use tlsdate/htp once they are stable and audited).
  • (adrelanos) Just sharing, no review. From Liberté Linux: "NTP is the only application that potentially must communicate in the clear — to a known server pool. NTP is not necessary for correct operation of Liberté, and it is currently turned off to prevent timestamp-based fingerprinting and MIM DoS attacks. Torified HTP adjusts the time very reliably — albeit with less precision. In general, Tor requires a correct computer clock to start up, but in Liberté this problem is circumvented using a consensus-based time estimate.".
    • (anonymous) As noted on the mailing list doing this has potential security implications (it eliminates one check that should certify the authenticity of the directory authority) and is therefore NOT recommended.
  • (adrelanos) Just sharing, no review. recent Tails discussion about this topic from 12 mai 2012.
  • (adrelanos) Tails-dev Why doesn't Tails use tlsdate? (htp replacement)
  • (adrelanos) Tails-dev Removing SSL CA dependency for HTP
  • (adrelanos) We should not turn off NTP on host. The ISP can see, that there is an operating system, which never performs updates, but never NTP, which is a lead for being a Whonix user. Also setting the clock out of band, and not using NTP, has another disadvantage. If the clock is too unique/fast/slow, it makes fingerprinting for Firefox or the Tor Browser Bundle on the host worse.
  • (adrelanos) We also should not share the very same time on Tor-Workstation, on Tor-Gateway and on the host. Javascript in TorBrowser is enabled by default can can read the users time up to the second. There major tickets against TorBrowser but I don't expect them to be solved anytime soon. The user might use the Tor Browser Bundle or Firefox on the host and websites might correlate users, seeing all instances share the same time skew.
  • (adrelanos) Reopened this one. At least for Tor-Workstation there should be a feasible solution.
    • (adrelanos) While fixing T-W, we assume, T-G is clean. We keep care about T-G afterwards.
    • (adrelanos) Note sure if this is needed: The VirtualBox --biossystemtimeoffset feature is not documented. 'VBoxManage modifyvm Tor-Gateway --biossystemtimeoffset +5000000' This adds +5000000 milliseconds to BIOS clock. The 5000000 could be replaced by a random value 1234567. Changing the host clock after the VM started doesn't result in syncing the time with the VM. (If we enable NTP on host again...) an adversary could still add a time skew but it would get skewed again by a random value, rendering this attack pointless.
    • (adrelanos) We can run (tails_)htp against trusted hidden services (torproject.org). This has to be done while booting, informing the user, not to establish connections, before the clock is updated. UPDATE: as discussed with Tails dev, this might not be the best idea, because the time needs to be quite accurate to be able to access hidden services (iirc +/- 30 min) and iirc they wanted to lift that a bit. And Tails also recommend not to use only a single server. It's also obvious not to do that. (Don't place all eggs in one basket, server could get compromised, server offline, etc.)
  • (adrelanos) I don't think this needs more mature upstream. See above.
  • (adrelanos) We have to understand the differences between htp and tails_htp.
    • (adrelanos) Do you speak some perl? Question about tails_htpdate... Time syncing Design doesn't answer it. "The custom /usr/local/sbin/htpdate we use delegates certificate verification to wget. It also uses several different pools of time sources, and if there are too many that fail for any given pool, e.g. because of failed certificate checking or being unreachable, the pool is considered to be potentially compomised and htpdate aborts." 1. Which pool is used to set the time, all pools or only one? 2. Does it only use one random server from x_pool to set the time or does it build an average value (time) from all servers which could be reached?
    • (adrelanos) After some testing I found out. It picks a random server from each pool and uses the mediate of them. I think adding tails_htp to Whonix-G and Whonix-W is fine. It's only a partial solution and does only work if the clock is not too much off and it requires Tor to work already. It's still a very good thing to add because host time and Whonix-G/W time will differ.
    • (adrelanos) Answered in tor-talk secure and simple network time (hack).
  • (adrelanos) Virtual Box has a bug: Guests clocks not kept synchronized. Another reason to include tails_htp. But we have to run it periodically to work around that bug.
  • (adrelanos) This ticket finally making progress. Running tails_htp at boot time is implemented in github devel branch. I am testing running it every hour at a random minute. Then this ticket can be finally closed.
  • (adrelanos) Using tails_htp since 0.4.4. The open bug has a workaround in 0.4.4 readme. New discussion: [Tails-dev] tails_htp SSL fingerprint pinning https://mailman.boum.org/pipermail/tails-dev/2012-September/001694.html

[INFRASTRUCTURE] Whonix 1.0 website [DONE]

(adrelanos) What is needed for Whonix 1.0?

  • We need a real website.
    • Where no random trolls/crackers can modify anything important. (Such as malicious script edits). (See also evil Evil developer attack.)
    • Some webspace and sufficient traffic.
    • A wiki on that site (media wiki). (And spoilers.)
    • And need a free SSL certificate.
      • All parts off the website reachable over SSL without any warnings (we login over Tor).
        • sourceforge.net does not offer that (SSL warnings).
      • startssl.com offers free SSL certificates. You simply have to prove, that you have control over the domain - but that's not possible with subdomains.
    • Hosting and domain.
      • Censor resistant in sense of "Whonix will not get deleted."
      • Free - if that is possible. No one is willing to pay and in the beginning there are no donations.
    • Bonus points for having it reachable by a hidden service.
    • We allow guest/anonymous postings (bug report, feedback, etc.) and moderate it very non-restrictive. (Allow any critique. Only delete off topic talk such as warez.)
    • Tor friendly.
      • Permit to sign up and to use the page exclusively over Tor.
      • Last time I checked wikipedia (wikimedia) derivatives and wikia weren't Tor friendly.
    • It's still desired to have the less critical parts of the wiki open for guest edits.
    • We can either use free project hosting or own hosting.
      • Is there a free project hosting fulfilling all requirements?
    • Text mode browsers, Javascript and other browser technologies, anonymous use
      • Shouldn't all the important stuff anonymous guests want to do (reading documentation, downloading Whonix or the scripts) be possible without the requirement for javascript or fancy browser technologies? Also registration should always stay optional for reading and downloading.
  • Comparison of open source software hosting facilities: interesting comparison. Google Code and sf.net are not suitable, because they block users from "Cuba, Iran, North Korea, Sudan, Syria", which is ridiculous. We better don't choice something based in non-free countries, such as US.
  • Needs a wiki, a forum, a blog, a mailing list.
    • Q/A forum or ordinary forum?
    • Mailing list can stay on sf.net?
    • Blog can stay on sf.net? Integration?

savannah

  • (adrelanos) https://savannah.nongnu.org (with SSL) looked promising and I don't expect them to be gone soon or to do any other stupid stuff (banning countries etc.). They offer homepages, for example http://www.nongnu.org/qwe/ but I haven't seen subdomains (qwe.nongnu.org) with SSL (for nongnu.org). That's the minimum requirement.

github

  • (adrelanos) Already using github as main git repository.
  • (adrelanos) github.com offers sub domains, but they are not reachable over SSL. I can't believe, there are no open source project hosting services with web hosting and SSL.
  • (adrelanos)

Update

  • (adrelanos) Now using http://whonix.sf.net and https://sourceforge.net/p/whonix/wiki/Home/ as website. The solution is far from perfect. Only a subset of the requirements above could be implemented. But at this point, the project isn't so well known. It's not possible to do much better. Without sufficient founding and more people it's not possible to pay for a server, which is large enough.

[SECURITY] Evaluate *BSD as a replacement for either t-w or t-g [DONE]

  • (anonymous) for a rationale see the security page (diversity of systems). BSD are generally better suited for routers than desktops so we should look into making a bsd t-g. AFAIK FreeBSD is the only system that has verifyable software updates and easy to apply binary updates. OpenBSD doesn't even provide hash sums for all required files, let alone signatures. FreeBSD doesn't seem to use much hardening. I think it doesn't even provide ASLR, but hardeing is only part of the security equation. The next version should default to clang/llvm which is a very interesting feature in terms of trusting trust.
  • (adrelanos) Thanks for the review. It's a good starting point to review other distributions. My first thoughts about BSD: too few users, therefore too few eyeballs and support documents.
  • (adrelanos) Absolutely not suited, now answered in the faq: https://sourceforge.net/p/whonix/wiki/FAQ/#why-arent-you-using-openbsd-its-the-most-secure-os-ever1

[LOW SEVERITY] [FINGERPRINTING] /dev/disk/by-id unique ids [FIXED]

  • (adrelanos) Looks all the bothering with the disk uuids wasn't worth it. /dev/disk/by-id contains unique ids. Who knows what else hangs arround in /dev... It still requires a compromised Whonix-Workstation or some bogus application collecting these ids and sending them somewhere, that's why this gets low severity. I prefer to fix this, if that's possible, I don't know how. Needs research.
  • (adrelanos) Really only a minor bug. Now documented: https://sourceforge.net/p/whonix/wiki/Security/#whonixs-protocol-leak-protection-and-fingerprinting-protection
  • (adrelanos) Fixed in latest git. Will be fixed in 0.4.5.

Related Tickets

Tor

ticket topic status
#5439; #4019 notice flood; Tor warns about public SocksPort addresses twice on startup (new defect)
#5438 sockslistenaddr in torrc fixed
#5437 man page: IsolateClientProtocol needs clarification? fixed
#5210 Enable gcc and ld hardening by default in 0.2.3.x (needs_revision defect)
#5220 Intelligently use capabilities/privileges and drop what we don't need for Debian Gnu/Linux accepted, no progress
#5553 prevent protocol leaks; Tor client connection API or protocol review howto accepted, no progress
#6060 add http proxy support to Tor accepted, no progress

Vidalia

#6207 apt-get install tor vidalia results in defunct Vidalia duplicate
#4716 vidalia... tries to start a per-user Tor with system-wide settings accepted, no progress
#6209 Add Vidalia to tpo precise repository accepted, no progress
Tails Tails wants to push some things upstream TODO

obfsproxy

#6201 Add obfsproxy to Tor stable repository workaround, now using Debian package

Analysis

#5928 Research: IP discovery through Tor behind isolated network No time?

TorIM

#5498 Tor IM Bundle - use decentralized system (ex: cabels or TorChat) No time?
#1676 Audit jabber/XMPP support for pidgin stalled

Infrastructure

#3592 lack of web forums accepted, in progress
#2436 Front Page of Wiki Not Editable REJECTED, there is now WikiStartAlternate, but ignored.
#5561 introduce rules for Tor wiki, trac, irc; netiquette; policy REJECTED
#1039 subdomain.torproject.org as www.torproject.org/subdomain (comment: for reaching Tor check through tpo's hidden service) REJECTED
#6103 Make a list of all torproject.org hidden services (and bring them back online) implemented, https://trac.torproject.org/projects/tor and https://www.torproject.org/docs/tor-hidden-service.html.en

GPG

#5606 deb package with all torproject.org signing pgp keys ?
#2617 Add GPG keys to website, remove dependency on keyservers REJECTED

Ubuntu

Ubuntu bugs do not matter so much anymore, since we switched to Debian.

716535 apt-get freeze attack (Valid-Until) importance: "low"(!)
1105645 /etc/bash.d/ wishlist -

Debian / Ubuntu

https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/1039420 NTP security vulnerability because not using authentication by default ?
http://brainstorm.ubuntu.com/idea/30050/ Idea #30050: Secure Network Time Synchronization Vote!
http://brainstorm.ubuntu.com/idea/30076/ Idea #30076: Enhancy Privacy/Security, Wipe RAM on shut down, reboot and trigger Vote!

Debian

23687166 ntp: NTP security vulnerability because not using authentication by default stalled
700811 interface comes up even if a script in /etc/network/if-pre-up.d/ fails -
675008 bash: should handle /etc/bashrc.d (or similar) for non-login interactive shell -

Tor Browser

#5480 can we get a link to "https://www.torproject.org/dist/torbrowser/latest-tor-browser" REJECTED
#5322 doesn't obey user.js? setting custom proxy settings ANSWERED
#3455 Tor Browser should set SOCKS username for a request based on referer ACCEPTED, ASSIGNED
#5236 Make a deb of the Torbrowser and add to repository very unlikely
#3994 Get TorBrowser in Debian very unlikely
#4522 Add privilege separation for bundled browser needs_information enhancement
#5791 Gather apparmor/selinux/seatbelt profiles for each component of TBB assigned project
#5024 compile time hardening of TBB (RELRO, canary, PIE) (new enhancement)
#5611 Enhance "Transparent Torification (Requires custom transproxy or Tor router)" in Tor Button. ?
#6025 enable Bookmarks Toolbar by default ?
#6053 TorButton breaks functionality to have multiple homepages (startpages) ?
#5273 Update TBB design doc for 2.3.x-alpha (missing Tor Browser Update Check Technical Documentation) new defect

torsocks

#6155 Import torsocks from google code to torproject.org trac (assigned defect)
#8137 add option to allow connections to local addresses new

Tor Check

#6098 Add a hidden service to check.torproject.org new enhancement

TorBirdy

TorBirdy different topics new
#6018 Add TorBirdy to the torproject.org repository new

Virtual Box

#10828 VBoxService --disable-timesync broken Done. Workarround. They say it's actually a feature, not a bug or a missing feature.

Arm

#7611 Man page parser out of date new defect

KDE

wiki editing

Similar Projects

https://sourceforge.net/p/whonix/wiki/Authorship/#similar-projects

people talking about Whonix

moved to https://sourceforge.net/p/whonix/wiki/Security/#security-reviews-and-feedback

Our Shell scripts and Build Documentation

Build Documentation
https://sourceforge.net/p/whonix/wiki/BuildDocumentation/

Questions

Archived: Dev/ArchivedDiscussion/QUESTIONS

New questions: Contacting Whonix developers / Feedback / Questions

Attachments (15)

Download all attachments as: .zip