Changes between Version 9 and Version 10 of doc/TorBOX/Dev/ArchivedDiscussion/SECURITY

Apr 7, 2013, 5:49:11 PM (6 years ago)



  • doc/TorBOX/Dev/ArchivedDiscussion/SECURITY

    v9 v10  
    525525 * (adrelanos) Encrypted updates would still offer an advantage. Exit nodes couldn't even guess that someone uses aos. That would make it harder for exit nodes to exploit something, would also add more privacy about installed packages. I don't think upstream will add this feature anytime soon. Ubuntu doesn't even offer download of images over https. I saw a discussion somewhere, that they don't want to do it because that would cause quite some CPU load. That might be the same with apt-get. I think we can close this one as [UPSTREAM ISSUE].
    526526 * (anonymous) That would be called security through obscurity, and even that wouldn't work out because exits can see you making a connection to a known ubuntu server. apt-get freeze attack issue is tracked in related bugs, therefore closed.
     528== [SECURITY] flashplugin-nonfree security concern [DONE] ==
     529 * (adrelanos)
     530 * (adrelanos) Fix the page.
     531 * (adrelanos) done for 0.5.1
     533== [SECURITY] [PACKAGING] Empty Tor Package [DONE] ==
     534 * (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.
     535 * (adrelanos) Done:
     537== [SECURITY] Include rawdog to fetch Whonix News (Blogs) [IMPLEMENTED] ==
     538 * (adrelanos) Related documentation: [ rss].
     539 * (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.
     540 * (adrelanos) Done in untested_adre git branch will come in 0.5.x.
     542== [SECURITY] [ENHANCEMENT] Switching Operating System [DONE] ==
     543 * (anonymous) why would this benefit us:
     544  * the ova is about half the size!
     545    * (adrelanos) Interesting...
     546  * Debian uses validuntil in apt, for T-W this isn't problematic because a evil exit can't persistently prevent you from updating.
     547    * (adrelanos) Valid, important point.
     548  * Tor/Tails/Torouter all have an affinity to Debian
     549  * Makes Whonix more diverse and harder to exploit both at the same time
     550  * we could use debdelta, and Debian likely will get delta updates before Ubuntu
     551    * (adrelanos) Do we need that? T-G can make updates over apt-get in clear anyway (beside the hide Tor usage people).
     552 * Cons?
     553  * 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.
     554  * (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.
     555  * (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 [[BR]]
     556    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)
     557 * (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.
     558  * (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.
     559 * (adrelanos) What about Hardened Gentoo? (Liberté Linux uses it.)
     560 *  (anonymous) answered here: 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...)
     561 * (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.
     562 *  (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.
     563 * (adrelanos) Will be still a long time until wheezy comes...
     564 * (adrelanos) [] 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:
     566# Tested on Ubuntu Precise.
     567apt-get install debian-keyring
     568gpg --homedir ~/gpg_debian --import /usr/share/keyrings/debian-role-keys.gpg
     569gpg --homedir ~/gpg_debian --verify SHA512SUMS.sign SHA512SUMS
     570sha512sum debian-6.0.5-i386-CD-1.iso
     572 * (adrelanos) Not sure if Debian is the right choose. They don't seem to care too much about security...
     573  * (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.
     574  * (adrelanos) No TLS authenticated source for their CD signing keys. WOT (web of trust) only. It's a sink or swim.
     575  * (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.
     576 * (adrelanos) Switched to Debian. Main reason were licensing issues with Ubuntu. On security page this is outlined in details.
     578== [SECURITY] Setting correct time (NTP/HTP) [DONE] ==
     579=== Resources ===
     580 * (adrelanos) Just as collection of related links.
     582==== Liberté Linux ====
     583 * [ Liberté Linux (toward the end of Network Security)]
     585==== Tails ====
     586 * [ search Tails's website for NTP]
     587 * [ Tails's solution]
     588 * [ authenticate_time_servers]
     589 * [ recent Tails discussion from 12 mai 2012]
     590 * [ Tails-dev Why doesn't Tails use tlsdate? (htp replacement)]
     591 * [ Tails-dev Removing SSL CA dependency for HTP]
     592 * [ Tails-dev tor-talk secure and simple network time (hack)]
     593 * [ tor-talk secure and simple network time (hack)]
     595==== VirtualBox ====
     596 *
     597 *
     599==== Torproject mailing list ====
     600 * [ System time in anonymity oriented LiveCDs]; [ from Roger]
     601 * [ How accurate does need the clock to be?]; [ answer]
     603==== tlsdate ====
     604 * [ ioerror / tlsdate]
     605 * [ tlsdate]
     607==== Authenticated NTP Guides ====
     608 * [ one]
     609 * [ two]
     611=== tlsdate ===
     612 * (adrelanos) Compiling is easy.
     614git clone
     618make install
     620 * (adrelanos) tlsdate does not support connecting to hidden services, or are there any hidden services with SSL?
     622=== htp ===
     623 * (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.
     626mkdir htp
     627cd htp
     633sha512sum *
     638  htp-0.9.3.tar.gz
     640  htpdate_1.0.4_i386.deb
     642  htpdate-1.0.4.tar.gz
     645Compilation and installation is easy.
     648make install
     650 * (adrelanos) Tails uses forked version of htp. Search for [ git].
     652=== tordate by Tails ===
     653 *;a=blob_plain;
     655=== tordate by Liberte Linux ===
     656 *
     657 *
     659=== Whonix ===
     660 *
     661 *
     663=== Ubuntu ===
     664 *
     665 *
     666 *
     668=== Discussion ===
     669 * (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: (toward the end of Network Security) and
     670 * (anonymous) time zone fingerprinting: should Tor-Workstation be set to UTC? Also: keymap fingerprinting. Belongs to Tor-Workstation installation.
     671 * (adrelanos) [ tails's solution]
     672 * (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 )[[BR]]
     673   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. [[BR]]
     674   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.
     675   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.
     676 * (adrelanos) ISP should be definitely part of our adversary model.
     677 * (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...
     678 * (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).
     679 * (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.
     680 * (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. [[BR]]
     681  * TODO: build, deploy, test Tail's HTP.
     682  * maybe interesting: Does htp detect delay attacks? That seems like a simple, yet effective attack that could easily be overlooked because it's so atypical.
     683 * (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.
     684 * (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.
     685 * (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...
     686 * (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.
     687 * (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.
     688 * (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.
     689 * (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?]
     690 * (adrelanos) Does Ubuntu (full, not server) after installation use authenticated or unauthenticated NTP?
     691   * (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.
     692    * (anonymous) No OS I know of uses authentication for time sync (neither free nor commercial systems)
     693   * (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.
     694    * (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. [[BR]]
     695     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.
     696 * (adrelanos) A helpful [ answer] for my question.
     697 * (adrelanos) And a brand new solution - [ ioerror / tlsdate]. I have not looked into it myself, just wanted to share the news. 
     698 * (adrelanos) Liberté Linux, new for me, good first impression, also uses HTP, just sharing, also haven't looked inside.
     699    * (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.
     700 * (anonymous) I think it's time to solve and close this ticket... --> (adrelanos) Agreed.
     701  * 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.
     702  * 1) Disable ntp on all Whonix systems, it either is useless (T-W) or opens us up to attacks (Host, T-G). --> (adrelanos) Agreed.
     703  * 2) Advise users to manually make sure the time is correct. --> (adrelanos) Agreed.
     704  * 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.
     705  * 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?
     706 * (anonymous) ioerror didin't talk too favorably about it ( and I tend to agree, hence no recommendation either.
     707   * (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.
     708    * (anonymous) As a response but also as a ''' summary of the whole discussion (tl;dr) ''' [[BR]]
     709      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. [[BR]]
     710      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).
     711 * (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'''.".
     712   * (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.
     713 * (adrelanos) Just sharing, no review. [ recent Tails discussion] about this topic from 12 mai 2012.
     714 * (adrelanos) [ Tails-dev Why doesn't Tails use tlsdate? (htp replacement)]
     715 * (adrelanos) [ Tails-dev Removing SSL CA dependency for HTP]
     716 * (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.
     717 * (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.
     718 * (adrelanos) Reopened this one. At least for Tor-Workstation there should be a feasible solution.
     719  * (adrelanos) While fixing T-W, we assume, T-G is clean. We keep care about T-G afterwards.
     720  * (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.
     721  * (adrelanos) We can run (tails_)htp against trusted hidden services ( 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.)
     722 * (adrelanos) I don't think this needs more mature upstream. See above.
     723 * (adrelanos) We have to understand the differences between htp and tails_htp.
     724  * (adrelanos) Do you speak some perl? Question about [;a=blob_plain;f=sbin/htpdate;hb=HEAD 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?
     725  * (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.
     726  * (adrelanos) Answered in [ tor-talk secure and simple network time (hack)].
     727 * (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.
     728 * (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.
     729 * (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
     731== [LOW SEVERITY] [FINGERPRINTING] /dev/disk/by-id unique ids [FIXED] ==
     732 * (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.
     733 * (adrelanos) Really only a minor bug. Now documented:
     734 * (adrelanos) Fixed in latest git. Will be fixed in 0.4.5.
     736== [SECURITY] Evaluate *BSD as a replacement for either t-w or t-g [DONE] ==
     737 * (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.
     738 * (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.
     739 * (adrelanos) Absolutely not suited, now answered in the faq: