Securedrop: OpenPGP key not updated, empty ossec mails

[KwadroNaut]

I had updated the expiry date of an OpenPGP key, pushed to keyservers, but forgot to update it on the OSSEC-side of things. Now the notifications that are sent, are empty, except for the subject. Possible improvements:

• encrypt to expired, not revoked keys
• fetch key updates over Tor, slow refresh
• send a plain text e-mail gently reminding the admin to take care of their keys

[kushaldas]

• encrypt to expired, not revoked keys

GPG does not allow this iirc. We are not supposed to be able to use any expired or revoked keys.

• fetch key updates over Tor, slow refresh

Fetching any key for SecureDrop over network (other than direct copied key during install time) can open up security loophole. @emkll and @redshiftzero can give more input on this.

• send a plain text e-mail gently reminding the admin to take care of their keys

Like the above comment, in my mind this can again increase the attack surface.

[emkll]

Good catch @KwadroNaut , it appears there is no error handling around the encryption, and since the key is expired, GPG will not encrypt the message and encrypted_alert_text will be empty. Checking for an empty string and sending a failure message seems like the best approach to me, in this case.

As @kushaldas mentioned, we rely on Ansible over ssh to transfer these keys, and using keyservers to refresh keys will introduce new failure scenarios, both for security and reliability (A recent example comes to mind: https://bitbucket.org/skskeyserver/sks-keyserver/issues/57/anyone-can-make-any-pgp-key-unimportable).

[KwadroNaut]

That's a nasty example there, @emkll and I'm afraid that's not the only argument against these updates. @kushaldas how to know when a key is revoked without updates?

Sort of chicken/egg problem, but I see the poinst you're both raising. So maybe the current behavior is pretty close to what's reasonable: don't send content if we're unsure if the admin can receive it encrypted. I'd like to get the subject encrypted too with memoryhole someday (unrelated to this issue)[1], which might render the notifications in a comple garbage message for the admin, which gets close to my third idea of gently reminding the admin to take care of keys…

This looks related btw: https://github.com/freedomofpress/securedrop/blob/develop/install_files/ansible-base/roles/backup/files/0.3_collect.py#L63

Unsure about the best way forward.

[1] https://github.com/autocrypt/memoryhole

[emkll]

For anyone experiencing this problem, one can manually update the GPG keys on the mon server. First, the admin-stick local copy of the public key (e.g. in install_files/ansible-base) must be updated, and the install playbook must be run again again.

In the following example, the key is uploaded to key servers, and relevant configuration for gpg alerts in install_files/ansible-base/group-vars/site-specific is as follows:

ossec_alert_gpg_public_key: admin.key
ossec_gpg_fpr: AAAAAAAAAAAAA

The following steps should update an expired gpg key:
First, check out the latest release as instructed in the release notes. Then run the following commands to update the locally-stored version of the public key and update the key on the servers:

cd ~/Persistent/securedrop
gpg --refresh-keys AAAAAAAAAAA
gpg --armor --export AAAAAAAAAAA > install_files/ansible-base/admin.key
./securedrop-admin setup
./securedrop-admin install

[KwadroNaut]

When in a hurry, you can also scp the key, ssh into the mon-server, su into the ossec user, and update the key with a plain old gpg --import.

[b-meson]

I also notice the current documentation for OSSEC does not advice admins for SecureDrop to set up a key that never expires like we do for the Submission GPG Key.