Re: client-side signature checking of Debian archives (Re: When should we https our mirrors?)
- To: Russ Allbery <email@example.com>
- Cc: firstname.lastname@example.org
- Subject: Re: client-side signature checking of Debian archives (Re: When should we https our mirrors?)
- From: Adrian Bunk <email@example.com>
- Date: Sat, 5 Nov 2016 23:23:22 +0200
- Message-id: <[🔎] firstname.lastname@example.org>
- In-reply-to: <email@example.com>
- References: <580CC7E3.firstname.lastname@example.org> <CAPgP4gwkkfhsfUMzGqT6AWqFnL7u2dazBvbj1ZPTpjQy0WTQeA@mail.gmail.com> <580CED6C.email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org>
On Tue, Oct 25, 2016 at 11:06:23AM -0700, Russ Allbery wrote:
> Adrian Bunk <email@example.com> writes:
> So, I'm not quite sure how to put this, since I don't know how much work
> you've done professionally in computer security, and I don't want to
> belittle that. It's entirely possible that we have equivalent levels of
> experience and you just disagree with me, and I want to acknowledge that.
I have some knowledge here and there, but I am definitely not
a Security Expert.
When something is so well-known or obvious that even someone like me
knows it or is able to figure it out, it has to be pretty well-known
> In the specific case of retrieval of apt packages, use of HTTPS raises the
> bar for the attacker who wants to know what packages you probably have on
> your system from simply parsing the GET commands (information that would
> be captured in any dragnet surveillance database as a matter of course)
> for package names and versions to writing Debian-specific analysis code to
> make (fallible) guesses from traffic analysis. This is a fairly
> substantial change in the required resources, and makes various things
> (such as retroactive data mining when this particular use case wasn't
> anticipated in advance) considerably harder.
I hope I am not too rude when I state the general problem I have with
the way you are arguing:
You are not trying to solve a problem,
you are trying to sell a solution.
The solution you are trying to sell is apt-transport-https as default.
The problem would be something like "more security/privacy for users"
or "make it harder for the NSA".
Your solution would be a lot of work with relatively little improvement.
> Yes, you're not going to get absolute security against the NSA with cheap
> wire encryption, but you *do* change the resource battle.
If something makes it more costly for the NSA, the US taxpayer will
just give them another Billion every year - no party in US congress
would oppose that.
Debian resources are far more limited.
Noone is stopping you from doing the work on the client-side for making
apt-transport-https the default (that noone seems to be working on) if
this is important for you - it is your time.
But for any properly formulated problem and a fixed amount of resources,
I doubt the best solution available would include apt-transport-https.
> > By discouraging users from using mirrors for security.debian.org, Debian
> > is presenting a nearly complete list of all computers in the world
> > running Debian stable and their security update status and policies on a
> > silver plate to the NSA.
> It's a tradeoff with freshness of security updates. Personally, I usually
> use an in-house mirror of security.debian.org for various reasons, and
> it's worth noting that our "discouraging" isn't particularly aggressive.
You are drawing your conclusions from just looking at some solutions.
When I go back one step and think of ways to improve the situation for
users, I do also see a possible low-effort improvement that does not
have the tradeoff you are talking about and that does not require a
local mirror. And when even I am able to come up with something, there
is likely more.
(Not limited to security) it is usually worth the effort to start by
properly formulating the problem(s) that should be solved, instead of
limiting yourself to some solutions.
BTW: The "possible low-effort improvement without tradeoff" is:
Is apt-transport-tor working reliably enough for general usage?
Are security updates available immediately through apt-transport-tor?
Is there a good reason why apt-transport-tor is not mentioned
at the frontpage of http://www.debian.org/security/ ?
My current impression (that might be wrong) is that the technical side
would be available, only documentation and perhaps PR (e.g. email to
debian-security-announce) are missing.
apt-transport-tor could also be taken into consideration in the
unattended-upgrades discussion as a (perhaps non-default) option
offered for receiving the security updates.
Oh, and when I look at http://www.debian.org/security/ I see
a link "For more information about security issues in Debian, please
... and a manual called Securing Debian."
The manual says "Version: 3.17, built on Sun, 08 Apr 2012".
I know that writing documentation is less sexy than implementing
technical solutions, but for the problem "more security for users"
proper user documentation is actually more important than many of
the technical solutions.
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed