On Mon, Jul 7, 2014 at 3:15 PM, Lou RUPPERT <himself@louruppert.com> wrote:
If I'm looking at a catalog page from a shoe store on my table,
connected via the phone network, getting close to my 2G cap for my
wireless router for the month. My battery's getting low. Do I want
to waste bandwidth and CPU cycles for TLS encoding, just for
pictures of shoes?
Let's try to turn our focus back to the question at hand, which is
whether there are merits to promoting https mirrors for users who have
concerns about being watchlisted based on their software choices. I
think client cpu cycle and bandwidth concerns are a bit of an
anachronism these days anyway.
I think you pulled out the only reason why using https for mirrors
would be useful.
The threat analysis doesn't show any practicable way for the any
attacker to prevent alter packages even with control of the network.
He could block updates but the client-side would noticed: out-of-date
repository and package list, failed to download specific packages.
HTTPS is a solution to this risk scenario:
A) I don't want anyone to know which package I download (passive listening)
B) I don't want a third party to selectively prevent me from
downloading a package/update (active man i the middle)
Scenario A is more likely to happen or to already be in place.
HTTPS in this case is *not* about security but just privacy.
1) Performance concern: The CPU cycles for encrypting is now low
enough so that it seems feasible. Not all package providers need to
provide https-based repository but having a few of those and give them
visibility would be greatly appreciated.
2) TLS certificates: we do not need the package to be behind a
"debian" certificate, just to be behind a certificate trusted by a
recognized third party (same requirement as for websites). Since we do
not seek authentication of the package but just privacy, we only need
to ensure that we talk to the server we wanted to, whichever it is.