freedomofpress / securedrop Goto Github PK

The source's interface should display the securedrop's version info on each page.

Changed name due to debate over whether CAPTCHA is right method to use. Consensus is on developing a responsive approach that combines several methods, including CAPTCHAs.

Add an option to localca.sh script option to revoke a certificate

In the footer of http://world.std.com/~reinhold/diceware.html it says the license of the wordlist is Creative Commons Attribution. Where's the best place to give them attribution inside the repo?

If you want to contribute this would be a good place to start. Lots of people are suggesting pretty substantial changes to the codebase and tests would make sure those changes don't unintentionally break things.

Demo of the SVS Interface to generate/encrypt SSL and GPG pub key to external hard drive, pointing out the secure wipe procedure

All over server_setup.py it's called the document server the journalist server, including at the end where it lists hidden service URLs.

D'oh!

Does it make sense to include the wordlist in the repo? Seems one could make a scraper and access all messages, no?

Right now these are listed in HACKING.md.

The serverInstall.sh script should output the tor onion url and the Document Server's web interfaces url.

It appears that in https://github.com/deaddrop/deaddrop/blob/master/crypto.py#L97 the data is unencrypted on the disk. Even if the disk is encrypted, I think this is sub-optimal. I would suggest either a tmpfs (not so solid for various forensics reasons), encrypting the files on the client as they're uploading, or encrypting them in chunks once they're in the server's memory.

I was just having a look at some of the history of crypto.py trying to figure out the intentions of some changes when I noticed that the history only goes back a few days & the git logs for deaddrop have not been preserved. I was looking at a file called 'crypto.py' to understand some changes, when I noticed the log only goes back a few days. There is an old log message entitled "fix various security issues identified by security team" - aaronsw (76af29c)

It makes it easier for future devs to easily understand intentions of past contributors. This is especially important when the file is called 'crypto.py'

update installation clean up script for the changes made for milestone .1

Add an option to only to create a new journalist user cert

NIST does not endorse RSA in new systems. They now favor ECC. GnuPG is not my first choice as a crypto primative but if it will be used, I think using a 521 bit ECC key pair is currently a reasonable idea.

Drop the tor2web user-agent to prevent possible leaks.

scrypt is another adaptive key stretching algorithm in the vein of bcrypt. Unlike bcrypt, however, it was specifically designed to thwart attacks by powerful adversaries capable of building large clusters of custom hardware for password cracking. Given securedrop's threat model, scrypt might a better choice than bcrypt; however, scrypt is significantly newer and comparatively less tested.

We should have consistent coding styles.

EDIT: Renamed title to reflect current discussion.

I have a working script with a pointer to the new wordlist and concatenates the 26 individual CSV files into a single file called 'wordlist'

Create app gpg keypair in the localca script

Functionality:

• Decrypt documents encrypted with the application public key
• Encrypt documents with journalists' public keys
• Provide a way to secure-wipe USBs

@diracdeltas has been working on this in the https://github.com/freedomofpress/securedrop/tree/journalist-interface branch. Wrote a TODO in the comments if anyone wants to help out.

Demo of downloading and verifying required files

The ossec binary and the grsec kernel should be hosted in deaddrop ppa to make it easier to keep files updated.

This should either be config option or a randomly generated key with high entropy (which is then encrypted to a long term, offline public key): https://github.com/deaddrop/deaddrop/blob/master/crypto.py#L66

Any host that has a public name with HTTPS should be pinned or at the very least send HSTS headers. If possible, I'd suggest sending a request to the Chrome team to ship such a cert in a few browsers.

This should be done for the New Yorker site but also it should be a best practice.

The server_setup.sh script should generate and use ssh keyfiles so the person implementing is not prompted for their password repeatedly.

OSSEC uses the email alerts to notify the journalist of file changes and other security alerts. The securedrop environment does not currently have an smtp server, so the organization that is implementing securedrop will need to provide access to smtp relay. This is a security weakness. An attacker could compromise the external email server to ensure that the journalist is not aware of un-authorized changes in the environment. Either an smtp server should be deployed in the securedrop environment or the ossec web ui http://www.ossec.net/wiki/index.php/OSSECWUI:Install could possibly be leveraged.

Steps to reproduce:

1. Set up according to instructions in HACKING.md
2. As source, visit the site. "Submit Documents", "Continue". Enter a test message and "Submit".
3. Visit the journalist site. Click the link of the new submission.

Expected behavior: Page contains a link to download the new submission

Actual behavior: 404, blank page with the text "not found"

In the install script need to update to config bcrypt salt and hmac random value

In the source and journalist base templates, the footer contains a "Powered by DeadDrop" logo linking to http://deaddrop.github.com/. This will leak the source/journalist IP address in server logs by the HTTP request made to deaddrop.github.com (now deaddrop.github.io). We cannot trust GitHub to keep referer and access_logs private.

https://github.com/deaddrop/deaddrop/blob/master/source_templates/base.html#L27
https://github.com/deaddrop/deaddrop/blob/master/journalist_templates/base.html#L27

When you first install SecureDrop, this is what the source Tor hidden service looks like. It shouldn't say Tip Box or DeadDrop anywhere, it should say SecureDrop.

Also, while we're at it, lets give it a white background with dark text, to make it seem friendly and less spycrafty.

It is currently up to the organization implementing securedrop to securely configure a network firewall. Possible solution is to recommend a network firewall like pfsense and provide best practices for securing it.

I'm skeptical of using GnuPG but if you're going to use it, I suggest you blind the messages such that the key ID is not embedded - this should at least ensure that a specific key may not be demanded by cryptographic identifier :

       --hidden-recipient name

       -R     Encrypt for user ID name, but hide the key  ID  of  this  user's
              key.  This  option helps to hide the receiver of the message and
              is a limited countermeasure against traffic  analysis.  If  this
              option  or --recipient is not specified, GnuPG asks for the user
              ID unless --default-recipient is given.

There are other reasons but the above seems sufficient to me.

Right now the instructions for how to use SecureDrop are non-existent. I began a markdown document to start writing this out: https://github.com/freedomofpress/securedrop/blob/master/docs/user_manual.md

It needs to be finished. Also this is where we should document how to encrypt and decrypt files, and wipe the USB drive for #27.

In the New Yorker diagram, it is suggested that the journalists will use a VPN - I suggest that you use a Tor hidden service, specifically, a stealth hidden service with authentication. This ensures that all required systems only touch the network with Tor - no need for other third party code and no need for higher privileges (eg: pppd, etc) when that code touches the network.

The current INSTALL file https://github.com/deaddrop/DeadDropDocs is heavy on crucial security steps for what to do if you plan on deploying deaddrop in production , light on details that can quickly get devs up and running and test improvements.

Looking at crypto.py, in order to generate a wordlist, crypto.py wants to import a module named config which contains a number of settings. Originally I thought this was python's config library, but now I think it seems likely there was a file called config.py at one stage. It's easy enough to get around but little hang-ups like this are what should be clarified in the HACKING file so time is saved.

Right now journalists identify each source as a hash. It would be better if the source had a name. It would be fun to write a Python script that turns hashes into human-meaningful names (and keeps a store of names used already in order to avoid collisions).

An attacker may MITM the original connection to the New Yorker website. As a result, the attacker may change the .onion URL in transit. An attacker is able to see that the submitter isn't reading the New Yorker and if they download the Tor Browser as their next action, I suspect the attacker may simply choose to break connections to the Tor website. This will stop a potential submission and it also presents the attacker with an opportunity to insert malware (at download time) to discover the documents under consideration for submission.

There is a vulnerability where the encrypted file is identified by time in the file name. This timing information is sensitive and if a journalist wishes to have such metadata, I suggest it should be encoded inside of the GnuPG message. However, I strongly caution that such accurate timing information is best to simply not collect and if it is required for some reason, discarding it is prudent.

The code in question is here:
https://github.com/deaddrop/deaddrop/blob/master/source.py#L62

A critical concern for the claims made for the deaddrop tool, is the central master server arrangement of the TOR system. TOR's main listing of available TOR entry nodes is provided from only one central entity and source. This central entity is tapped by most institutions, its routing is MIM and tampered by nation-state perimeters, even large cities and ISPs falsify the entry point listing for the TOR system.

As a result, any new client is forced to communicate first with the compromised and high-risk central listing of tor-nodes, meaning that the potential client is murdered before succeeding at getting the horrible interface clients installed or working correctly.

This has been a thoroughly documented and deadly situation for a decade, the system is designed to identify and isolate any initial contacts with the master system, resulting in the full compromise of the potential client with deadly potential.

As there is no guarantee of the integrity of any component of the TOR system, and more importantly that there is absolutely no trust in the communications between the client and the central master server, it brings further concern that all communications with the TOR master server or publicly listed NODE entry points are immediate wiretap orders.

In most cases, the AUTOMATIC wiretap order from (american) ISPs activate within about 4 seconds, meaning all traffic, including initial key shares, are trapped by the aggressor entity PRIOR the transfer of any "protected" data.

Yes, this prevents services providers like the new NYT project from having any coherent awareness of the source of content, but it provides a major deadly liability for the victim sources.

AT THE INSTANT ANY CLIENT ATTEMPTS TO COMMUNICATE WITH TORPROJECT, THEY ARE IMMEDIATELY BOUND TO A FISA AND OTHER INTERNATIONAL WIRETAPS.

The result of which, is a deadly serious violation of the public interest and human rights, and a very deadly resulting situation. Any client of the system is immediately victimize simply due to their initial contact with a central system, regardless of their intent.

This includes browser plugin repositories, all of the other TORProject tool sources.

It must be made clear that in no way does the deaddrop nor TOR system PROTECT the victim. It must be made clear that TOR is an explicit vulnerability in the transfer of public interest information. It must be made clear that to contact TORProject results in an IMMEDIATE intelligence-gathering wiretap, regardless of intent or content transferred. And it must be made clear that the entire TORProject publicly accessible system is provided by entities who know how to MIM and molest the data and content in the middle. If the TorProject code was fully valid in intent, it still is compromised of and by parties who emulate and exploit its perceived function.

Connecting to TORProject in many regions creates a deadly situation.

cc: US Department of State, Naval Research, other sponsors of TOR.

Demo of installing checking and locating tails persistent storage

Switch from sha256 has of codename on source and journalist, SVS interfaces to using py-bcrypt.

Temp host the ossec binary on the FoP website until PPA is set up

py-bcrypt needs to be installed on source document and viewing interfaces

We can't do this any time soon because Tails Server isn't released yet, but here's the blueprint: https://tails.boum.org/blueprint/server_edition/

When there's a stable version released keeping the servers secure will be way simpler if we make the source server, document server, and monitor server all use Tails instead of Ubuntu.

It seems that the general architecture is overly dangerous - I might be mistaken about how the New Yorker has deployed DeadDrop, so forgive me if I'm just totally missing a major part of the documentation...

Specifically, it seems that source.py and journalist.py should run on entirely different systems. There is no reason to run them on the same system. As an example, one could have two systems - both with a stealth hidden service - and with something like rsync, one side (source) could encrypt data, push it into a directory and then the remote (journalist) side pull it down. This would create two different kinds of compartmentalization: one is cryptographic (eg: source's file is encrypted), and the other is using the natural boundaries of the entire system, even though the web app is more constrained. This allows for bidirectional sharing of data in a privacy by design manner.

If you have such a design, it also ensures that when the source interface is compromised - it will not expose the journalists beyond the ability to mount better attacks on GnuPG. Such a compromise will of course allow the attacker to compromise sources in the future...