On Fri, Aug 16, 2013 at 08:04:24PM -0400, Zack Weinberg wrote:
Hi, I'm a grad student at CMU studying network security in general
and censorship / surveillance resistance in particular. I also used
to work for Mozilla, some of you may remember me in that capacity. My
friend Sumana Harihareswara asked me to comment on Wikimedia's plans
for hardening the encyclopedia against state surveillance.
<snip>
First of all, thanks for your input. It's much appreciated. As I'm sure
Sumanah has already mentioned, all of our infrastructure is being
developed in the open using free software and we'd be also very happy to
accept contributions in code/infrastructure-as-code as well.
That being said, literally everything in your mail has been already
considered and discussed multiple times :), plus a few others you didn't
mention (GCM ciphers, OCSP stapling, SNI & split certificates,
short-lived certificates, ECDSA certificates). A few have been
discussed on wikitech, others are under internal discussion &
investigation by some of us with findings to be posted here too when we
have something concrete.
I don't mean this to sound rude, but I think you may be oversimplifying
the situation quite a bit.
Enabling HTTPS for everyone on a website our scale isn't a trivial thing
to do. Besides matters of policy -blocking Wikipedia in China isn't
something that can be lightly done- there are significant technical
restrictions. Just to lay a few examples here: there is no software that
can both do both SPDY and take as input the key for encrypting SSL
session tokens, something that's needed if you need a cluster of
load-balancers (you also need to rotate it periodically; a lot of people
miss this). There is no software out there than support both having a
shared SSL session cache and also do SPDY[1]. etc.
DANE is great and everything but there's no software availalble that
satisfies our GeoDNS requirements *and* supports DNSSEC. I know, I've
tried them all. Traditional DNSSEC signing proxies (e.g. OpenDNSSEC)
don't work at all with DNSSEC. (FWIW, we're switching to gdnsd which has
a unique set of characteristics and whose author Brandon Black was hired
in the ops team shortly after we decided to switch to gdnsd.)
Plus, DNSSEC has only a marginal adoption client-side (and DANE has none
yet) and has important side effects. For example, you're more likely to
be used as a source for DNS amplification attacks as your responses get
larger. More importantly though, you're breaking users, something that
needs to be carefully weighted with the benefits.
If you need numbers, this is from a paper from USENIX Security '13 last
week titled "Measuring the Practical Impact of DNSSEC Deployment"[2]:
"And we show, for the first time, that enabling DNSSEC measurably
increases end-to-end resolution failures. For every 10 clients that are
protected from DNS tampering when a domain deploys DNSSEC, approximately
one ordinary client (primarily in Asia) becomes unable to access the
domain."
Is dedicating (finite) engineering time to write the necessary code for
e.g. gdnsd to support DNSSEC, just to be able to support DANE for which
there's exactly ZERO browser support, while at the same time breaking a
significant chunk of users, a sensible thing to do?
We'll keep wikitech -and blog, where appropriate- up to date with our
plans as these evolve. In the meantime, feel free to dive in our puppet
repository and see our setup and make your suggestions :)
Best,
Faidon
(wmf ops)
[1]: stud does SSL well (but not SPDY), but does not pass
X-Forwarded-For, and Varnish doesn't support the PROXY protocol that
stud provides, so either of the two would need to be coded (and we've
already explored what it'd take to code it). nginx scales up and has
some support for SPDY but doesn't have a shared-across-systems session
cache or session token key rotation support nor it supports ECDSA.
Apache 2.4 has all that, but we're not sure of its performance
characteristics yet, plus mod-spdy won't cut it for us. etc.
[2]:
https://www.usenix.org/conference/usenixsecurity13/measuring-practical-impact-dnssec-deployment
_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
