I have a number of questions and requests for possible changes to the Tor Browser Bundle.
Why is the current Tor Browser Bundle for Linux not available in the Tor repository? The reason I am asking is adding the Tor Browser Bundle to the repository would ensure users have the latest Tor Browser Bundle and eliminate the risk of a man in the middle attack. Most Tor users do not have the skills needed to verify the downloads are genuine. On GNU/Linux adding the Tor Browser Bundle to the repository would ensure the user need not know how to verify each update as apt already does this. It would also ensures that ALL security updates get installed ASAP rather than just the base distribution packages without the user having to take additional steps. Tails requires users to download a new disc each time an update is released as well. Like the Tor Browser Bundle this too gives an attacker more of an opportunity to compromise a Tor user. Any additional effort / time required from the user is undoubtedly going to reduce the number of Tor users and increase the dangers. The second thing I was wondering relates to Tails. Why does Tails need to be downloaded each time an update is released? If the goal is a read-only medium there are newer methods to make writeable media read-only without having to burn a new CD each time and update is released or reload a distribution. lathe for instance is a script which creates a read-write update mode using AUFS and a read-only boot mode. I've been working on some of these issues for a long time. One of the issues I've come across is modern media (flash, ssd, etc) has potential risks (encryption), can be very slow, and is less reliable. What are the risks of using encryption on flash, ssd, etc? If a user boots from a read-only (with a secure update mode) flash drive with an encrypted partition for data how much risk is there given an attacker could otherwise install a software based keylogger to achieve the same effect? While I can only assume the Tor Browser Bundle does not have any gaping security holes there is still a real risk of users leaking. The risk comes from things like printers, running in the wrong mode (non-Tor mode), etc. This is not an acceptable risk for many Tor users. I would like to create a hardened distribution with severe restrictions to keep users well contained from harming themselves. I believe locking down the platform is critical as users can't be expected to know or click the appropriate buttons. Having worked on some of these issues I realise that a full blown distribution like Ubuntu requires significant updates. This is a problem for slower mediums. I would like to create a minimal distribution to reduce the number of updates a user needs. Another issue I am trying to solve is the reliability of modern removable media. Removable media is notoriously unreliable and slow. Especially for booting off. I'm not sure where the problem lies as I have not found SLC to be significantly more reliable than MLC. It may be the issue is USB. I have read something to the effect that when a system loses power you are more likely to run into data corruption with flash media. While I don't recall the details it sounded something like the increased write times means there is a higher chance the data or maybe more data would be in a buffer somewhere rather than having been written to disk. Thus increasing the likelihood of corruption. I think there may be a solution to the above issue. By maintaining two backup copies of the data a user could restore an uncorrupted copy "quickly and easily" even if a failure occurs during one of the updates or backups. Syncing would also be faster than making an entire backup as only changed files would be replaced/added/deleted. Rsync can be used in reverse as well so even a failed update could be reverted quicker than doing a full restore of an entire backup. For those who are not aware rsync can be used locally without a network connection. The way I believe this could possibly work in a "quick" manor on slow media is the following: apt-get update; apt-get upgrade; date_of_backup_1=`stat -c %Y /backup1 | sed 's/test.txt//'` date_of_backup_2=`stat -c %Y /backup2 | sed 's/test.txt//'` if [ $date_of_backup_1 -gt $date_of_backup_2 ]; then rsync -av /root /backup1/* else rsync -av /root /backup1/* fi The above would find the oldest backup to sync with. This way if the system lost power during a sync a restore could be performed from the other backup. You may need to check that the last syncing of a backup folder in the above code completed successfully before syncing it again. Failing to do so may give you a corrupt restore point. I am not completely sure on this though. It may not be necessary for one reason or another. locked down /w wifi application available and firefox only (with very little else) iptables setup where Internet access is restricted based on the user and only Tor has access to the Internet; this forces you to go through Tor and should prevent any leaks read-only /w read-write update mode to ensure user always has the most recent security updates without the need to potentially leak encrypted data to an unencrypted boot partition apparmor profile applied to firefox to reduce the risk of an unknown vulnerability keeping a minimalist design whereby unnecessary and potentially exploitable components are not included the inclusion of particular applications that might be needed in a similar locked down mode (apparmor profile applied) _______________________________________________ tor-talk mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
