Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

SecureDrop

ssl.washingtonpost.com

Post reply on HN
Print view View original

51–60 of 99 posts

Re: SecureDrop

#51

Post by handsomeransoms »

blauwbilgorgel wrote: post #16

Does anyone know what the codenames are like? If they are easy enough to remember, then they may be easy enough to brute-force? I think this is a great concept, yet perhaps too little, too late (Journalists should know PGP and drop boxes like these should have been common already). I also worry a bit because of Washington Post's track record with leaks, of the top of my head: - Washington Post was Snowden's first cho…

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!

Re: SecureDrop

#52

Post by handsomeransoms »

lawl wrote: post #41
FiloSottile wrote: post #38

Earlier quoted context omitted.

I don't see how that would help. The threat model here, the reason to use Tor is that they could be compromised and forced to log, and through Tor they would not know the leaker's IP. You only need the two "leak at time X, IP Y loaded this page at time X-5" datapoints to break this. An embedded page is not fetched by someone else.

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

Re: SecureDrop

#53

Post by handsomeransoms »

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

Re: SecureDrop

#54

Post by handsomeransoms »

lawl wrote: post #41
FiloSottile wrote: post #38

Earlier quoted context omitted.

I don't see how that would help. The threat model here, the reason to use Tor is that they could be compromised and forced to log, and through Tor they would not know the leaker's IP. You only need the two "leak at time X, IP Y loaded this page at time X-5" datapoints to break this. An embedded page is not fetched by someone else.

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…

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

Re: SecureDrop

#55

Post by handsomeransoms »

meowface wrote: post #17
lnanek2 wrote: post #10

Wow, Tor is still a thing? We have confirmation that security agencies have taken over exit nodes and injected spyware before to track targets. I'm surprised anyone uses it. It's like the security lottery.

The NSA leaks reveal that for the most part, Tor is still secure if you're using a sufficient number of intermediary nodes. If anything, the real concern here is the implicit encouragement to use local library computers, which would be much easier for a government agency (or cybercriminal) to infect with malware and observe.

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

Re: SecureDrop

#56

Post by stevengg »

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.

https://www.youtube.com/watch?v=9XaYdCdwiWU grugq talking about opsec

Re: SecureDrop

#57

Post by enraged_camel »

untog wrote: post #43
sspiff wrote: post #7

Earlier quoted context omitted.

I'd put the USA pretty high on that list. They've implemented plenty of their take-downs over the past year, and are more capable of introducing something like this than any SEA state.

I think many people living in the US are unaware of just how bad the rest of the world has it, sometimes.

That's not the point at all. The USA claims to be a bastion of democracy and freedom. Therefore it has significantly higher standards to live up to than countries like Russia and China.

Re: SecureDrop

#58

Post by lawl »

handsomeransoms wrote: post #54
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…

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

Wouldn't matter, the GET for a particular IP for the article would still show up before the GET for SecureDrop, the actual timing is irrelevant here, if there's always an article visit, and then a SecureDrop request.

I guess you could randomize if you load the iframe or not. Then you couldn't be sure if a visit was an actual visit or an iframe that was randomly triggered (with a random delay).

But for this to be useful you'd still need to instruct sources to randomly browse the page before going to SecureDrop. Which might work if you force them to click a link on the main-page to get to the SecureDrop page.

But if they go directly to /securedrop it will fail again because the GET /securedrop will show up as the first request from that IP, giving away that the visit was intentional.

So my current idea would be to randomly generate the actual /securedrop path in a non-predictable matter per client. Maybe something simple like securedrop-sha1(...). Then link to that from WaPo's main page. Forcing everyone to go trough WaPo.com. But then you still have the problem that you must make sure sources don't access this link from history or something.

Quite a lot of work, for still flawed security.

Re: SecureDrop

#59

Post by hackuser »

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…

> I'm not sure how we could explain to avoid it - where would the explanation go?

You could put the instructions on pages that many people visit regularly, true security through obscurity. For example, put the instructions in abbreviated form in a box in the footer of your front page (or in the footer of every page).

Re: SecureDrop

#60

Post by Torgo »

MikeTaylor wrote: post #40
hadoukenio wrote: post #2

Sometime in the near future, I predict that the US will require some form of photo I.D before using an internet kiosk. As usual, the spin will be to protect the children.

Good thing criminals have no way to obtain a fake photo-ID.

That's what "National Strategy for Trusted Identities in Cyberspace (NSTIC)" is for:

http://www.dhs.gov/xlibrary/assets/ns_tic.pdf

It's a national smartcard identity program that Obama admin has been pushing for a while.

Post reply on HN