Re: people.debian.org will move from ravel to paradis and become HTTPS only
Op maandag 21 juli 2014 11:34:53 schreef Thijs Kinkhorst:
> On Sun, July 20, 2014 21:34, Steve Langasek wrote:
> > Because it's not an improvement to the service; it's a change that makes
> > the *service* to Debian developers worse, for political reasons.
>
> I don't agree that it gets worse
You're no longer serving those who need to provide an HTTP-only link,
for whatever reason. By any definition I can think of, that means you're
doing less, which implies you're providing less service.
> or that it is for political reasons, but even if it were, it being
> political does not make the reason bad per se.
It is if there are technical arguments against the change (there are)
and there are no technical arguments in favour of the change (there
aren't).
> The use case broken by this change is preseeding installs over plain http
> from a server somewhere on the internet. I find it doubtful whether this
> would be something we need to be facilitating as a project.
If it is a set of preseed files to allow installing machines on one
particular corporate network? Not so much.
On the other hand, if it is a set of preseed files that change the
answers of some low-priority questions (which are not ordinarily shown
to the user installing a machine) so that the default behaviour of d-i
changes without changing the fundamental functionality? That could be
something a Debian Developer might want to provide as a service to our
users, and that would require some HTTP-only webspace, preferably under
the debian.org domain.
One example of such a scenario would be a preseed file that preseeds the
answer of "passwd/make-user" to "false", and ensures that libnss-ldap or
something similar is installed on the resulting system. This would
greatly simplify installing machines without local users.
Having said that, it is a fallacy to assume that just because only one
example has been given, that one example is the only use case that we
should consider. Here are a few others:
- A company's ISP can't provide them with the bandwidth they need, so
they install a transparent caching proxy to reduce bandwidth needs
(this isn't specific to people.d.o, but that doesn't make it less
valid). Transparently caching HTTPS is much more complex than
transparently caching HTTP.
- Someone broke OpenSSL (again) so that https downloads are broken, and
the maintainer puts a (gpg-signed) patch up on their people.d.o space
(or posts a message to a mailinglist; but lists.debian.org already is
https-only apparently, so that doesn't help for people who aren't
subscribed)
- You are somewhere with extremely bad connectivity (say, in Wall Street
during rush hour) where you need to look up/review some documentation
before a meeting, and your SSL connections keep timing out.
- You want to download a large file that is provided along with an
md5sum and a GnuPG signature onto a resource-strapped device (say, a
raspberry pi) which can't decrypt at link speed, and you don't like
waiting.
Need more? I can come up with more, but that would be missing the point.
The point isn't that we should continue supporting HTTP because scenario
X, Y, or Z. The point is that we should continue supporting HTTP because
it doesn't buy us anything not to, while it may cost our users and our
developers something they could do beforehand but can't do right now
anymore.
If you can come up with a scenario where an attack to the *project*
would be prevented by providing an HTTPS-only people.debian.org, *then*
I would agree that disabling HTTP is a good move. But I don't think that
it's possible to come up with such a scenario, simply because you're
providing static files which anyone can download. The only security
benefit to be had is at the client side.
In fact, due to the fact that TLS is a complex protocol which uses a
number of rather complex algorithms, there's a lot that can go wrong
with security in TLS which can't go wrong with plain HTTP, and which
would *reduce* the security of the project. That this isn't just a
hypothetical scenario is proven by the heartbleed bug of a few months
ago.
As with any security-related choice, choosing between HTTP and HTTPS
involves a trade-off of features and convenience versus security. In
most cases, security should win out, and for that reason I agree that
making HTTPS the default (insofar as that is possible) could be a good
thing to do. However, since the only security benefit to be had in
enabling HTTPS for static files is at the client side, I think it's only
fair to *allow* the client to make that tradeoff and decide that in this
one particular case, disabling HTTPS is the right thing to do.
By redirecting all HTTP requests to HTTPS, you're denying clients that
choice, and thus are reducing the level of service that you provide
them.
--
It is easy to love a country that is famous for chocolate and beer
-- Barack Obama, speaking in Brussels, Belgium, 2014-03-26
Reply to: