-------- Original Message -------- > > namely the mirrors serving the updates can be made to serve malicious iso's > > with > > fake verification keys. > > Either I don't understand what you mean, or you didn't understand the > security discussion you're referring to. May you please clarify what > you mean with "fake verification keys", and what exact section of the > aforementioned security discussion you're referring to?
Hi, no specific section, is the basic principle of insecure networks that you are pushing updates through that im pointing out is inheriently at fault. Namely theres two main attack vectors, that tails.org and its mirrors can be made malicious by intruders, and that the connection to the mirrors/tails.org can be modified in transit by a malicious 3rd party. On the first point, when a sites IP is known its server can be located rendering it vulnerable to physical seizure or attacks, im assuming your servers arent guarded 24/7 by 2 armed men then you are leaving everyone wide open to what is a fairly common technique amongst governments to access and control a server locally. The obvious solution is to create a tails.org .onion located on a new server separate from the clearnet one as to insure its location remains a secret, allowing for its users to reference it as a secure verifiable source of info. As for the possibility of remote hacking i will assume since the tails devs are capable of securing an OS that they are capable of securing a website. On this point it seems wholly irresponsible that tails users upon connecting to Tor and loading the browser are connected to a clearnet site with scripts enabled, what sort of security model opens users up to scripting attacks every single time they connect to the internet?? On the second point, traditionally to prevent MITM's from modifying traffic in transit websites use SSL which is a most basic of security protocols. Tails.org and its distro mirrors do not even bother with this, the arguement supplied by the devs is "they can just attack the mirrors anyways"....see point 1. It can also be argued that SSL is not secure because a nationstate could forge a cert or force a CA to create one for them, and that exit nodes or a MITM can and have stripped SSL. These points are correct, the solution is to make a tails.org .onion, which is end to end encrypted and does not rely on 3rd party web-of-trust models that are vulnerable to nation-states, MITM's, or corporate compliance. This has been pointed out before by others before elsewhere on the internet and perhaps was not heard. How trivial it would be for an attacker to force users to unwittingly download contaminated distro's? And why does tails.org provide such lengthy guides on verifying the .iso's using information that could just as easily be forged (SHA256/signing keys)?. If the devs would create a distrobution channel that ran over tor as an .onion then none of these problems would exist. Why then is a distro centered around Tor so adverse to running on Tor? -------------------------------------- From: intrigeri <[email protected]> Apparently from: [email protected] To: User support for Tails <[email protected]> Subject: Re: [Tails-support] Insecure updates, devs please address Date: Sun, 18 Jan 2015 13:20:18 +0100 > Hi, > > thanks for looking into the security of our incremental upgrade mechanism. > > [email protected] wrote (18 Jan 2015 09:00:22 GMT) : > > The attack vectors detailed in the incremental updates design spec > > (https://tails.boum.org/contribute/design/incremental_upgrades/) mention > > that alot of > > these attacks are the same as the old method of manually downloading and > > verifying an > > iso, > > This is correct. > > > namely the mirrors serving the updates can be made to serve malicious iso's > > with > > fake verification keys. > > Either I don't understand what you mean, or you didn't understand the > security discussion you're referring to. May you please clarify what > you mean with "fake verification keys", and what exact section of the > aforementioned security discussion you're referring to? > > > Yhese attacks can be solved by making the mirrors .onion's > > instead of http, no possibility of mitm replacing updates in transit and no > > way for > > an attacker to find the mirrors location in order to attack it. This is a > > fundemental > > security flaw that could easily be addressed by routing existing > > infrastructure > > through Tor. Is there some reason the devs have ignored this simple fix? > > We can discuss that once the above points are clarified. > > Cheers, > -- > intrigeri > _______________________________________________ > tails-support mailing list > [email protected] > https://mailman.boum.org/listinfo/tails-support > To unsubscribe from this list, send an empty email to > [email protected]. _______________________________________________ tails-support mailing list [email protected] https://mailman.boum.org/listinfo/tails-support To unsubscribe from this list, send an empty email to [email protected].
