As of recent there have been many requests for HTTPS content delivery for the
Debian archive.
Debian mirror administrators have been discussing the issue in IRC and via peer
to peer email over the last few months.
Here is a raw log snippet of the largest discussion that has been had thus far.
These conversations are being shared for the benefit of end users who are
questioning why Debian is not currently delivering HTTPS content.
Of the 530 mirrors available 31 currently serve /debian/ over HTTPS, each under
their own self signed certificates. This represents only 5.85% of the total
mirrors available.
An unofficial list of HTTPS Debian Mirrors is available at:
http://noodle.portalus.net/debian_https_mirrors.txt
-Donald Norwood
---
<symoon>: the archive is signed in a away that you trust the content not the
transport
-
<BTS> Opened #750522 in mirrors «HTTPS mirrors
support/request».http://bugs.debian.org/750522
<Cnote> https for mirrors doesn't really give the end user a lot other
than feeling more secure...but its coming one way or another with the amount of
people talking about it and requesting it. Rather we get ahead of it.
<maswan> well, the only https cert I'll deploy on my mirror would be a
wild-cart cert for *. Which I guess would be self-signed, given that no sane CA
would hand one out to me...
<maswan> If that would make the users feel more secure, I could actually
deploy that next week.
<Mithrandir> maswan: why? You could deploy SNI based stuff, surely?
<Mithrandir> also, * won't match ftp.se.d.o
<maswan> Mithrandir: oh, why not?
<Mithrandir> because it's not a glob, it matches per component
<Mithrandir> so you'd need *.*.*.* for ftp.se.d.o
<maswan> ah, sure
<maswan> you'd just list a bunch of them then, I think the longest known
hostname is 5 or 6 components
<maswan> Mithrandir: SNI doesn't help much in us getting certificate
signed fro a large number of different domains owned by different organizations
not us
<Mithrandir> maswan: no, we (DSA) would then provide you with a mafia cert.
<maswan> Mithrandir: and we'd still need a gnome.org, gimp.org,
ubuntu.com, umu.se, etc, etc cert.
<maswan> note that you'd need to provide a ftp.*.debian.org in order for
us to take over ftp.dk.d.o for a while, etc.
<Mithrandir> sure
<Mithrandir> except you can't have * there
<Mithrandir> so what we'd do is just have ftp.d.o and dns based load
balancing or something.
<maswan> or we just drop the silly security theater of https for mirrors
<Cnote> haha
<Cnote> Mithrandir, you mean a central cert?
<Mithrandir> I mean a single cert for all mirrors and not using explicit
configurations in apt, yes.
<Mithrandir> if we wanted to do https, that's a much more sensible way to
do
it.
<Mithrandir> maswan: actually, we could fix apt to do TLSA and just put it
in DNS and it's Just Work.
<Cnote> I was thinking the cert issue would be the biggest holdup but I
like that approach.
<Cnote> *all participating mirrors.
<maswan> Mithrandir: for /debian/ yes, less so for /debian-cd/
<Mithrandir> maswan: sure
<Q_> Mithrandir: TLSA is the best suggestion I've heard so far.
<Ganneff> still, https for mirrors stays somewhere near "stupid"
<Q_> I think it only makes sense in combination with tor or some
vpn.
<maswan> traffic analysis by any adversary not too stupid (and we're
assuming they are intercepting traffic) should be next to trivial given the
small set of well-known file sizes.
<maswan> also, there is a perfectly good way of getting good privacy of
packages installed, run a local mirror
<carlos_c3sl> Besides, it'll increase the load on the mirrors enormously
<maswan> yeah, a fair bit. but on the other hand, how much cpu load do
we have today? I don't think it is so much a capacity problem as a power
consumption issue for us, for instance.
<raphael> is this for all mirrors or just cd images mirrors ?
<Cnote> All
<maswan> raphael: primarily package mirrors, I think
<maswan> and yes, TLSA makes it doable-but-stupid instead of
ehm-maybe-but-stupid
<carlos_c3sl> maswan: it's a lot, an order of magnitude. And it's mainly not
cpu nor electricity
<raphael> what would the purpose of using https be? read it as what's
the
threat model, or what are you trying to protect/defend from?
<Cnote> Past working out all the kinks of providing it, I would be
very interested to see if the traffic shifts to https enabled mirrors.
<raphael> as already mentioned, it is no good against traffic analysis
<raphael> so confidentiality can't be guaranteed, integrity is already
provided by the use of signed hashes, and the availability is not much of an
issue here
<Cnote> I don't think we are paranoid enough. :) I think we get it but
the conversations outside this channel and elsewhere seem to keep asking about
it despite alternatives like private mirrors, et al.
<raphael> a private mirror on its own is not enough
<maswan> That's because they aren't paranoid enough and don't consider
traffic analysis, is my guess.
<Cnote> I meant as one of the suggested alternatives.
<raphael> e.g. your upstream might not deliver you all the files, which
you might only notice when trying to install tor (for example), and investigate
by hand and/or switch to another mirror
<Cnote> The entire hidden OS gets lost once the traffic is analyzed
regardless, but that is more on that system administrators plate than ours.
<raphael> the latter activities would leak details of your use of the
mirror
<maswan> raphael: Good point. So private mirror with archive integrity
checks. And if all the upstreams you choose lack tor and have suspiciously
similar pingtimes, you should really break out the tinfoil hat supply.
<maswan> Seems like there is a good case for a FAQ on "how do I run
debian without my ISP/spy agency knowing what packages I have installed?"
<Q_> Should it also add "that I'm using Debian"?
<symoon> regarding upstream being offensive, we could offer https using
debian cert *to metadata only*
<symoon> providing a way to check integrity in a reliable way
<maswan> integrity checks are quite doable and verifyable to the signed
release files
<Q_> symoon: Having the file with the MD5/SHA* on a debian.org host
with https might add some value.
<symoon> today, no ssl, so you might be provided outdated signed
metadata
<raphael> maswan: thinking about the case of plain simple rsync, I'm not
sure rsync provides any protection against cheap, on-the-fly, alteration - so
there's no need for your traffic to be redirected
<Ganneff> symoon: thats why moving suites have the expiration of the
metadata
<symoon> Ganneff: with an order of magnitude of days
<Ganneff> yeah, but making it much smaller is a bit unfriendly to users
too.
<Q_> symoon: For things like unstable/testing, I don't think days
is
a problem.
<Q_> But even the security archive seems to be set to 10 days.
<raphael> less, IIRC, around 5
<maswan> raphael: hm. it is probably doable with rsync, but less trivial
than http, given the ammount of checksumming in various forms being done. you'd
have to alter those too. but probably doable.
<Q_> raphael: Valid-Until: Sat, 14 Jun 2014 17:11:17 UTC
<raphael> symoon: providing the metadata over d.o also leaks some
details
(you use debian, you use a specific distribution given that old/stable doesn't
fetch it from there or you mirror n suites, etc), and it doesn't protect
against my point above, unless things like ftpsync verify the integrity of all
the mirror on every sync, unconditionally, fetching the metadata via https or
with signature verification
<raphael> maswan: well, -c is usually blocked on mirrors... ;)
<maswan> raphael: yeah, but the incremental filelist transfer and stuff
does it. also -c is checksum *all* files, you can still trigger checksumming
when updating a file of the same name without --whole-file
<symoon> for the 'you use a specific distrib', we could just have a
central host providing a 'security bootstrap' for all others uses (including
archive.d.o and more recent)
<symoon> for the "you use debian" I don't know distributed systems like
BT enough
<raphael> maswan: indeed
<maswan> symoon: we'll, you'd start off with tor+vpn as a base layer to
hide that, because if they can inspect any non-trivial application traffic that
can probably pin down debian and version from that.
<maswan> symoon: second would be that you'd have to be behind a
firewall. Probably not a debian firewall if you want to hide debian.
<maswan> third, mirror centos and ubuntu too. and check for windows
updates. and...
<maswan> and I'm probably not nearly paranoid enough to come up with a
sufficient amount of ideas to hide the fact that you are running debian from an
interested and not incompetent adversary
<maswan> which packages I have installed I think we can come up with a
reasonably good way of hiding though.
<Cnote> What about updates?
<Mithrandir> "run a local mirror"
<maswan> that my local mirror is updating or not updating, is a state
that would leak
<Mithrandir> just mirror everything locally and they'll either conclude
you're vulnerable to everything in the world or that you run a local mirror
<raphael> mirroring too early (or too late, depending on the POV) is
also
leaky
<maswan> I'd assume that they could figure out my arch by guessing PC
anyway, and possibly even limitit to the release I run because fingerprinting
of my traffic would probably tell enough about kernel etc version to tell
<Cnote> maswan, Even if a local mirror is used the possibility still
exists that someone competent enough can figure out eventually what is on the
system from the traffic in a variety of ways, from looking to see what is being
requested or in the alternative seeing what is not being requested.
<maswan> Cnote: you mean application traffic from the installed
packages?
<Cnote> Yes.
<maswan> sure, but there can't be much help from here on that other than
"be aware. and use tor."
<carlos_c3sl> ....I think people don't realize how much more demanding it
becomes, mainly because we lose sendfile()
<carlos_c3sl> What I mean by "lose sendfile" is that apache will no longer
be
able to dispatch the transfer and let the kernel do all the work; the bits will
have to go through user space, which is an order of magnitude slower. Our
machine wouldn't handle the load if a significant portion of the flux were
https.
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
