On Mon, Oct 24, 2016, at 00:28, Russ Allbery wrote:
> The value of HTTPS lies in its protection against passive snooping.
There are some relevant issues, here.
1. It does protect against passive snooping *from non-skilled
attackers*. And this is not being made anywhere clear enough.
2. It is unknown how much it can protect against passive snooping from
skilled attackers capable of passive TCP metadata slooping and basic
traffic analysis *FOR* something like the Debian archive and APT doing
an update run against the Debian archive (i.e. this comment is NOT valid
for ANY OTHER USE of https).
Do not dismiss (2). TLS is not really designed to be able to fully
protect object retrieval from a *fully known* *static* object store
against traffic metadata analysis. And an apt update run would be even
worse to protect, as the attacker can [after a small time window from
the mirror pulse] fully profile the more probable object combinations
that would be retrieved depending on what version of Debian the user
has.
apt-transport-https really exists to help people bypass half-hearted
filtering and logging by corporate or ISP web proxies, and it is very
good for that. It is a valid user case, and one we do want to support.
But it shouldn't be sold as a strong privacy defense, *ever*.
There wouldn't be a reason to not enable apt-transport-https: at this
point of the analysis: it is still not making things really any worse,
so you'd likely have a net gain since it does raise the bar for the
attackers.
However, there are these little real world details called "attack
surface" and "implementation complexity" as sources of exploitable
security vulnerabilities, and the picture changes a lot when you start
looking at that angle:
(up-to-date Debian stable/jessie amd64 system):
ldd /usr/lib/apt/methods/http | cut -d '(' -f 1
linux-vdso.so.1
libapt-pkg.so.4.12 =>
/usr/lib/x86_64-linux-gnu/libapt-pkg.so.4.12
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6
libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1
libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0
liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5
/lib64/ld-linux-x86-64.so.2
compared with:
ldd /usr/lib/apt/methods/https | cut -d '(' -f 1
linux-vdso.so.1
libapt-pkg.so.4.12 =>
/usr/lib/x86_64-linux-gnu/libapt-pkg.so.4.12
libcurl-gnutls.so.4 =>
/usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6
libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1
libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0
liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5
libidn.so.11 => /usr/lib/x86_64-linux-gnu/libidn.so.11
librtmp.so.1 => /usr/lib/x86_64-linux-gnu/librtmp.so.1
libssh2.so.1 => /usr/lib/x86_64-linux-gnu/libssh2.so.1
libnettle.so.4 => /usr/lib/x86_64-linux-gnu/libnettle.so.4
libgnutls-deb0.so.28 =>
/usr/lib/x86_64-linux-gnu/libgnutls-deb0.so.28
libgssapi_krb5.so.2 =>
/usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2
libkrb5.so.3 => /usr/lib/x86_64-linux-gnu/libkrb5.so.3
libk5crypto.so.3 => /usr/lib/x86_64-linux-gnu/libk5crypto.so.3
libcom_err.so.2 => /lib/x86_64-linux-gnu/libcom_err.so.2
liblber-2.4.so.2 => /usr/lib/x86_64-linux-gnu/liblber-2.4.so.2
libldap_r-2.4.so.2 =>
/usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
/lib64/ld-linux-x86-64.so.2
libhogweed.so.2 => /usr/lib/x86_64-linux-gnu/libhogweed.so.2
libgmp.so.10 => /usr/lib/x86_64-linux-gnu/libgmp.so.10
libgcrypt.so.20 => /lib/x86_64-linux-gnu/libgcrypt.so.20
libp11-kit.so.0 => /usr/lib/x86_64-linux-gnu/libp11-kit.so.0
libtasn1.so.6 => /usr/lib/x86_64-linux-gnu/libtasn1.so.6
libkrb5support.so.0 =>
/usr/lib/x86_64-linux-gnu/libkrb5support.so.0
libkeyutils.so.1 => /lib/x86_64-linux-gnu/libkeyutils.so.1
libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2
libsasl2.so.2 => /usr/lib/x86_64-linux-gnu/libsasl2.so.2
libgpg-error.so.0 => /lib/x86_64-linux-gnu/libgpg-error.so.0
libffi.so.6 => /usr/lib/x86_64-linux-gnu/libffi.so.6
I assume I don't have to remind anyone of the security history of the
above library stack. As far as I am concerned, enabling
apt-transport-https *is* a zero-day remote exploit waiting to happen, it
only depends on whether we will find out and patch the vulnerability it
first, or the attacker will exploit it first.
I'd prefer if we enhanced apt transports to run a lot more protected
(preferably under seccomp strict) before any such push for enabling
https transports in apt. It would reduce the security impact a great
deal.
Mind you, at fist look it seems like apt transports will *run as root*
in Debian jessie. HOWEVER I didn't do a deep check, just "ps aux" while
apt was running. And I didn't check in unstable. So, I (hopefully)
could be wrong about this.
Can you imagine trying to contain an exploit in the wild that will take
advantage of people trying to update their systems against said exploit
to spread even further? Well, this is exactly what would happen. We
should not enable apt-transport-https by default until we have _really_
hardened and contained the apt transports.
Now, hopefully I got all of that wrong and someone will set me straight.
It would make me sleep better at night...
--
Henrique de Moraes Holschuh <h...@debian.org>
