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

81–90 of 99 posts

Re: SecureDrop

#81

Post by wmj »

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…

Print a QR Code for SecureDrop in every issue of the newspaper. Hell, feature it as part of a story announcing SecureDrop the first time you print it. Then just print it in a consistent position with minimal explanation from then on.

This may be one of the rare cases where the use of a QR Code is justified.

Re: SecureDrop

#82

Post by tlrobinson »

Random question: has anyone attempted to build a Tor-like system (or bridge to the actual Tor network) using WebRTC?

Assuming you were able to avoid the "JavaScript crypto problem", would this be a good or bad idea?

Re: SecureDrop

#83

Post by handsomeransoms »

sandstrom wrote: post #69
handsomeransoms wrote: post #53

Earlier quoted context omitted.

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

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

Re: SecureDrop

#84

Post by handsomeransoms »

qb wrote: post #63
handsomeransoms wrote: post #53

Earlier quoted context omitted.

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

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.

Re: SecureDrop

#85

Post by handsomeransoms »

chrisstanchak wrote: post #79
handsomeransoms wrote: post #53

Earlier quoted context omitted.

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

Glad you are doing this. You should just stick this link/info in the footer of all Washington Post pages.

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

Re: SecureDrop

#86

Post by handsomeransoms »

toni wrote: post #5
dewey wrote: post #4

In case you don't have Tor installed and want to know what it looks like: https://imgur.com/GbwKfuG,D2aWi25,glApNg3

Very refreshing to see a big, red warning in the screenshot about the fact that Javascript is enabled ! Usually you see the same thing when Javascript is disabled, asking you to enable it.

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

Re: SecureDrop

#87

Post by ot »

sandstrom wrote: post #69
handsomeransoms wrote: post #53

Earlier quoted context omitted.

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

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

Or, since the content of this page is mostly text, it could be included in the HTML of all washingtonpost.com home page requests with very small overhead, and shown with a non-tracked javascript action (link/button), so it is all client-side and indistinguishable from a normal request to the home page.

Re: SecureDrop

#88

Post by grugq »

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.

That is a poor analogy of the threat. Basically the problem is about attracting adversarial resources. Any suspicious activity will attract more attention and thus make it more likely the adversary will find real evidence.

I wrote up an analysis of exactly this problem last year: http://grugq.github.io/blog/2013/12/21/in-search-of-opsec-ma...

Re: SecureDrop

#89

Post by grugq »

mpyne wrote: post #71
giarc wrote: post #32

Earlier quoted context omitted.

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.

A Tor user at Harvard was successfully tracked when he sent a bomb threat, since he was the only user on the Harvard LAN using Tor at the time the threat was issued. That wasn't proof , of course, but it didn't need to be proof, just a good lead for law enforcement to kick-start their investigation.

My analysis of that incident: http://grugq.github.io/blog/2013/12/21/in-search-of-opsec-ma...

Re: SecureDrop

#90

Post by toni »

handsomeransoms wrote: post #86
toni wrote: post #5

Earlier quoted context omitted.

Very refreshing to see a big, red warning in the screenshot about the fact that Javascript is enabled ! Usually you see the same thing when Javascript is disabled, asking you to enable it.

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

Agreed with you completely. Every time a new web app is posted to HN and it doesn't work without enabling Javascript, a small circle of security-conscious people complain about it. The responses from other people are in the lines of:

"Are there really people that browse the internet without enabling Javascript in 2014?"

"Well, 0.01% of your users have Javascript disabled, you can safely ignore them"

"Javascript is an important part of the web, if you have it disabled, you have no right to complain"

We need more people like you to advocate secure browsers without using Javascript.

Post reply on HN