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

71–80 of 99 posts

Re: SecureDrop

#71

Post by mpyne »

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.

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.

Re: SecureDrop

#72

Post by jlgaddis »

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.

If memory serves, there were several people who had been or were using Tor at the time the threat was sent. When he was questioned by the police, however, he confessed.

Re: SecureDrop

#73

Post by vhost- »

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…

Also, if you can swing https://washingtonpost.com?page=securedrop, the request will just look like it's to https://washingtonpost.com since query parameters are encrypted with ssl.

Re: SecureDrop

#74

Post by improv32 »

vhost- wrote: post #73
sandstrom wrote: post #69

Earlier quoted context omitted.

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…

Also, if you can swing https://washingtonpost.com?page=securedrop , the request will just look like it's to https://washingtonpost.com since query parameters are encrypted with ssl.

So is the rest of the URL, it could just as well be https://washingtonpost.com/securedrop

Re: SecureDrop

#75

Post by alex_duf »

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.

Clever

Re: SecureDrop

#76

Post by vhost- »

improv32 wrote: post #74
vhost- wrote: post #73

Earlier quoted context omitted.

Also, if you can swing https://washingtonpost.com?page=securedrop , the request will just look like it's to https://washingtonpost.com since query parameters are encrypted with ssl.

So is the rest of the URL, it could just as well be https://washingtonpost.com/securedrop

Oh right, paths are too. Sorry!

Re: SecureDrop

#77

Post by mpyne »

jlgaddis wrote: post #72
mpyne wrote: post #71

Earlier quoted context omitted.

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.

If memory serves, there were several people who had been or were using Tor at the time the threat was sent. When he was questioned by the police, however, he confessed.

That's possible, but doesn't really change the point. By bootstrapping a associations of identity-masking technologies with possible identities you allow "normal" law enforcement investigative techniques to unmask the identity.

Re: SecureDrop

#78

Post by meowface »

handsomeransoms wrote: post #55
meowface wrote: post #17

Earlier quoted context omitted.

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

Apologies, you're completely right. I think I got that impression from something someone else said in this thread.

Re: SecureDrop

#79

Post by chrisstanchak »

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…

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

Re: SecureDrop

#80

Post by iainnash »

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…

How about some simple cookie tracking an iframe that loads a random number of seconds after the page loads (like 10 - 60)? That might spam the logs randomly enough so that it couldn't be tracked. However, I think measures such as including the Securedrop page as a part of the root domain only under ssl would be the simplest solution in this case.
Post reply on HN