Skip to content
Snippets Groups Projects

DOCUMENTATION

Last edited by Alexander Færøy

Main Article - TorBOX TOC(noheading, depth=0)

ArchivedDiscussion

DOCUMENTATION

Merge Custom Setup into Build From Source [DOCUMENTATION]

  • (proper) Now when Custom Setup is labeled as deprecated we may not feel in mood to keep it updated. What about merging Custom Setup into Build From Source? We could drop Custom Setup. All comments from Custom Setup should transferred to Build From Source. We only would have to maintain one version. Two open questions for me: somehow we should distinguish between steps necessary for private builds and steps necessary for public release? Either by marking or separating. Perhaps also the information part (How To Install - Overview...) should be separate? Not everything must be inside the comments but it won't hurt as well. Dunno... Your opinion?
  • (anonymous) I think I did merge everything missing, only things left are the custom t-w ubuntu desktop and windows desktop but those shouldn't be used anymore. Anything else? I also labeled everything not required for private builds ("skip this step"). Anything left to do? if the answer to both is no I'm all for deleting/removing the custom setup page.
  • (proper) Ok. I'll added a warning that the page will be deleted soon and I am going to delete all content which I feel which is covered. Stuff like custom ubuntu and windows can be moved to a scratch pad (like VMware). Still not sure about the "Overview" section with "Host operating system" or "Bare Metal". I don't really want to loose something which might be asked later again and why we dropped it or if that's possible or whatever. In any case we can solve this. -- DONE. If anything wrong, we can still fix.

ApplicationWarningsAndNotes vs SecurityAndHardening vs TorifyHOWTO [DOCUMENTATION]

  • (proper) There are three sites with very similar content, TorBOX/ApplicationWarningsAndNotes, TorBOX/SecurityAndHardening and TorifyHOWTO. Currently it's a bit suboptimal. Not properly sorted, some redundancy. I am thinking how to arrange things better. My idea is to move everything possible, where it makes sense, from ApplicationWarningsAndNotes and SecurityAndHardening to TorifyHOWTO and than link back. We need only one explanation about protocol leaks (IP and other stuff such as username, CTCP, time zone and so on) and why they should be avoided. That information is currently spread over many pages. ApplicationWarningsAndNotes and SecurityAndHardening should contain only stuff which is really limited to TorBOX. ApplicationWarningsAndNotes clarifies single applications and SecurityAndHardening general security concepts. All the torification, socksification, protocol leaks stuff is left to TorifyHOWTO. Opinions?
  • (anonymous) 100% agreed.

Transparent Torification in Tor Button Trac Ticket [DOCUMENTATION]

  • (proper) "Transparent Torification (Requires custom transproxy or Tor router)" in Tor Button has no documentation and and very little reference on Google. I want to file a trac ticket against Tor Browser Button. Goal is better support for transparent proxy and less fiddling with Tor Browser. The text is open for any edits, clarification, whatever. Can be deleted after posting to the tracker. (Ticket removed after posting. #5611 (moved))
  • (anonymous) Well, but there is no way to select that option in TB before Vidalia is started and hangs, this would have to be selected in vidalia or the launcher and the it will still run that code each time. To do it cleanly this would require a bit of reworking and I don't think the tor guys are interested at all but let's see.
  • (proper) You are right. Please edit the text accordingly. Well, he (mikeperry) already included that feature. He can either improve it, drop it or leave it broken as it is. I don't want to guess ever again what they may think, I fatally failed once. (Os upgrades over Tor) Chances are indeed bad. Let's try before giving up. Update: #5611 (moved)

Security and Hardening article [DOCUMENTATION]

  • (proper) Good changes. TSL... I bet you mean TLS Transport Layer Security? Another question about the block beginning with "Therefore in the context of TorBOX using hidden services". Can you rephrase it please? Note sure I understand right. It implicates, that hidden services over TorBOX are less secure than "ordinary" hidden service (with just one host with Tor and server). I don't believe that is true. The opposite is the case. (If T-W's webserver or whole T-W is compromised, IP and hidden service key stays secure. Successful attacks on Tor/T-G are worst case, IP and hidden service key revealed.) I haven't seen any TSL/SSL protected hidden services, but I believe it's possible, why not. Although it does not make so much sense, as connections to hidden services are encrypted end-to-end anyway. Maybe TSL/SSL would make sense, if the visitors wants to view a hidden service over tor2web proxy. Tor2web would know who wants to access a certain service, but couldn't read the content of the transmission. Okay, perhaps you mean, that TLS/SSL is more secure than hidden services end-to-end encryption. That may be true, as Tor does not use the strongest ciphers (if I remember correctly, only 1024 bit gpg public keys) while TLS/SSL can force AES256. Tor devs have an accepted ticket and design draft to use stronger ciphers - we may inform about it, but solving that is beyond TorBOX scope.
  • (proper) It's still TSL https://en.wikipedia.org/wiki/Transport_Layer_Security not TLS, don't you think?
  • (anonymous) thanks for correcting that...

To Do [DOCUMENTATION]

  • (proper) 'To Do' and 'Working but untested' and the discussion from main article can be probable outsourced to this place and just link it.
  • (anonymous) I've trimmed this section quite a bit by moving all the footnotes here. I think still want an overview of the current status on the main page. This attracts more contributors and warns potential users that this is all still very work in progress. To sum it up, major roadmap goals go to the front page, anything else goes here. The Firewall set up for example is pretty much the most important thing in TorBOX.
    • (proper) Fully agreed, that is important.

Hardening [DOCUMENTATION]

"Hardening of Host and VMs (Pen testing, “nefarious” program containment, etc)"

  • (anonymous) Done? I think this is complete/beyond scope
  • (proper) This would be unfortunately an endless topic, one could install OpenBSD or something similar, audit source code, compile everything from source, activate so many security features, install ids, honeypot, endless methods one could argue endless, it's beyond scope. We use Ubuntu, which has many security features enabled by default, we give elementary advice advice and hints for further reading. If someone wants to contribute in building the most secure Gateway / Workstation, they're welcome, until then it's closed, anyone free to reopen.

installer CD boot options [DOCUMENTATION] [REJECTED]

  • (proper) "F6 (other options) Free software only", shouldn't we recommend that? I haven't recognized any difference yet.
    • (anonymous) according to vrms no non-free code was installed on a default install. I wouldn't recommend it, this is personal choice.
  • (proper) What about any other F6 other options? acpi=off, noapic, nolapic, edd=on, nodmraid, nomodeset, Expert mode - Any of them useful to reduce the footprint of the Tor-Gateway?
    • (anonymous) don't mess with it if it aint broken, these options are only to be used if there are problems with the default.
  • (proper) "F4 (modes), minimal a system" does work with VirtualBox; "F4 (modes), minimal a virtual machine" does not work with VirtualBox (Gave up waiting for root device. Commond problems: ... ALERT! /dev/disk/by-uuid/... does not exist. Dropping to a shell.), but works with VMware. Anyone know why? There are are few differences, I don't know all, but for example, the minimal system has a dhcp client and in comparison with the minimal virtual machine does not have a dhcp client.
    • (anonymous) It might work if we tweak the VM settings or boot options (^^). I recommend against this if vbox tools especially if this enables some VBox drivers that increase attack surface (graphic, clip board etc.) It's not needed and only complicates things.
  • (proper) I agree with you in most parts. The "Free software only" does not make sense yet, as nothing unfree is installed, if that where the point, if any closed source software were installed, we should recommend against it. For now it's resolved.

installer options the user should choose [DOCUMENTATION] [IMPLEMENTED]

  • (proper) The Ubuntu server installer asks quite a few questions and I think we all should use the same reasonable settings. Here is my proposal.
  • (proper) language: English; keymap: choose yours (potentally risk...); country (leave it as it is): United States; full name (leave it as it is): leave blank; host name (leave it as it is): ubuntu; time zone (change it): UTC (it's at the very bottom); username (account name): user
  • (proper) If your host is encrypted, no need to encrypt the VM (and questionable if there wouldn't be leaks in the hosts swap anyway), rather encrypt your host.
  • (proper) Any objections? If not, I am going to add this in a few days.
  • (anonymous) Sounds good. These precautions are only necessary on Workstations because if such leaks occur on the gateway the adversary already has access to the IP.
  • (proper) Done.

using NAT adapter instead of bridge adapter [DOCUMENTATION] [IMPLEMENTED]

  • (proper) I am not happy with this part (from here) "eth0 configuration notes: During installation of Ubuntu Server, if you cancel the step where it tries to get your network connection via DHCP you can hit cancel and set up a static IP. (See security/hardening) Or you use the default DHCP which requires that the physical network the host is connected to is managed by DHCP, this is the case in most networks. In any case, eth0 will already be set up during installation. "" And especially not with "# This is just an example and will depend on how your local network is configured!"

Therefore I propose to use NAT instead of bridged networking. It does not depend on how the users local network is configured. I am working on a solution but ran into a problem. nano /etc/network/interfaces

<snip>
# This device will connect to the internet and may be also connected from the host for SSH administration.
auto eth0
iface eth0 inet dhcp

# This device will only communicate with the Tor-Workstation (Tor-Workstation).
#auto eth1
#iface eth1 inet static
#address 192.168.0.1
#netmask 255.255.252.0

And port forwarding for SSH is also easy. Go to VirtualBox -> settings -> network -> Adapter 1 -> Attached to: NAT, Cable connected -> Port Forwarding. Name: SSH; Protocol: TCP; Host IP: 127.0.0.1; Host Port: 2222; Guest IP: leave blank; Guest Port: 22. In Putty choose IP 127.0.0.1 port 2222.

As long I leave eth1 out commented, everything will work, unfortunately, after enabling it, not even ping to external targets will work anymore. Do you have an idea why is that?

  • (anonymous) Using a Linux host I can't reproduce.

    "# This is just an example and will depend on how your local network is configured!" This is irrelevant, see how the script handles this, it only appends the eth1 configuration and leaves eth0 as it is. However there are good arguments for using NAT instead of bridging (MAC, tethered or 3g connectivity, restrictive gateway...). Bridged network is what's closest to the bare metal approach, but that's not very relevant either. For me NAT works fine. If you can figure out the problem on your end we should implement it. (useful for troubleshooting: ip addr/ifconfig, route, resolv.conf, or simply restart). Try using the settings of the shell script, they are slightly different. OT, we should use the same, I don't know what's the benefit of netmask 255.255.252.0 for example. New thread?

  • (proper) Changing netmask of eth1 from 255.255.252.0 to 255.255.255.0 helped - Internet connection is now working again. Not sure if that is wise -> new thread.

  • (proper) Tor connectivity does not work yet, because of IP listener binding, IP from dhcp for eth0 will be something like 10.0.2.15, can be easily fixed. And to use a fixed NAT IP I got to tell VirtualBox that, but that is covered in the manual, unfortunately it will be a console command.

  • (anonymous) But isn't Tor listening on eth1's address which is unaffected by changing eth0?

    • (proper) Normally it is. I think I know what caused it. The control port which I let listen on eth0. Looking into it soon...

  • (anonymous) As I said, I used the shell script and everything "just worked". To recap: eth0 is using dhcp and NAT, eth1 got a static IP of 192.168.0.1 and tor is listening on that address. Did you use that netmask (.252) on eth0? Maybe post the full etc/network/interface of both VMs.

  • (proper) What broke it was the listener on eth0 for Vidalia and the different netmasks for eth0 (255) and eth1 (252).

updates over Tor, should not waste Tor bandwidth [DOCUMENTATION] [SOLVED]

  • (proper) The Tor-Workstation should not download updates over Tor. We should provide an easy solution to download updates over non-Tor. Any ideas?

  • (proper) We we decide also to torify the Tor-Gateway (forbid non-Tor emissions), we'd also need a solution for that.

  • (anonymous) It's also already mentioned on the main page under disadvantages with a link for offline updates for ubuntu. There's a gui toll which could be run on the host/not-anonymized system but it doesn't work quite well. By default it creates an update disk with packages cached on the local system and it's really cumbersome to add new packages with all dependencies for the Tor Workstation. Best way to transfer stuff to Tor-Workstation is iso files, they are I think read only (or can be discarded after having attached them to the VM) and do not open a new attack surface. One could connect the Tor-Workstation directly to the internet right after installation when it's still "clean" (add another bridgedt/nat adapter) to do the initial update and later do small security patches over Tor but there is "proxy leaks" to worry about. For example /etc/resolv.conf could leak an identifiable IP. Update related correlation is probably hard, especially if the user switches mirrors. I don't see a reason for torifying the gateway except maybe for the NTP/HTP client but that could use SOCKS. Gateway software updates can go over clear net no problem except if you want to hide the fact that you are using Tor (then you'd have to hide apt-get updates which hit the tor repo and of course updates to tor itself). The TransparentProxy wiki page has iptable rules to rute everything through Tort but maybe apt-get can also be socksified on it's own, alternatively one could do offline updates as well. IMO that is all optional, hiding the fact that one is using Tor is not a typical user case and if one tunnels tor through VPN/SSH both is taken care of at once.

  • (proper) This is also a problem probable TorRouter has to think about. The current hint about offline updates is not sufficient. We should make a whole chapter discussing that topic. Must be a really handy and easy method, so actually people would prefer it, and not updates over Tor. Maybe we could boot an independent system from iso, add NAT adapter, and let the second operating system the operating system on virtual hard drive? Still brainstorming... Not sure if aptoncd is inviting enough to be actually used by most users. Still brainstorming.

  • (anonymous) using a 3rd OS makes it too complicated (and 1/3 as many things can fail) diff updates and a stripped down OS would minimize the size of updates. let's see what they answer to https://tails.boum.org/forum/auto-update_critical_software_in_the_live_cd/

  • (anonymous) UPDATE: This is more problematic and more difficult than I had feared. Once we open direct communication (offline or not) between the tor-workstation and a non-torified machine we weaken the isolation of the workstation. When using apt-offline for example one has to creates a "signature". That already sounds bad, and it is. It may leak out an uniquely identifiable "signature", certainly malware could intentionally create a very atypical or unique signature file. When transferring files from the tor-workstation there's always the possibility of exploits targeting the host/other system (e.g. USB subsystem, FS driver, thumbnail parser, lnk vulnerability etc.). aptoncd could probably stay one-way only, i.e. there is no requirement to ever transfer files from the workstation. But depending on how unique the applications are you are going to install (e.g. the simple fact that you install thttpd could make you a target) can reduce anonymity. There's also the chance that the aptoncd inadvertently leaks IDs across systems. That all means it's favorable to update through Tor. But obviously we don't want to promote that. Add to that the more general VM fingerprint issue and I can only come up with one solution: we need to use a live cd of some sort that comes with most everything preinstalled and has frequent releases, TBB would be preconfigured. Tails would fit that very well if there was a (boot) option that disables the built-in tor process. I wonder what the torrouter devs have come up so far, they are exactly in the same boat.

    For now we should just recommend a reasonable up-to-date and popular Live CD without security patches. Instead users should rely on snapshots and always assume the workstation is compromised, which you should always do considering the insecurity of general purpose OSs...

  • (proper) You made a very good research. Good idea to advise to use Tails or Liberté Linux (which also looks very well) in meanwhile would be good. But better Tails, as it's already an official Tor project. We could make a feature request (or provide a patch) for Tails to disable Tor with boot menu - then Tails could be used behind a transparent proxy. I handle the feature request?

  • (anonymous) Please, go ahead.

  • (proper) A bit later, but finally done. Tails without Tor behind Transparent_Proxy

  • (proper) I further suggest to report a bug regarding this issue for TorRouter (component TorRouter, priority blocking). Would be interesting to see, how they want to solve it. There seems to be no such bug report in the bug tracker. If they say "do the updates over Tor", then we can promote that as well, and if they have a solution, fine. As you seam to understand this problematic better, could you make that bug report?

  • (anonymous) Sure, but I'm not sure if that's really a blocking bug for TorRouter... Maybe better on the mailing list (which I haven't subscribed to).

  • (anonymous) I think I was quite mistaken about Torouter. https://lists.torproject.org/pipermail/tor-dev/2011-June/002763.html {{{ "Let's go back to the original point of the tor router. It is to provide a consumer-level Internet NAT/router that is a tor bridge. This way, people have a functional Internet gateway, and also give blocked users access to information via tor." }}} Quite the different threat model... Better look into tails.

and https://trac.torproject.org/projects/tor/ticket/3453 "I'm not convinced transparent tor needs to be a key feature of either torouter hardware. My concern is that this is going to encourage people do to unsafe things over tor. Even if it isn't encouraged, people will use technologies that cannot be properly secured and merely push the risks from their local network and ISP to exit relays. The costs to the user could be high. Perhaps tor could block known plaintext ports by default and/or send these through the local IP per iptables rulesets, thereby bypassing tor."

  • (anonymous) UPDATE: I thought about this some more and there is only one real solution here: we need a new distro. That would be distro Nr.984349742. No already existing one fit our requirements. They are as follows:
    • Not a Live CD: TorBOX isn't a live cd, it's more capable and more flexible. There is no point in restricting again what we can do by using a live cd as the only client. Also, Live CDs always suck when it comes to timely security updates.
      • (proper) Yes! A Live CD would be only a tweaked Tails (with transparent proxy), not too bad, still useful, but definitively not what I initially wanted.
    • Small installation: if the base installation is small, there will be less and smaller security updates and we can get away with using tor for the updates.
      • (proper) At least a graphical desktop, even the minimal gnome or kde packages need loads of security updates.
    • All required packages are on the install disk: Ideally that includes a "patched" TBB, certainly xorg and a WM, irc, what else?
    • Not a custom solution: The installer should create a generic OS that fits most user cases (so user do not need to modify anything), this is because of fingerprinting
  • As the base I'm looking at Ubuntu alternate CDs even with a minimal configuration we are looking at maybe 100 MB security patches in February since the release of the CD in October 2011. Install CDs could be released more frequently than every 6 months of course. But still, there will be kernel updates and the Ubuntu generic kernel is HUGE. A different approach is to use some already existing daily/nightly iso but I can't seem to find a distro that does daily iso builds for a stable branch. I don't think we would want to use development snapshots. To recap:
  • debian/ubuntu based - this is because of familiarity, not for technical reasons. Fedora uses delta updates by default. This looks very desirable.
  • if we don't have delta updates: small(er) kernel but still regular security updates - This doesn't sound easy
  • TBB included
  • (proper) I am also interested in ova releases (binary builds, a virtual machine which can be downloaded, it's just one file and can be imported with VirtualBox or VMware (maybe others as well, I don't know.) TorGateway.ova and TorWorkstation.ova
  • (proper) Your points are all very good points I will go over more detailed later. Currently I am also doing a lot a guesswork. It's still questionable for me, who is allowed or better said, welcomed to post at the Tor tracker. At the moment only known Tor devs seam to post their. My plan is to read though all (also closed ones) TorRouter trac tickets and also to read all related mailing list posts. You know, I was going to ask how they intend to solve the operating system updates for clients (Tor-Workstation) with their Tor transparent wifi feature, it seems not even clear if they deploy such a feature. But as of right now it seams they yet have not even discussed how they want to run operating system and Tor updates for TorRouter. I am going to post that, if I am allowed and welcome to. My goal is to improve Tor, develop, not to keep the devs from working. So it will be some time until I introduce myself at the dev mailing list.
  • (proper) And I am not sure how long we can afford using the this wiki site if we want to continue with big improvements, be a real project. Maybe torproject.org would set up a new component, TorBOX at their trac? I want to prepared best before asking to minimize chances for a no. In general - I think - they are still fine with a VM project, because they implemented the transparent proxy features into Tor and they added Tor VM to the tracker.
  • (proper) It's also questionable how welcome TorBOX is at torproject.org. If we offer at any point any binary builds, will they tolerate that? I mean, they have no reason to trust us, they do not know us and have probable no time to check if we haven't a) done a flawed implementation and b) inject malware on purpose at some point. For the projects security and trust issues I'd prefer that builds will be made remotely and not on our own computer. The question is, how to become an official project listed on the torproject.org front page? What requirements do they have? How did they trust other third party developers and projects? Won't they tolerate us? Do we need our own hosting, then first become a reliable project or can we continue using their servers? The answer might be somewhere in the history of Tails (for comparison) and some questions may be asked on the mailing list, but not all.
  • (anonymous) I was looking for a generic install iso solution because this would work both for VM and bare metal set ups. Turn's out we don't need that. It does indeed look desireable to use a VM as the client regardless of whether the gateway and network is virtual or not, snapshoting is one reason, fingerprinting another. While we can't elemintate all fingerprints a VM at least hides the problematic unique serial numbers of various hardware components. Anotger reason, really persisten rootkits are made a lot harder (BIOS/firmware rootkits) and finally: if we ever ship a client VM it can be locked down and striped down because there is no need for diverse hardware drivers.
  • (anonymous) I've looked into Fedora and it doesn't work that well. Fedora is too bleeding edge and fast moving. Even with a light desktop (custom XFCE) set up and deltarpm I'm still looking at about 300 MB of updates (380 without deltas) for Fedora 16 (released in November). A small ubuntu or debian desktop without debdelta installed from a install disk released in October requires less (but still too much). Scientific Linux and CentOS don't seem to be doing delta updates yet. Ideal would be a minimal base installation of Ubuntu/Debian with debdelta, a small WM and a few carefully selected applications. I've made made a feature request for TBB to be made available from the deb.torproject repo so it could be kept up to date with the rest of the system. The "only problem" - I can't seem to find any mirrors for debdelta. Also debdelta compared to courgette doesn't save us that much bandwidth.
  • (anonymous) I really don't know what else we could look into. Either we don't patch the client or we abuse the network - as long as there are just two TorBOX users it doesn't matter :) Releasing frequent new ova bundles (like Tail's frequent releases) obviously is no answer, it's supposed to be a persistent installation. Releasing update iso's is no good either because people will install their own applications and those need to be updated as well, we can't anticipate all applications they are going to use. Besides it sucks in terms of usability (and is a lot of work for whoever maintains the offline updates).
  • (anonymous) created a new wiki page just for this ticket: https://trac.torproject.org/projects/tor/wiki/doc/TorBOX/Dev/ClientVM
  • (proper) Perhaps we find an alternative to creating a new distro (Ubuntu fork). I mean, I don't have so much knowledge (yet) about linux, not to talk about starting a distro. For example Packaging Tor Browser for TorBOX is sweet. Does that need a distro? A .deb package also would do. (if we were to solve the update dilemma) And in the end, if we really need our own distro... Maybe we still don't need our own. We could contribute/join a similar privacy orientated existing distro and rather provide some additions? An existing distro has a lot to offer, hosting, website, traffic, trust. It would be also possible to cooperate with a similar project, perhaps Tails or Liberte Linux as persistent installation.
  • (proper) Without me the TorBOX project would never have started, maybe someone else would have started it. And without you, it wouldn't be where it is now. The swarm intelligence is very effective. This means, perhaps we should ask in the right place. I mean, the Tor developers added the transparent proxy feature to Tor and thought about adding to TorRouter... I am going to ask soon.
  • (proper) I am still very unsure if the own distro way is the right way to go. Even if the default installation theoretically needs only 10 MB for updates.... If we ship a torified operating system, a fully functional Ubuntu, people will use all it's possibilities (apt-get is too easy). This means if someone (and this will be many people) doesn't like the light desktop environment, they download, install and update gnome/kde-minimal, they install gnome/kde-stadard over Tor. It feels like I am killing the network I am using. When I started TorBOX my goal was to offer a fully functional torified operating system, but I wasn't aware of the update string attached. The Tor network is already busy with bittorrent traffic and you won't be able to download a small file from a one click hoster (rapidshare and such) because 24/7 all users are "disputing" who may use the free slot. And now we add gnome/kde/os updates over Tor?
  • (anonymous) Well, that about creating a new distro was a bit tongue in cheek. If we distribute an ova instead of an install iso it's even less problematic. apt-get being easy is not a con, people abuse regardless of technical barriers. The slowness of tor will detract people from downloading KDE or Gnome, so will the slowness of the virtual machine under the heavy load of a full DE. We could remove apt-get (and reduce the image size!) but then we could as well install a live cd. Maybe we could tweak sources.list to only fetch security updates by default (and now allow installation of new packages). TorBOX is for power users anyway, even if it's an easy binary distribution. There'll never be THAT many users to really be a problem. Let's not lose track over this.
  • (anonymous) UPDATE: We'll use Ubuntu for now, despite it not having delta updates. Security updates since October: ~70 MB (by far the biggest part is the kernel). 70MB is like someone fetching TBB over tor twice and there have been FAR more than two updates to TBB since October 2011. But, that number isn't the cumulative amount of all security updates, just what you need to download today to get the latest version of all patched packages and there have been many kernel updates since then (last version is 3.0.0.16.19, so 19???) Delta updates would simply solve this issue.
  • (proper) Okay, I asked them, "Operating system updates behind Transparent Proxy okay?" #5284 (moved)
  • (proper) I was told to ask on the mailing list. Done that. tor-talk - Operating system updates / software installation behind Tor Transparent Proxy
  • (proper) There is now a good answer from Andrew. No objection from him. Let's see if in the coming days another Tor developer complaints about our plans. I should have asked more early on the list. It looks like we've put much more though into this issue than necessary. Okay, better to much, than to less.
  • (proper) Quite a few answers. None about network load complaints. Therefore anonymity related stuff. overview by subject
  • Original question can be closed. We already have more specific tickets for the remaining things.
  • (proper) It is solved. Has actually never been an issue. The Tor developers did not complain about waste of traffic, see mailing list for source.

Tor Browser inside T-W false positively outdated [DOCUMENTATION] [ANSWERED]

  • (proper) Not sure if this is critical or not. Ticket #5296 (closed). Also this "check.torproject.org may tell you that a new update is available even if there isn't. That's because Tor Check doesn't support TorBOX." does not really make sense. We use the most current version of Tor Browser inside Tor-Workstation. Why Tor Browser in T-W thinks it's outdated? Even after asking and complaining in trac there is no documentation how this works. The downside of this is, that TB inside T-W could have a different fingerprint from the normal TBB.
  • (anonymous) It's not the website, it's the Torbutton that is incompatible, it does some checks (maybe using vidalia?) and those fail. That's why I made the default homepage point to TorBOX\Readme which contains a link to check.tpo. T-W users will never see that scary warning unless they update tbb on their own without first patching it as documented in TB\twscript. No fingerprinting risk apart from the default homepage. But we do trust TPO to that extent, right?
  • (proper) Thanks. Finally I found it. Torbutton seams not to be compiled, the addon = the source code. In \chrome\content\torbutton.js is a function torbutton_do_versioncheck().

design document [DOCUMENTATION] [DONE]

  • (proper) A Tor Virtual Machine Design and Implementation

  • (proper) The two original author seam to be gone. I'd like to revise that document. No one ever said that this implementation proposal must be the final one or is the only possible one. At the moment no development from the torproject on this, beside TorBOX. The process they describe in that document can be rapidly simplified, without losing features or security. We have already proven that we do not need such an advanced build environment, neither any application patches. However, the document still contains many wise polices we should honor. Anyone interested in revising that document? Should we keep a changelog? Where and how should we start editing the document? Simply in a new wiki site?

  • (proper) The goal of this is, to become someday an official Tor project. At all times there would be a written user friendly tutorial in English to build TorBOX oneself, like we already started on the front page. Additionally maybe screenshot or video instructions. Someday, a bundle of TorBOX could be officially offered on torproject.org (would have to be discussed as soon as we gathered all necessary information and TorBOX is mature).

  • (anonymous) We've already covered all the things that matter, I found nothing new in the document. It's a one VM sollution and if I understood correctly, the VM runs Tor and the host's traffic is routed through it (3.8. Network Configuration is just a list, no details given). This would be very weak (compared to TorBOX) as client exploits can bypass Tor. TorBOX is basically the Tor hardware project implemented in VMs. This torrouter is progressing steadily and improvements in either can benefit both. I'm not sure if they are aware of the progress we've made in the last couple of days.

    As for bundling and redistribution. I think we'd first need a portable VirtualBox. Qemu just doesn't cut it anymore. My Tor-Gateway exported (gets compressed) is 350 MB. We could add a dhcp server and any client OS run in another VM would be torified. This is hardly a solution for the general public. You need to set internal network adapter in the settings manually and using just "any client" is unsafe because of fingerprinting and other attacks that would be mitigated by using Tor Browser as the client. We could create another minimal distro with TB and bundle that too but this would be another few hundred MBs. As mentioned elsewhere, we could trim both significantly. For example TinyCore comes with a gui and is only 10 MBs or so. With deps, Tor and browser that would grow.

    Much better (for redistribution) would be to use a one VM approach as well but with Tor running on host and VM running only TB and a few other must have clients (with the option to install more, e.g. a webserver for hidden services). All the approaches, including the one we currently have (build it yourself, with the shell script it takes literally just a minute after installing Ubuntu Server), have one thing in common: It entices people to install TorBOX on top of their current OS. This is Bad. General purpose Desktop OSs are unsafe and to be untrusted. The real "killer app" for TorBOX would be if we could fit it on a Live CD. Since RAM ressources are even more strained we'd need the one VM solution in addition to stripping down host and guest to the absolute minimum. Then we have the problem with live CDs that we, not upstream, would be responsible for updates and releases.

  • (proper) For example we do not implement "fail safely" (reject ICMP/ping.., we use drop), if you're interested see UDP firewall rule unnecessary?

  • (proper) TorBOX does not rely on VirtualBox and desktop host OS. Bare metal use (psysical computers) is possible and advised safer. I'll agree, people shouldn't be educated in using a TorVM on the top of their unsafe Windows desktop computer.

  • (proper) Instead of Live-CD I'd rather use Live-USB or eSATA.

  • (anonymous) We do fail closed, that's all that matters. If the firewall script fails nothing will be routed because forwarding is disabled, if Tor fails nothing will be routed because traffic is directed to a dead end (a port where nothing listens), if the whole gateway fails nothing get's routed because there is nothing to route to (internal virtual network is isolated from the physical network that is connected to the internet and in case of bare metal there would be a ethernet cable going to a dead port. We actually fail safer when we don't implement the UDP reject because in the first case we'd have to enable forwarding (however I'm not sure what happens if there is no iptable rule that explicitly enabled forwarding). Edit: Tested, here are the results: If forwarding is enabled and no iptables are set (default polocy for FORWARD is ACCEPT!) it will leak everything from Tor-Workstation. We MUST NOT do this exactly to achieve the goal of being fail safe.

    • (proper) Not sure what the "fail safe" is supposed to mean. I understood it as "reject (network answer) unsupported actions" and you understood it as "ensure unsupported actions do not leak". Anyway, my interpretation might not be important and indeed, your interpretation is already fulfilled.

  • (anonymous) "fail safe" means "fail closed": if a gateway crashes or disfunctions it will stop all traffic flow, fail open means it will let everything through. It's not a matter of what i think it means, it's the generally accepted definition of technical terms ;=) If forwarding was enabled we would fail open.

  • (anonymous) Live USB is OK too but you don't get the reboot to known trusted state featuer. eSATA is just like installing to a second hard drive or partition. If left attached the main OS could infect it.

    • (proper) Users could forget to unplug USB and/or eSATA, I see no difference there.
    • (anonymous) you are right, it only matters whether it's external or internal. unplugging external devices certainly is easier than unpluging internal devices, especially on portable devices...

  • (anonymous) Live CD is the only method that reliably protects against physical forensics. With FDE you can be forced to reveal the keys, with a live cd there is nothing to disclose after shutdown and RAM erasing.

    • (proper) When it comes to Live CD, I always think, that Tails is the much more mature project. Nothing wrong with a competitor/alternative, but as I have nothing to complain about their work, their development style and so on, I'd rather join that project. I even thought about using Tails as base for TorBOX (they implemented so many security things already, I am not yet done knowing them all). The biggest difference between Tails and TorBOX is, that TorBOX is a two VM (or two hardware) approach and that Tails is a Live CD while TorBOX main feature is a persistent storage and the ability to install any software package (ex: good for anonymous developing etc.). So when using TorBOX as as Live CD, I do not know, why not simply use Tails? Wouldn't it be better to implement the two VM thing into Tails then? Tails developers seam to be open for it, but no one seams to work on it right now.

  • (anonymous) You can actually install all sorts of programs in Tails via apt-get (debian repos) and use persistence. The real difference is that Tails doesn't offer strong protection against targeted attacks. It actually offers none. TorBOX does. It's based on a distro known to be one of the weakest OSs security wise. (just one) source: http://labs.mwrinfosecurity.com/blog/2010/06/29/assessing-the-tux-strength-part-1---userspace-memory-protection/ Sure, Debian/Tails can be made very secure but that's on Tail's to do for a years with no progress.

  • (proper) Not sure if I understand correctly, but preventing VM Fingerprinting Attacks could be also a part of that design document.

  • (proper) Two new sites created, TorBOX/DesignDocumentBase and DesignDocument.

  • (proper) first cleanup, first draft; Closed: It's sufficiently described now.

Can someone make a logo? [DOCUMENTATION] [DONE]

  • (proper) A goal of mine is the get officially listed on the tor main page (still a long way) under "Our Projects" (where you can see Tails, Tor Browser and so on). Can someone make a pretty logo? The logo would be needed for the tor main page and for all TorBOX pages, especially the TorBOX front page.
  • (proper) Related to Graphics to explain TorBOX.
  • (proper) At best the logo should somewhat represent the type of the project. Since TorBOX can run in VMs and on real hardware... Maybe the Tor onion inside a box (google picture search box) or a computer box? Or an onion where VMs and boxes (computers) are connected? Be sure not to violate any proprietary rights (can not simply google picture search and use any picture as base) and if you do not want to be identified, be aware of possible metadata. It's possible to include pictures to this wiki.
  • (XJ) I have done a logo, hope you like it. The only difference between those two is the sign on the box. Larger sizes available Image(torboxes_small.png)
  • (proper) Absolutely great! Imho the left one is better. However, I stay flexible. Can you divide those two please? After that is done, we can add it to the front page. And later step by step to all sub pages.
  • (anonymous) And I like the right one better :P Thanks XJ!
  • (XJ) Thanks! I'm glad that you like it. I couldn't decide which one to send so I showed you both... but if I had to choose just one I would pick the one on the left side. Anyway, I'm sending both logos in sizes: Original (1947x1896), medium (500x487), small (200x195) and extra-small (100x98) all .PNG files with transparent background. Download (.rar).
  • (proper) I downloaded that file and attached all the files beside the original. (The tor wiki allows at maxmium 2 MB upload and those originals are about 4 mb)
  • (proper) Now we can decide which size we want to attach at which pages (front page and sub pages). For now I add the biggest one to the front page. I used the right one, to do anonymous some honor, as he contributed most content and most complicated stuff.
  • (anonymous) :)

Graphics to explain TorBOX [DOCUMENTATION] [DONE]

  • (anonymous) I'm still not happy with the "About" on the homepage. Someone not familiar with the matter probably has a hard time understanding it. Something like: https://tails.boum.org/todo/Two-layered_virtualized_system/#index2h2 (But much simpler of course!)
  • (proper) Agreed. Unfortunately I never done graphics before. Related to Can someone make a logo?.
  • (XJ) I could do it. But even I have hard time to understand and visualize it in my mind. If anyone that understands it could simply draw it a piece of paper and scan/photograph it and upload here. I could make it more pro.
  • (anonymous) That would be awesome. I made a quick sketch: https://trac.torproject.org/projects/tor/attachment/wiki/doc/TorBOX/Dev/tb2.png https://trac.torproject.org/projects/tor/attachment/wiki/doc/TorBOX/Dev/tb.png Second one is bare-metal with a TW VM (the most secure option). The first one is the basic two VM option. the red arrows in TW mean it's isolated against the host, the only "allowed" arrow (labelled "isolated network") goes to TG where it is torified and routed to the internet. Host traffic is directly routed to the internet. The way the borders are arranged is done on purpose in the first image, the second image is inaccurate (TW and host should both touch TG) Hope this helps visualizing it.
  • (XJ) I have done the basic two VM option. Tell me if it's alright. I can make the "bare-metal" too. Image(about2.2.jpg)
  • (anonymous) The graphics look amazing, thank you! Can you change some parts of the text? Sorry, I should have thought about the proper wording first...
    • replace VirtualBoxes with Virtual Machines
    • replace VirtualBox #1/2 with VM #1/2
    • "The red arrows indicate that malicious or misbehaving applications can't break out of the TW (Tor-Workstation)"
    • "All network connections are forced to go through TG (Tor-Gateway) where they are torified and routed to the internet"

I don't think we need a bare metal graphic. it's the basic same concept and the explanations should suffice.

  • (XJ) Done.
  • (anonymous) Thanks! I've added it to the homepage.
  • (proper) Great! Very well done! Thanks! (I removed the pictures inside the text. No longer needed. To save some space. The pictures are now on the front page.)

Article "Connect to a Tor Gateway on your local network using PPTP VPN" [DOCUMENTATION] [ANSWERED]

  • (proper) I don't really understand the point of that article, Connect to a Tor Gateway on your local network using PPTP VPN. It's said to use it in local network only, not over internet because PPTP is not secure enough for this situation. And the own LAN should be trusted, so why encrypt it? And if the own LAN is not trusted, it would kinda count as internet as well, and then also PPTP wouldn't be the right tool.
  • (proper) Some time ago I thought about an article how to OpenVPN into T-G, but ultimately rejected that idea. Of course it would be neat form a remote location to OpenVPN to T-G and to have a perfectly anonymized connection. The drawback is, it protects only against misbehaving software, not against malware, which deactivates or circumvents the VPN. And in ones own lan, I see virtually no advantages to use (any)VPN over our current gateway mechanism.
  • (anonymous) pptp is used because it's very easy to configure and well supported by all kind of devices. Compared to a proper set up with a hardware gateway between the internet and the devices you want to torify it's less secure but doesn't require any kind of hardware or network layout changes.
  • (proper) Closed, thanks, I'll add it.

Improving bare metal approach [DOCUMENTATION] [DONE]

  • (proper) I think our current bare metal thing is flawed. Who uses three laptops anyway? One for your normal use, without Tor. One as T-G and one as T-W. It's very impractical and barely anyone is going to do that, not to talk about the financial, space effort and being suspicious (Why do you have three laptops?). The Raspberry Pi looks very well for our situation. It's cheap, small (to hide) and suited to work as T-G. The RP would be connected using LAN to the home (WIFI) router. Apart from the RI, the user would also need a USB wifi (or USB lan adapter). Everything costs below 50$. The user is supposed to, to continue using it's existing operating system and existing WIFI (or LAN) for it's normal activity, without Tor. If he wants to use Tor is a very secure manner, he is supposed to shut down it's operating system, (optionally wait a random delay), and to boot T-W from USB (or eSATA) (boot preference in BIOS: 1. USB (or eSATA) 2. internal hdd). Afterwards T-W uses T-G over the RP's WIFI (or LAN adapter). (His normal operating system is supposed, not to know the RP's WIFI key and his T-W is supposed, not to know it's normal WIFI key.)
  • (anonymous) I don't see how it's flawed. There's nothing in the how to that assumes or requires 3 full blown computers. Ubuntu supports ARM (beagleboard, pandaboard...) RP is still vapoware, right? But sure, we can add some more hints to the page about that.
  • (proper) Yes, RP may only be subscribed, not more, although I am confident to get a RP in near future. As soon as I got, I will set it up for myself and share it. What's currently missing, are instructions how connect to T-G using WiFi. But that shouldn't be too hard.
  • (anonymous) T-G to T-W must be wired, otherwise T-W can hop on another wifi network and bypass tor.
    • (proper) That's very sad, but true. I haven't thought about this one. Even if only the host would manage the wifi connection and not the vm, it would be still weaker than a wired connection.

Performance? [DOCUMENTATION] [CLOSED]

  • Are there any problems with using a server kernel?
    • (proper) I installed a big desktop environment on top and never had any issues, at least not in Virtual Machines. Not sure about bare metal. We got to should a change log between the two kernels.
    • (anonymous) Badly worded question. I meant performance and such, I know that it "works" (also on bare metal).
  • How's performance in general?
    • dmesg says: "EXT4-fs (sda1): Unaligned AIO/DIO on inode ... by VirtualBox; performance will be poor."
    • vesa sucks (but the alternative, using guest drivers and acceleration is insecure, pretty much all vulns in VirtualBox in the past were mitigated by not using guest additions)
    • related: in debian screen resolution is even lower than the 1024*768 that are the default in Ubuntu.

Goals/Requirements for T-W [DOCUMENTATION] [DONE]

  • Minimize fingerprintability
  • This can only be achieved with virtualization, hence we will recomment to use the client VM even in a bare metal TorBOX set up. Non-virtualized hardware often contains unique and traceable serial numbers.
  • Updates
  • We want to be able to fetch at least security updates over Tor because this prevents side channel attacks, correlation attacks, accidental leaks.
  • We want timely updates that do not require lots of user interaction (or users won't patch).
  • User friendly packaging of useful and required client applications
  • only open source software (license needs to permit redistribution)
  • upstream must have a proactive security policy
  • security patches should to be distributed with delta updates
    • (proper): proposal for deletion: no longer necessary?
    • (anonymous): yes, not absolutely necessary but very useful because of Tor speeds...
  • minimal but still user-friendly graphical desktop environment
    • comment by proper: We are not required to have such low traffic anymore. Dunno if people will like openbox, never tested it. Let's see... Most people dislike unity. Gnome 3 is messes up, can not even create shortcuts. Gnome 2 was okay, but hardly supported in up to date operating systems. Alternative? The holy mess of linux desktops... Hard decision... KDE, LXDE...
    • I like OB and it's easy to customize. What's important in a VM environment is performance and RAM footprint and I think no other "nice" and "friendly" WM matches Openbox there.

Changelog for T-G and T-W scripts [DOCUMENTATION] [ANSWERED]

  • (proper) We have a changelog for our binary releases. Should we also maintain a small changelog for our shell scripts? Only a brief summary what's new. Where could be place this changelog? I suppose also under TorBOX/Changelog is too confusing.
  • (anonymous) changelogs are for releases, not development versions. I doesn't matter if something is released as a binary or not, stable release get's a new version number (the same for all parts) and a changelog entry. This should contain only things users actually care about - nothing confusing.
  • (proper) I was merely interested to provide a brief overview of our progress for other developers.
  • (anonymous) considering how many developers TorBOX currently has I think the wiki history should suffice for that...
  • (proper) I dunno if it were to attract more, probable not.

Learn from tails [DOCUMENTATION]

  • (proper) The question isn't if we can learn something but what. Discuss things from https://tails.boum.org/contribute/design/Tor_enforcement/
  • (anonymous) Not necessary IMO due to our different design. We are better protected against leaks and don't need any more enforcement besides iptables.
  • (proper) Can't hurt not to reinvent the wheel. See Tails - Design: specification and implementation, they solved few problems we haven't yet, such as time syncing. It's a good idea to read through their writings.
  • (anonymous) The question is too general, if something comes up we can look at it again.

Rename T-W/T-G to TorBOX-Workstation/Gateway [DOCUMENTATION] [DONE]

  • (anonymous) Other projects already use the same names, it would help unifying our script naming conventions, minimizing the risk of name collisions and avoid confusions.
  • (proper) Ok with me. I am on it. Not done. All documentation pages also have to be updated.
  • (anonymous) Hope we won't have to do that again anytime soon :P
  • (anonymous) some links got probably broken in the progress.
  • (proper) I don't think so, if you simply used the replace all, the links also got renamed. They'll probable still work. If not, we fix as soon we recognize. In some time we can use google: site:(trac.)torproject.org tor-workstation and check if everything got changed.

[0.2] Alpha, Beta, Stable [DESIGN DECISIONS] [DONE]

  • (proper) You said, before Tor 0.2.3, TorBOX can not be stable. Why not? The stream isolation feature has not been existed for years. People have been told for years to press everything through port 9050 and no on speaks about stream isolation, just cross read through some forums which discuss Tor. Sure, as soon as Tor 0.2.3 is out we recommend to update and use that feature. Out and the users understanding of Alpha, Beta, Stable may differ. What is roughly defined as Alpha, Beta, Stable?
  • (anonymous) Yes, and all these years Tor had a significant weakness. I wouldn't feel confident releasing "stable" when I know that a fix to an important security is already available in a development version. For me the terminology suited for TorBOX is: Alpha: features are constantly being added, scripts can be edited without making sure that they work reliably. Beta: Only fix important stuff, test it. Stable: Build and Release the current beta with all fixes when we feel it's ready. I'd expect beta testing to last a month or so, shorter if we can get feedback from more users.
  • (proper) Surprisingly, they've added Tor 0.2.3 beta to the Tor stable repository. That's good because we can use the Trans-, Dns, and SocksPort directives from the Tor "Alpha" manual, which was hard to make compatible with 0.2.2. We can now fully make use of stream isolation. Obfsproxy has not been added to the Tor stable repository (see related tickets).
  • (proper) For the scripts, I hope we can always edit them as we feel. That can be called a development version. Released versions can be frozen like we done with TorBOX 0.1.3 and important fixes can still be published (like the critical issue, which was fixes). Or if we desire, we can make multiple branches and backport important fixes from the development version to already released versions.
  • (proper) I want to prevent that calling it alpha implies "not really secure". We can release a few alphas, invite users and reviewers to check it. If there are no serious complaints about security, it were nonsense to continue calling it alpha.
  • (proper) Calling it alpha or not, I want to ensure, that users who try TorBOX won't think "this shit doesn't work, never try it again". Let's make a good first impression.
  • (anonymous) It's not just about security. Our design makes security issues inherently less likely to occur. But it's also about usability and currently we are still working on some user facing stuff (like zenity, gnome-term replacement...). Untill those are all integrated and tested we wouldn't be doing users a favor by calling it not an alpha, they get turned away if things don't work right. But if we say, hey, it's still in alpha, they will understand and forgive such issues and hopefully check later for a beta/stable. We can only make a good impression when we have a somewhat finished and tested product.
  • (anonymous) some of that should be in FAQ
  • (proper) I am on it.
  • (proper) Copy and pasted a lot, rephrased a bit... https://trac.torproject.org/projects/tor/wiki/doc/TorBOX/FAQ#AlphaBetaStableDevelopmentTorBOXversionscheme

Comments

    Please register or sign in to add a comment.