Would it be possible to have a daily mail notification about the content of the journalist interface ? Every day a mail would be sent to the journalist from the app server. It would just state the number of unread documents. So the journalist does not need to login to the journalist interface if there are no unread messages / documents. If there is nothing to read the journalist would still receive a daily notification. Someone watching would know the journalist receives notifications from SecureDrop which is already known because the landing page advertises the availability of SecureDrop.
It may be better to send the notification from the mon server. It already sends notifications and can inspect the app machine to figure out if there are more submissions. And it’s presumably safer than adding the ability to send mail to the app server.
Ask for an email + GPG key + fpr named journalist-heartbeat (because it will send a mail every day)
Configure the OSSEC server to know this email, in the same way it knows where to send OSSEC alerts
On the app server
a daily cron creates /var/run/securedrop/past-day-submission with the number of submissions received in the past 24h
On the OSSEC server
/var/run/securedrop/past-day-submission is monitored by OSSEC
a daily cron runs
if /var/run/securedrop/past-day-submission checksum is the same as the checksum of a file containing a zero, send an mail to the journalist-heartbeat email saying there are zero submissions
else send an mail to the journalist-heartbeat email saying there are submissions (number unknown)
Definitivly agree, as it must be a pain in the ass to connect regularly only to discover there are no new submissions.
In terms of cryptanalysis, the “zero submissions” emails should also potentially look like and be as long as the emails stating that there are submissions.
The first step was to refactor sdconfig which took some time. Now taking a closer look at how OSSEC could be used.
On the app server
a daily cron creates /var/lib/securedrop/past-day-submission with the number of submissions received in the past 24h
If we had a more recent version of OSSEC we could use /var/ossec/bin/agent_control -r -a to trigger the check immediately. Instead we just wait tail -f /var/ossec/logs/ossec.log and be patient. The check takes 10min on a VM.
On the OSSEC server
Whenever a notification is to be sent by OSSEC it goes thru the send_encrypted_alarm.sh shell script. It needs to be modified to not send notifications about /var/lib/securedrop/past-day-submission changing to the admin because it is supposed to change.
A cron job runs daily and use syscheck_control to get the hash. And if the hash matches a file with zero in it, we know nothing arrived /var/ossec/bin/syscheck_control -i 1024 -f /var/lib/securedrop/past-day-submission
For the record, a gitter conversation on that topic today.
soooo … I’ve a draft implementation to notify journalists about the number of submissions received in the past 24h, with the idea that such notification is sent encrypted to an address that’s different from the OSSEC address. But sent from the ossec server because that’s where mails are sent.
Conor Schaefer @conorsch
22:58
with you so far. my concerns are mostly around the potential leakage of information in the notification mails, but continue.
Loic Dachary @dachary
22:58
it’s here daily email alert to journalists about submissions received in the past 24h · Pull Request #2803 · freedomofpress/securedrop · GitHub
so the mail has one number and is sent daily, encrypted, therefore there is no way to determine if the number is 0 or 1 or 10
on the app server a daily cron creates a file in /var/lib/securedrop with the number of submissions more recent than 24h
redshiftzero @redshiftzero
23:00
what about a “there has been activity since you last logged in - you should check securedrop” or “there is no new activity on securedrop” message only?
Loic Dachary @dachary
23:00 @redshiftzero sure
the key is indeed to know if there was activity or not
the ossec agent has a command that cat the file
and it runs once a day
Loic Dachary @dachary
23:05
and the server has a rule in the multidrop group and whenever the group receives a mail it forwards it to the journalist alias which is then processed by procmail to encrypt/send to the journalist email
this is my first shot at doing something non trivial with OSSEC and I’m seeking input before diving into tests and what not
redshiftzero @redshiftzero
23:08
hmm so one issue with implementing this in OSSEC: is this feature for the admin or the journalist?
Loic Dachary @dachary
23:08
I did not implement the journalist gpg/mail because it waits on freedomofpress/securedrop#2758
it’s for the journalist so the journalist knows when to go to the journalist interface
instead of going for nothing
redshiftzero @redshiftzero
23:09
right, but the journalist typically doesn’t have access to OSSEC alerts
Conor Schaefer @conorsch
23:09 @dachary no concerns with the ossec side of things as you describe them… that sounds like a pretty good way to do it! however, i do have concerns about metadata leakage—as @redshiftzero points out, there’s conditional logic at play, based on source interactions, that even though encrypted could potentially be analyzed over the wire by powerful adversaries. your PR identifies #1195 for closing, which is good, but there’s also conversation in the older #544 that may be relevant
Loic Dachary @dachary
23:09 @redshiftzero reason why there would be a different gpg key + email
Conor Schaefer @conorsch
23:09
then there’s the UX story for journalists (i see @redshiftzero is already pointing this out above).
my gut says asking journalists to use more encrypted email in their daily workflow is not a recipe for success.
we have orgs interested in a physical notification system: think a raspberry pi that turns green if submissions are found, red otherwise. it’s not a panacea, but i see that solving the problem you are trying to solve in an effective way. and as much as the physical notifier sounds like a ton of work, i’d say it’s comparable to the work involved with managing gpg email
redshiftzero @redshiftzero
23:12
my comment is just that most journalists onboarded to securedrop don’t see the OSSEC alerts
Loic Dachary @dachary
23:14
so, regarding the journalist having more email, that would be a tradeoff. Either they handle one more mail per day. Or they have to go to the journalist interface to see what’s happening. It stands to reason that journalists with SecureDrop that have low activity would welcome the mail instead of going to the journalist interface.
does that make sense ?
redshiftzero @redshiftzero
23:14
GPG is bad UX aside, another approach for this feature could be 0. Journalists opt-in to email alerts in user interface in the app code - this means they need their public keys uploaded and stored on the application server (e.g. see long-closed #1523) 1. Flask-Mail once a day sends the emails to journalists
the only real alternative to email that i can see for this would be to use signal-cli (which lots of admins also want for the OSSEC alerts)
Loic Dachary @dachary
23:16
but that would mean mails being sent from the app server, right ?
I assume that’s a big no security wise but … maybe not ?
Michael Sheinberg @msheiny
23:18
shit i dont think the grsec issue is related to cloud-init
Conor Schaefer @conorsch
23:18 @msheiny i’m working on the ossec stuff, have a few minutes to sync on the grsec CI progress before you log out?
tomorrow AM is fine too
redshiftzero @redshiftzero
23:19 @dachary - in terms of config i think we would just need creds for the SMTP relay also on the app server
Michael Sheinberg @msheiny
23:19
sure @conorsch – walking mah dag now – should be around for another hour
Conor Schaefer @conorsch
23:19
I really like the idea of signal-cli. our trainers already encourage both journalists and admins to use signal groups (with disappearing messages) for internal communication related to SD.
Loic Dachary @dachary
23:20 @redshiftzero I don’t follow ?
redshiftzero @redshiftzero
23:21
oh i was just saying that Flask-Mail just needs credentials for an SMTP relay to send emails afaik. was your security concern in terms of traffic analysis? (the reason you said it’s a “big no security wise”)?
Loic Dachary @dachary
23:22
I assume that adding any kind of mechanism that has the ability to exfiltrate data (like being able to send mail) is a security concern and therefore best to avoid
on the app server that is
but I’m new to reasoning about security so…
Conor Schaefer @conorsch
23:24
keeping Mon as the communicator makes sense, although it definitely does complicate the logic. I feel we’d get more bang for our buck if we went the signal-cli route, since then Admins could ALSO use signal for alerts rather than gpg email. @redshiftzero too early for signal-cli prototyping?
redshiftzero @redshiftzero
23:26
ahh okay i see. well i think any outbound TCP traffic is allowed on the application server, so if someone is in a position to exfiltrate data on the application server it’s unfortunately already game over
Loic Dachary @dachary
23:26
how does it complicate the logic ?
redshiftzero @redshiftzero
23:27
yeah i agree @conorsch using signal-cli is definitely more bang for the buck, if someone wants to go forth and prototype that it would be wonderful
Conor Schaefer @conorsch
23:27 @dachary “complicates the logic”: your description of the ossec-cat-then-send-email workflow is more complicated than @redshiftzero’s comment about flask-based sending. but, again, i think it’s the safer approach
redshiftzero @redshiftzero
23:28
why is it safer?
(note: i’m cool with either approach as long as we can maintain it)
Loic Dachary @dachary
23:30
I suppose it is safer because it uses existing code paths instead of creating new ones ? maybe ?
Conor Schaefer @conorsch
23:30 @redshiftzero because we already have notification logic e.g. email well vetted configuration-wise on the Mon Server. introducing outbound communications from the App Server goes against the grain of our hardening approach to date. willing to entertain a discussion, but using the App Server to send alerts seems more a sign of “the Mon Server config is painful to work with” than “this is the right approach for journalists and sources”
yeah, pretty much that, @dachary
and, to be clear, I do think the Mon Server config is a pain to work with! reaction to that should be improve the Mon story, not sidestep the pain and overload the App server
“how many unread submissions are there” is very much a monitoring function, in my head
redshiftzero @redshiftzero
23:46
i mean, using the web application to send user-friendly emails to users of that web application is a common approach (using a host-based IDS to send alerts to non-technical users seems like an anti-pattern). that said, it does necessitate opening a port on the app server to send emails, managing the mail configuration on the app server, and additional code paths (well i guess either way you will also need additional code paths to get OSSEC to send emails to journalist users (at minimum because their emails and public keys are not stored anywhere in the securedrop database) - tl;dr i’m not sure if the difference in the length of the diff) buuuut if this can be done simply with OSSEC - i.e. it works and its maintainable then i’m not going to be a “stick in the mud” about this
aside: if i had a nickel for every time travis bombed out on me, i wouldn’t need to work at FPF @dachary contemplates his travis-fail-nickel pile and realizes he has a fortune
Conor Schaefer @conorsch
23:50
“Better than Bitcoin! TravisCoin! Take your testing failures and turn them into financial success!”
redshiftzero @redshiftzero
23:50
lol, if only
we could all be rich
Loic Dachary @dachary
23:51 @redshiftzero I’m happy to refactor using Flask-Mail if you think that’s the best route. In both cases I suppose we’ll have to defer to @emkll best judgement, right ?
redshiftzero @redshiftzero
23:54
yep let’s see what @emkll thinks of this for sure- though if you have things working in OSSEC it’s probably not worth backtracking (also we should check what the state of maintenance of Flask-Mail / similar is)
Loic Dachary @dachary
23:54
If he does not have strong feelings either way, I’m inclined to go the Flask-Mail way. I went the OSSEC way because I was focused on using the existing communication means as much as possible. But that was based on intuition rather than sound reasoning. @redshiftzero I don’t have things working in OSSEC. I have a draft, untested implementation that I think will work. And I’m glad this conversation happens now
Conor Schaefer @conorsch
23:55
great, let’s ping him during standup (or before, since you log in earlier than i do ). i will say that over time gpg-email integrations in SD should go away in favor of comms tools that our trainers actually recommend, e.g. Signal, so I’m worried that @dachary’s work will be shortlived. but i believe i’ve made myself clear on that
redshiftzero @redshiftzero
23:56
yeah i totally agree with that. signal is so much better for users
someone should make a flask extension that integrates signal-cli for notifications
Loic Dachary @dachary
23:56
I’m ok with short lived work as long as it’s useful to actual people
Conor Schaefer @conorsch
23:57
hmm i like the flask idea @redshiftzero… there’s a general purpose notification utility called ntfy, written in python, and the maintainer is receptive to merging a signal backend
redshiftzero @redshiftzero
23:57
oh very interesting
Conor Schaefer @conorsch
23:57
(thinking out loud about how to write as little code as possible)
redshiftzero @redshiftzero
23:59
haha. i hear you. i 'd this issue, now we’ll let open source do the rest (that’s how it works, right?): dschep/ntfy#141
implementing it there is better than my flask extension idea because we can call nfty from the app code and use it for OSSEC
@mickael the above chat is worth reading, but here is the short version: would it be acceptable for the application server to be able to send encrypted mails ? The alternative implementation is to create a file on the app server, wait for the mon server to notice it and then have the mon server send a mail.
Thanks for the ping @dachary. As discussed above: For an adversary observing metadata of mails sent from SecureDrop area (size, frequency, time) a SecureDrop instance that receives millions of documents per day should receive emails with the same quantity, size and frequency as the other.
Adjusting the size of the message can be done through padding, and the easiest way to ensure similar frequency and timing to always send at regular intervals.
I agree with @conorsch and @redshiftzero bout the mon server being the logical place to implement this functionality, and we don’t want to duplicate the maintenance burden for communications either. Furthermore, flask-mail does not seem to be actively maintained at this time. Finally, if we move to signal-cli, it would be nice to not have java installed on the app server.
I think for these reasons, (and because of the relative ease to implement), the OSSEC method seems like a sensible option at this time. The main drawback is that the monitor server does not have any management interface (except ansible) which will make updating journalist emails/gpg keys a challenge.
Ok, I’ll keep going in this direction since @redshiftzero wrote she does not object to it (please speak up now if you changed your mind ;-).
The easiest way probably is for the admin to setup an alias (securedrop-notification-for-journalist@media.press for instance), subscribe journalists who are willing to be notified (via whatever interface they use to manage mail aliases internally) and distribute the private key PGP key to all of them. Or to just have one point person responsible for watching the notifications which is probably the most common use case for this feature. Because it’s appealing to new SecureDrop installations with low traffic.
For the record, had an interesting conversation yesterday about Semantic Security and what it would mean in this specific case. I have no conclusion to present, of course, because the topic is new to me
Based on my understanding of the OpenGPG standard implemented by GnuPG , GPG used RSA to encrypt a randomly generated symmetric session key (with a random iv) that encrypts the data. This should protect against semantic disclosure in this context.
A good reference for this (in the future) would be the Advanced into to GPG which some Freedom of the Press Staff have seen in person. (Slide 18 in particular). Please correct me if I’m wrong…
). i will say that over time gpg-email integrations in SD should go away in favor of comms tools that our trainers actually recommend, e.g. Signal, so I’m worried that 
'd this issue, now we’ll let open source do the rest (that’s how it works, right?): dschep/ntfy#141