On Mon, Mar 20, 2017 at 12:00 AM, iry <[email protected]> wrote: > Jean-Philippe Ouellet: >> The same problems would still apply, but would instead apply to >> obtaining and bootstrapping trust in your copy of Qubes. If this is >> a problem you really wish to solve, simply providing trust via >> signed qubes templates is not sufficient. > > I am not sure why "simply providing trust via signed qubes templates > is not sufficient". Do you mean if one do no verify the Lantern > software, he/she will probably not do verify for Qubes OS installation > file neither? Could you please explain more about this to me? Thank > you very much!
Yes, this is what I mean. Bootstrapping guarantees of authenticity and integrity is not solved by simply wrapping the intended payload (Lantern) in another thing (Qubes) which must itself also be bootstrapped, unless that thing (Qubes) is already somehow trusted. In this case, I sincerely doubt the intended users already have a trusted copy of Qubes. Rather, the net effect of such wrapping is that an adversary who wishes to subvert the delivery of Lantern may instead target Qubes. I'm not saying don't do it, only pointing out (as I think you already understand) that meaningful secure delivery is not solved simply by signing a template with a key distributed with Qubes, and as such the download sources & verification section of your proposal was IMO perhaps somewhat misleading. >>> B. Privacy ... By placing Lantern in an independent qube, it will >>> not be able to collect the local user behaviors that happen in >>> other qubes. >> >> I think claiming this is somewhat misleading unless you also also >> enforce that the traffic within is somehow also protected >> independently. > Thank you for your feedback! I did find it misleading. The following > is my correction to the previous statement. How do you like this one? > > By placing Lantern in an independent qube, it will not be able to > collect the user behaviors that happen in other qubes. ...except for all the traffic analysis and active man-in-the-middleing it could do even on networks which might otherwise not be attacker controlled. > Additionally, a whonix-gateway can be set up between Lantern-Gateway > and an AppVM, making all the traffic through the Lantern client > encrypted by Tor client already. I think this (or equivalent) should be very much encouraged, otherwise your above statement may not hold true. I view your proposed ProxyVM as providing only availability, potentially at degraded integrity and confidentiality (in the event that the circumvention tool is somehow vulnerable, which you indeed recognize may be the case). Someone wanting all three properties may need to take additional measures besides just using a given censorship-circumvention tool, and should be well informed that that is the case. This is a minor detail though which can be addressed in documentation much later on. Don't worry about it, your proposal is still very strong IMO. >> Running the server-side infrastructure to forward traffic has >> associated costs, and perhaps those running them somehow rely on >> income from Lantern Pro in order to cover those costs? I think it >> would be wise to at least start a discussion with them about this >> rather than taking an adversarial approach towards Brave New >> Software right from the start. > > Thank you very much for your advice! I agree with you that I should > start a discussion with the Lantern community. I did not even realize > this can be a problem. Your advice let me realize that there is a > difference between being a DIY user and being a responsible developer. Heh. Reminds me of my game-hacking days ;) There's a difference between privately using a cheat you wrote, and distributing it and ruining the game for everyone... > I will start a discussion with them soon! And I will report the result > to the mail-list. Sounds good. > Please let me say thank you again for your feedback, Jean! You're very welcome! This kind of detailed and engaged communication is a model to all GSoC applicants :) -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/CABQWM_AeafOm8JFLPDLrx%2BYSj%2BQtbbXgpmhe43VcCVWu02GcYA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
