SecureDrop • Hacker News Board

Re: SecureDrop

#61

Post by FiloSottile » Mon, Jul 07, 2014, 6:00 PM UTC

handsomeransoms wrote: post #52

lawl wrote: post #41

Earlier quoted context omitted.

Either you misunderstood me, or I don't quite understand how that would not help. My suggestion is to embed an iframe to the posted URL on every page on www.washingtonpost.com. Every article, everything. I'd assume this would blast the logs enough that if you look at "time X-5" you'll have too many data points to actually make something out of it. Because everyone who reads an article on wapo will have also visited t…

(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…

Uuuh, hi there! Thanks for the effort you all put into making leaking safer for sources.

Other possible approach: load the landing page everywhere and show it with Javascript when the user clicks their way to it. I think it's an improvement on the iframe without drawbacks. How does it sound?

Re: SecureDrop

#62

Post by hackuser » Mon, Jul 07, 2014, 6:01 PM UTC

giarc wrote: post #32

FiloSottile wrote: post #26

If the leaker visits this page before opening the Tor Browser from a regular browser to copy the onion url, the whole thing is as safe as SSL as there will be a trail of the SSL connection just before the visit to SecureDrop. And they don't even explain to avoid it. OPSEC is hard.

That's like saying John Smith went to a bank withdrew money at 1pm on Jan 1. Then the bank was robbed at 1:10 Jan 1 therefore John Smith robbed the bank. I don't think you can connect visiting the info page and the very next SecureDrop file upload.

The threat here isn't only proof that is acceptable in court:

* Your actions could put you on a shortlist of people to be more thoroughly investigated.

* Your actions could tip off the people whom your information threatens; maybe they stop communicating with you (or worse) to shut off the leak.

* Per the Snowden release, the NSA tracked the communications of people within something like 3 degrees of their targets. With standards that low, it's not a stretch to think someone would track everyone visiting the Washington Post's secure drop box.

Re: SecureDrop

#63

Post by qb » Mon, Jul 07, 2014, 6:06 PM UTC

handsomeransoms wrote: post #53

FiloSottile wrote: post #26

If the leaker visits this page before opening the Tor Browser from a regular browser to copy the onion url, the whole thing is as safe as SSL as there will be a trail of the SSL connection just before the visit to SecureDrop. And they don't even explain to avoid it. OPSEC is hard.

(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 avoi…

> 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.

Print it in the physical newspaper. The German computer magazine c't prints their PGP key fingerprints in the masthead.

Re: SecureDrop

#64

Post by hackuser » Mon, Jul 07, 2014, 6:19 PM UTC

I worry that the Washington Post has unintentionally created a honeypot for leakers. I wonder if the Post has the resources to sufficiently secure it:

The requirement for security is to make successful attacks more expensive than they are worth for the attackers. (There is no perfect security, of course.)

How much is information leaked to the WP worth? It's information that can change the course of history; it could make war or peace; it could be worth billions or even trillions of dollars; it could simply change the course of the stock market or of one stock and be worth billions to an individual.

If I ran a state intelligence service, with the fate of my nation and all my citizens in my hands, I would be irresponsible not to invest in monitoring the Washington Post (and the NY Times, and others') "secure" tip line. If I ran an unscrupulous business, it would be worth it, if only for the information relevant to the stock market. EDIT: Also, the information can change the course of elections and be a target of unscrupulous politicians.

I find it hard to believe that the Washington Post or any news organization has the resources to protect assets that valuable.

Re: SecureDrop

#65

Post by im3w1l » Mon, Jul 07, 2014, 6:20 PM UTC

handsomeransoms wrote: post #52

lawl wrote: post #41

Earlier quoted context omitted.

Either you misunderstood me, or I don't quite understand how that would not help. My suggestion is to embed an iframe to the posted URL on every page on www.washingtonpost.com. Every article, everything. I'd assume this would blast the logs enough that if you look at "time X-5" you'll have too many data points to actually make something out of it. Because everyone who reads an article on wapo will have also visited t…

(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…

Downloading Tor from an inofficial source sounds like a recipe for trojans though... I don't think most people will have Erinn's signature to verify.

Re: SecureDrop

#66

Post by JoeAltmaier » Mon, Jul 07, 2014, 6:27 PM UTC

im3w1l wrote: post #65

handsomeransoms wrote: post #52

Earlier quoted context omitted.

(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…

Downloading Tor from an inofficial source sounds like a recipe for trojans though... I don't think most people will have Erinn's signature to verify.

Business idea: signature database with web interface. So download from anywhere, and look up the signature on the database to verify its authentic.

Re: SecureDrop

#67

Post by DustinCalim » Mon, Jul 07, 2014, 7:07 PM UTC

This is brilliant, and a smart move for the WP, despite some of the criticism's below. I think it's a much needed, if romantic, idea that harkens back to the transparency of Wikileaks, and gives WP a great little heads up over some of the other papers. I wouldn't be surprised to watch the others follow suit soon.

Re: SecureDrop

#68

Post by lawl » Mon, Jul 07, 2014, 7:23 PM UTC

FiloSottile wrote: post #61

handsomeransoms wrote: post #52

Earlier quoted context omitted.

(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…

Uuuh, hi there! Thanks for the effort you all put into making leaking safer for sources. Other possible approach: load the landing page everywhere and show it with Javascript when the user clicks their way to it. I think it's an improvement on the iframe without drawbacks. How does it sound?

Hard to verify that there are no ajax shenanigans.

It's a hard problem :/

Re: SecureDrop

#69

Post by sandstrom » Mon, Jul 07, 2014, 7:25 PM UTC

handsomeransoms wrote: post #53

FiloSottile wrote: post #26

If the leaker visits this page before opening the Tor Browser from a regular browser to copy the onion url, the whole thing is as safe as SSL as there will be a trail of the SSL connection just before the visit to SecureDrop. And they don't even explain to avoid it. OPSEC is hard.

(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 avoi…

A few things that may be helpful:

1. Make the entire site available under `ssl.washingtonpost.com` (ideally without the `.ssl` prefix).

That way, the domain won't be as suspicious as it is right now. I suspect that this is more or less the only content hosted on the domain.

2. Include an iframe for all (or a random subset of) visitors, loading this particular url (hidden).

By artificially generating traffic to the endpoint it will be harder to distinguish these from other, 'real' requests.

Use a random delay for adding the iframe (otherwise the 'pairing' with the initial http request may distinguish this traffic).

3. Print the link, url and info block on the dead trees (the paper), as other has suggested.

4. Add HSTS headers (http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security)

Re: SecureDrop

#70

Post by dublinben » Mon, Jul 07, 2014, 7:42 PM UTC

im3w1l wrote: post #65

handsomeransoms wrote: post #52

Earlier quoted context omitted.

(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…

Downloading Tor from an inofficial source sounds like a recipe for trojans though... I don't think most people will have Erinn's signature to verify.

It shouldn't matter where you're downloading the TBB binary, since you're going to verify the signature before trusting it, right? Surely you wouldn't just assume it was legitimate, and then install it.