I hope I'm not being rude, but everything you've suggested here has already been discussed. HTTPS and HSTS are already on the schedule once the China workaround is invented. Cookies are already tagged as Secure and HttpOnly when over HTTPS. Both the certificate pinning RFC and the DANE RFC have been discussed for implementation.
With that said, I think the real problem with Wikimedia's security right now is a pretty big failure on the part of the operations team to inform anybody as to what the hell is going on. Why hasn't the TLS cipher list been updated? Why are we still using RC4 even though it's obviously a terrible option? Why isn't Wikimedia using DNSSEC, let alone DANE? I'm sure the operations team is doing quite a bit of work, but all of these things should be trivial configuration changes, and if they aren't, the community should be told why so we know why these changes haven't been applied yet. Can somebody from ops comment on this? Or do I have to sign up for yet another mailing list to find this out? *-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science www.whizkidztech.com | tylerro...@gmail.com On Fri, Aug 16, 2013 at 8:04 PM, Zack Weinberg <za...@cmu.edu> 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. I've read the discussion to date > on this subject, but it was kinda all over the map, so I thought it would > be better to start a new thread. Actually I'm going to start two threads, > one for general site hardening and one specifically about traffic analysis. > This is the one about site hardening, which should happen first. Please > note that I am subscribed to wikitech-l but not wikimedia-l (but I have > read the discussion over there). > > The roadmap at https://blog.wikimedia.org/**2013/08/01/future-https-** > wikimedia-projects/<https://blog.wikimedia.org/2013/08/01/future-https-wikimedia-projects/>looks > to me to have the right shape, but there are some missing things and > points of confusion. > > The first step really must be to enable HTTPS unconditionally for everyone > (whether or not logged in). I see on the roadmap that there is concern that > this will lock out large groups of users, e.g. from China; a workaround > simply *must* be found for this. Everything else that is worth doing is > rendered ineffective if *any* application layer data is *ever* transmitted > over an insecure channel. There is no point worrying about traffic analysis > when an active man-in-the-middle can inject malicious JavaScript into > unsecured pages, or a passive one can steal session cookies as they fly by > in cleartext. > > As part of the engineering effort to turn on TLS for everyone, you should > also provide SPDY, or whatever they're calling it these days. It's valuable > not only for traffic analysis' sake, but because it offers server-side > efficiency gains that (in theory anyway) should mitigate the TLS overhead > somewhat. > > After that's done, there's a grab bag of additional security refinements > that are deployable immediately or with minimal-to-moderate engineering > effort. The roadmap mentions HTTP Strict Transport Security; that should > definitely happen. All cookies should be tagged both Secure and HttpOnly > (which renders them inaccessible to accidental HTTP loads and to page > JavaScript); now would also be a good time to prune your cookie > requirements, ideally to just one which does not reveal via inspection > whether or not someone is logged in. You should also do > Content-Security-Policy, as strict as possible. I know this can be a huge > amount of development effort, but the benefits are equally huge - we don't > know exactly how it was done, but there's an excellent chance CSP on the > hidden service would have prevented the exploit discussed here: > https://blog.torproject.org/**blog/hidden-services-current-** > events-and-freedom-hosting<https://blog.torproject.org/blog/hidden-services-current-events-and-freedom-hosting> > > Several people raised concerns about Wikimedia's certificate authority > becoming compromised (whether by traditional "hacking", social engineering, > or government coercion). The best available cure for this is called > "certificate pinning", which is unfortunately only doable by talking to > browser vendors right now; however, I imagine they would be happy to apply > pins for Wikipedia. There's been some discussion of an HSTS extension that > would apply a pin (http://tools.ietf.org/html/**draft-evans-palmer-key-** > pinning-00 <http://tools.ietf.org/html/draft-evans-palmer-key-pinning-00>) > and it's also theoretically doable via DANE (http://tools.ietf.org/html/** > rfc6698 <http://tools.ietf.org/html/rfc6698>); however, AFAIK no one > implements either of these things yet, and I rate it moderately likely that > DANE is broken-as-specified. DANE requires DNSSEC, which is worth > implementing for its own sake (it appears that the wikipedia.org. and > wikimedia.org. zones are not currently signed). > > Perfect forward secrecy should also be considered at this stage. Folks > seem to be confused about what PFS is good for. It is *complementary* to > traffic analysis resistance, but it's not useless in the absence of. What > it does is provide defense in depth against a server compromise by a > well-heeled entity who has been logging traffic *contents*. If you don't > have PFS and the server is compromised, *all* traffic going back > potentially for years is decryptable, including cleartext passwords and > other equally valuable info. If you do have PFS, the exposure is limited to > the session rollover interval. Browsers are fairly aggressively moving > away from non-PFS ciphersuites (see <https://briansmith.org/** > browser-ciphersuites-01.html<https://briansmith.org/browser-ciphersuites-01.html>>; > all of the non-"deprecated" suites are PFS). > > Finally, consider paring back the set of ciphersuites accepted by your > servers. Hopefully we will soon be able to ditch TLS 1.0 entirely (all of > its ciphersuites have at least one serious flaw). Again, see < > https://briansmith.org/**browser-ciphersuites-01.html<https://briansmith.org/browser-ciphersuites-01.html>> > for the current thinking from the browser side. > > zw > > ______________________________**_________________ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/**mailman/listinfo/wikitech-l<https://lists.wikimedia.org/mailman/listinfo/wikitech-l> _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
