handsomeransoms's comments

Great point, just a nit: Rust does not have mandatory GC.

  > You are implying something fundamental: that the encrypted traffic could be adequately analysed for insight without the need for decryption.
  > Yet to do so would be to defeat SSL itself, or at least to declare it as insufficient to adequately protect secrets.

This is possible through HTTPS traffic analysis, see [0] and [1] for starters. Of course, it's much easier for Cloudflare to do analysis for DDoS protection if they have access to plaintext.

Whether this means that SSL is, as you say, "insufficient to adequately protect secrets" is an interesting discussion to have.

[0] http://arxiv.org/pdf/1403.0297.pdf

[1] http://blog.ioactive.com/2012/02/ssl-traffic-analysis-on-goo...

Yeah, I'm having a hard time finding details on the vulnerabilities. A lot of the links in the advisories are broken, and the descriptions on the Mitre CVE pages seem to be awaiting update.

Anybody know how to find better descriptions of these bugs, or the patches that fixed them?

Oh, yeah :/ The login page is over SSL, but everything after that is not (!!) This protects your password but not your OkCupid session cookies. It's an improvement over no SSL at all (which was the case for a long time) but still leaves a lot to be desired.

Doesn't appear to work at all in Firefox 30 on Linux. Clicking one of the images after scrolling a bit (triggering the loading of additional content) leads to an infinitely spinning bar - no content ever loads. The same STR works without issue in Chrome.

(SecureDrop dev here) Glad you like it! It's hard to tell people who get excited about fun UX ideas that they can't use JS, but from my experience as a browser security engineer, eliminating JavaScript (and plugins, which the TBB does already) dramatically reduces the browser's (unfortunately enormous) attack surface.

Good idea, but, like many of these ideas, easier said than done.

We've been working on this with some of our deployment partners for a while now :D Great idea! I didn't know anybody else did it, it's cool to hear about c't.

Definitely! The challenge is getting the news orgs to change their entire site, which often involves a lot of complex, entrenched infrastructure and sometimes involves reluctant third parties such as ad networks.

We're working on a best practices guide for deployments [0]. I'll make sure these suggestions go in there. Feel free to take a look and comment if you're interested!

[0] https://securedrop.hackpad.com/SecureDrop-Deployment-Best-Pr...

(Securedrop dev) That's not an implicit encouragement, despite it being your interpretation. Library computers, in my experience, do not typically allow you to install software on them, such as the Tor Browser Bundle, which is needed to access SecureDrop.

The explicit encouragement that is clearly written on the landing page is to use a personal computer (not a work computer) and a public network (e.g. a coffee shop).

Maybe you could use JS to randomize the timing of the iframe load after the article load?

(Securedrop dev here) This is a really good point. Unfortunately, we're "as safe as SSL" no matter what, unless the source has a separate way to verify the .onion address on the SSL-protected page. They can use the SecureDrop directory for that (and we're working on other schemes as well), but it's not automated so only a handful of very cautious sources would likely do this.

I'm not sure how we could explain to avoid it - where would the explanation go? Visiting that page would be just as much of a correlation, no? It's kind of a chicken and egg problem, unless the source is already using Tor.

Avoiding the "trail of the SSL connection" also suggests we should be doing something to combat website fingerprinting, which we have discussed but do not have a clear solution for yet.

Our current thinking is that just visiting the landing page is not enough to prosecute a source. We can do better, and are working on it, but it's difficult.

(Securedrop dev here) We often suggest ideas like this to deployment operators, and others as well. For example, we encourage deployments to mirror the Tor Browser Bundle so sources don't have to go to Tor's (monitored) website to get it. We encourage them to use SSL everywhere so the "trail to the landing page" is harder to spot. We encourage the exact "hidden iframes" idea you propose here. And we encourage them to deploy on a path, not on a subdomain (because hostnames are visible even with TLS). At least WaPo is doing the last one right!

Generally, it is very difficult to convince the operators of sites like the Washington Post to do things like this, but we're working on it!

Securedrop dev here. We tried to balance the memorizability of codenames (aka Diceware passphrases) with their length. The current minimum length is 8 words from a list of 6969 words, so you get math.log(69698, 2) = 102 bits of entropy, which is quite good. Additionally, the codenames are stretched with scrypt with affords an extra (approx.) 14 bits of entropy (that's our current work factor).

We are continuing to discuss and debate this trade-off. Other ideas welcome!

It is not useless if you have some other way to verify the key, such as the Web of Trust.

It's also on the keyservers: http://pgp.mit.edu/pks/lookup?search=0xEBA34B1C&op=index

(Firefox dev here) When you say Security Exception, do you mean you're seeing a certificate error on this page? The certificate is valid for me, so that indicates something dodgy on your end (perhaps a captive portal, or middlebox on a corporate network).

With enough sampling, it should be possible. Additionally, the values you are trying to infer are pretty small (8 bytes each) so that makes it easier.

> Additionally, what about addressing insecure forms that fail to utilize https.

FWIW, Firefox detects insecure login forms and emits a security warning to the web console. This is aimed at developers, however, not users (because the developers are the only ones who can improve the situation).

Our heuristic is imperfect as well. We simply detect <input type="password"> fields on http pages. This works well enough. Trying to detect when developers are abusing <input type="text"> for a password field is non-trivial.

Mozilla dev here! Sorry to hear you're having so many problems! A few things to consider:

1. Many of Firefox's stability issues are due to 3rd party components (plugins and addons). I recommend disabling all of them, restarting the browser, and seeing if the issues persist. You can then selectively enable (or click-to-play, for plugins) them to improve your experience while maintaining stability. 2. You could also try a profile reset [0], which tends to magically fix some problems (especially if you've had the profile for a while).

[0] https://support.mozilla.org/en-US/kb/reset-firefox-easily-fi...