Submission email notifications

[tildelowengrimm]

Checking SecureDrop every day is a huge hassle. Instead, it should tell me about new submissions, but without leaking any information.

Every day at 6am, SecureDrop sends me an encrypted email noting the number of unread submissions and the number of submissions received in the last 24 hours, even if these numbers are zero. If submission categories are used, each category's “owner” is sent the same info about their category.

[pwplus]

Just a thought, but it may be unfounded: Wouldn't just stating the number of recent submissions leak information about the time in which they were submitted? Especially since they are some what ordered. This would be most drastic in the case where an outlet has a small number of submissions. Let's say that an outlet has a single source that submits a trove of documents of the course of a few weeks. That source only works two days of the week and is equally likely to submit documents on either day. Doesn't the fact that emails stating when those documents were submitted (even though it is only a 24 hour window) greatly narrow down who could leak the documents since the emails would only show new documents within 24 hours after the source submitted them?

Strong encryption and a constant stream of emails may be enough to mitigate these concerns, but guaranteeing the source's anonymity should be of greater concern than journalist convenience. These are just my thoughts, so don't put too much weight into them.

[tildelowengrimm]

I don't see how an encrypted email that gets sent out every day whether or not there's a submission reveals any information whatsoever.

[garrettr]

@pwplus I don't understand your critique.

The goal here is to avoid leaking information about source behavior to an adversary who is capable of performing traffic analysis on the status emails. The easiest way to do that, while still being convenient for journalists, is to do what @flamsmark suggested in his initial comment, plus a little more. You need to:

1. Send the email on a regular schedule, regardless of the activity on the server. This interval could be configurable by the journalist (every day, 2 days, week, etc.), it simply must be unrelated to any source activity.
2. Encrypt the email end-to-end (obviously)

At this point, the only remaining signal to an adversary is the size of the encrypted email. Each notification email should be padded to ensure that all emails have the same size, regardless of their contents. This requires a unified and well-defined format for all possible notification emails (depending on categories, roles, etc.)

The only subtle point is, once padded, we need to avoid compressing the emails before encryption. Otherwise, an adversary could perform a traffic analysis attack on the size of the emails, similar to the CRIME attack on HTTPS. Similar to CRIME, allowing compression in this context would enable a chosen plaintext attack because:

1. The email format will be well-defined (open source)
2. An adversary can perform actions on the Source Interface that will deterministically influence the contents of the emails.

Once encrypted, any further compression (e.g. applied by the mail server or transport) does not lead to a potential attack. I don't think they'll ever be so large that compression makes a meaningful impact on their storage or transmission.

Note that GPG compresses plaintext by default (this is actually a terrible idea, but it's GPG so not a big surprise there). We'd need to pass -z 0 to gpg to avoid compressing the plaintext in this context.

[tildelowengrimm]

If the notification is really simple, the size shouldn't indicate much. “There are XX unread submissions of which XX where submitted in the last 24 hours.” doesn't leave a lot of room for adventure.

Or pad notifications with poetry and/or gifs.

[trevortimm]

Agree that this would be a nice feature and @flamsmark's proposal would be a good way to implement it to mitigate leaking sensitive info. However, before going forward we should keep in mind that this potentially could diminish one of the features of SecureDrop which we talk about when describing the benefits to others: newsrooms often have compromised networks, and that right now, nothing about SD submissions ever touches that network. Right on our front page, we say SecureDrop is designed to be used in high-risk environments like that.

The current workflow requires the journalist log onto their regular workstation using Tails. If we implement this feature, the email would come to their normal workstation, and even if the alert is sent using PGP, if their computer or network is compromised, it is possible for the attacker to either get the PGP key off that computer or wait for the journalist to decrypt it and read it then.

Of course one could say the same if their firmware if compromised and an attacker can somehow see what they're doing on Tails. However that is at least a much more sophisticated attack.

In @flamsmark's proposal, the info would be less specific because it only sends it once per day and does not specify the source. Personally I do think the chances are low that this information would be useful to an attacker, and we might decide that the trade off is worth it, but we should at least be conscious of it.

[garrettr]

@trevortimm Good point, thanks for bringing it up. It depends on the content of the notification emails. If they are, as @flamsmark has suggested, simply a summary of meta-activity, e.g.

7 new sources
15 new submissions

then it's not a concern. If the emails are more detailed (which would make them more useful/helpful), e.g.

Since you last logged in, there are 7 new sources.

You have replies from:
    * source name 1
    * source name 2
    * ...

You have new submissions from:
    * source name 1
    * source name 2
    * ...

I think the 2nd form would be much more useful, and the source names are designed to be random pseudonyms so it might be acceptable to expose them to a less trusted security domain (the journalist's computer). It does leak some information (metadata) to an adversary who can compromise the journalist's computer.

[pwplus]

What I was trying to say is that if the emails were some how compromised (court order or a hacked email account, etc), having a 24 hour creation time could greatly narrow down the possible list of sources if a company or agency were able to get those emails. My example was just to show that if there were only a single source, then a company with those emails would have a pretty short list of who to look at as possible sources. I can see how that is not so clear from my earlier comment.

Like I said, encryption and now the things Garrett mentioned are possibly enough to protect from this.

[tildelowengrimm]

Right now, the biggest hurdle is just getting people to check SecureDrop — they're busy and (especially during pre-launch testing) the probability of seeing an empty document interface day after day is demoralizing. Adding more info might be more useful someday I guess, but what I really want is a push notification that says whether or not to do the work of logging in to check for submissions. Minimal information is fine. Even if it just said “check SecureDrop" or “don't check SecureDrop", that'd be great.

[garrettr]

@flamsmark Thanks, that's helpful feedback! Perfect is the enemy of the good, and all that 😁

[tildelowengrimm]

I seem to have duplicated Issue #544 .

[Taipo]

Assuming you have some journos that will check in daily regardless, and others that do so more randomly due to their other work load, another possible way of addressing this would be if SD only sent notifications if a journo had not checked in for say x days after a submission (lets say for example sake, 2 days).

[tildelowengrimm]

I think it preferable for notification behavior to be completely undetermined by either submissions or journalists logging in.

[ajvb]

Going to work on a very simple implementation of this for the hackathon.

Per conversation with @fowlslegs and @redshiftzero, I'm going to implement this as a daily cronjob that runs a python script that parses through the OSSEC logs, looks for changes related to new submissions, and sends an encrypted email either saying "There are no new submissions" and "There are new submissions" .

[ajvb]

@fowlslegs @redshiftzero This may not actually work as we originally thought.

From: http://ossec-docs.readthedocs.io/en/latest/faq/ossec.html

OSSEC does not store the logs sent to it by default. If a log does
not trigger an alert it is discarded, and logs that do trigger alerts
are stored with the alerts in /var/ossec/logs/alerts.

This means that for this too work from the monitoring server, we would need to configure the changes to trigger alerts. At that point, you would lose the ability to hide when the notification would come in + you would have the problem discussed this morning of mixing in application-level functionality with ops-specific functionality.

[conorsch]

@ajvb OSSEC does not seem the right tool for this job. What about a POC Python script that:

1. checks the sqlite db for any "unread" submissions
2. outputs that number as an integer, even if it's zero

Bonus points if it returns a non-zero exit code for zero unread submissions, and a zero exit code if unread submissions were found. Then we can rather trivially hook up an alerting mechanism, such as piping to encrypted email to the instance Admin.

To be clear, we have no method of contacting registered Journalists outside of the Document Interface. These alerts at present would apply only to the Admin, who already receives OSSEC alerts via encrypted email.

[ajvb]

@conorsch

So if this could use db.py, then:

#!/usr/bin/python
from sys import exit
from db import Submission

if __name__ == "__main__":
    n = Submission.query.filter_by(downloaded=False).count()
    print n
    if n > 0:
        exit(0)
    else:
        exit(1)

Then we can rather trivially hook up an alerting mechanism, such as piping to encrypted email to the instance Admin.

Would you mind explaining how this could be done within the current infrastructure? Wouldn't this require sending the email from the application server or am I missing something?

[psivesely]

We'd want all DI users to receive these notifications, not just admins. How does the admin manage access to email notifications in a way that doesn't threaten the separation of the mon and app servers? It'd be nice if when a journalist was deleted from the DI, they stopped receiving emails, but we can't just allow the journalist app running on the app server to set values on the mon server. We also shouldn't install a MTA on the app server.

[ajvb]

We'd want all DI users to receive these notifications, not just admins.

Agreed, but may be harder. Might be easier to do just admins for the MVP?

It'd be nice if when a journalist was deleted from the DI, they stopped receiving emails, but we can't just allow the journalist app running on the app server to set values on the mon server. We also shouldn't install a MTA on the app server.

Not sure how we can get away with both of these:

• App server can't set values on the mon server
• shouldn't install a MTA on the app server

If OSSEC is not the right tool for this (which I agree that it is not), then there needs to be someway for the monitoring server to pull data from the app server.

What is the safest way that the monitoring server can get the boolean response from the application server on whether or not there is new data?
Or, what is the safest way to send emails from the app server?

I feel like the safer route currently is to have the monitoring server get the data from the application server as it already is getting data from it. Can we mimic the safety measures of ossec within the application/API we provide for getting this data?

[psivesely]

I say this often, but this is yet another problem that would be much easier to solve via the reading room client. The problem is that we want to provide a unified management interface to the admin, while storing state on two backends that must remain compartmentalized. We can't use code provided by one of the backends to do this (i.e., the DI) because this would break the compartmentalization, so we must provide a native application via a signed package. Anyway, back to addressing this for the current SD landscape....

How about we build a little tool for the admin workstation that lets the admin add and remove users from the email notifications list, manage-notifications? We could of course make a desktop icon to launch it. The script downloads a plaintext configuration file from the monitor server over SSH, and opens it up in some friendly, simple GUI editor (maybe even Zenity). The format is very simple:

email1 fingerprint1
email2 fingerprint2

After modification, the contents are copied back to the monitor server. We could do some sanity checking to make sure each field at least appears to be a valid email address or PGP fingerprint.

When journalists are added or deleted via the admin interface, we should change the message flashed to inform the admin they might want to modify this list.

As to the email notifications themselves. I think the app server should create a new, simple log that gets rotated daily, and provides a boolean response to whether there are unread messages. I think we should use OSSEC to parse this log, and a new command (via a Python script) to send email notifications.

[ajvb]

How about we build a little tool for the admin workstation that lets the admin add and remove users from the email notifications list, manage-notifications? We could of course make a desktop icon to launch it. The script downloads a plaintext configuration file from the monitor server over SSH, and opens it up in some friendly, simple GUI editor (maybe even Zenity).

I like this, but it seems frail and prone to weird bugs. Is it not possible to have the MVP require you to SSH into a the machine and edit the file using vim or similar?

As to the email notifications themselves. I think the app server should create a new, simple log that gets rotated daily, and provides a boolean response to whether there are unread messages.

👍

I think we should use OSSEC to parse this log

I don't believe OSSEC is the right tool for this, per my former comment: #1195 (comment)

This probably breaks the compartmentalization mentioned in your previous comment, but would it be possible have the mon server simply scp/download the file, read it, and then delete it?

a new command (via a Python script) to send email notifications.

👍

[psivesely]

I like this, but it seems frail and prone to weird bugs. Is it not possible to have the MVP require you to SSH into a the machine and edit the file using vim or similar?

Yeah, I think that's probably the way to do this for now, lest we invest two much time into it, when it's important we begin to focus our energy on more long-term solutions.

I think we can have OSSEC call a customized active response, that is not really active. What I mean by this is that it calls a Python script that perhaps maintains a simple binary state (e.g., a text file that should only contain a 0 or 1 at any time). Then we create a second script that sends one of two email messages, based on this binary state, to an admin-maintained list of users. This second script is run as a cron job at a set time. This could be maintained/ provisioned by Ansible--the list of users to email, the time to email them, and whether email notifications are wanted at all--by adding new vars.

I still think this is a hacky solution, but at least it adds minimal code and doesn't introduce new communication processes between the app and mon servers. I need to get back to this when I have more time to play with OSSEC + dig through the documentation. There's gotta be a way to do this safe and easy.