Helpdesk needs a PGP key to be able to receive encrypted help queries
Couple days ago sherief mentioned we need a PGP key to be able to receive and handle encrypted help queries via RT.
I think it's a great idea as protecting our users' sensitive information is and always should be our first priority at support team.
This ticket is to help us remember we need to make this happen (hopefully in near future)
Once we have the pgp, we should start advertising and encouraging our users to use encryption if possible.
Activity
See #12816 (closed) for a discussion on how to do that using RT and why I think it's a bad idea.
Other options I have experience with are:
- An OpenPGP key where the privacy key is shared by multiple people. Painful, as once someone leaves the team, you need to revoke the entire key, issue a new one, and redispatch the private key.
- Using Schleuder, a gpg encrypted mailing list system with remailer capabilities. Each message is decrypted on a central server (which holds the common private key) and then re-encrypted for every recipient. By sending an encrypted and signed message to the list, it's possible to add new keys to the list keyring and also send replies to outside email addresses. This is how Tails does support. Schleuder is ok to use once you've mastered it. But that's a process which made some people really unhappy. Also the software is in bad shape right now (probably it won't be in Debian Jessie).
In any cases, this mean that these OpenPGP-encrypted exchanges would likely be out of RT.
All of this seems like a lot of pain for little gain. We have a process that works pretty much alright right now. I don't see an easy way to introduce OpenPGP in there that will not make us loose email, fail to follow-up on users, and the like.
Replying to lunar:
See #12816 (closed) for a discussion on how to do that using RT and why I think it's a bad idea.
when a user contacts RT it usually means they were unable to use Tor, meaning they're sending a plaintext email over the clearnet on the same network (which they're trying not to use,) about their issue. Even if we keep the data unencrypted in our database, PGP could still add a good layer of protection from their adversary, while their message is traveling on the wire.
Other options I have experience with are:
- An OpenPGP key where the privacy key is shared by multiple people. Painful, as once someone leaves the team, you need to revoke the entire key, issue a new one, and redispatch the private key.
- Using Schleuder, a gpg encrypted mailing list system with remailer capabilities. Each message is decrypted on a central server (which holds the common private key) and then re-encrypted for every recipient. By sending an encrypted and signed message to the list, it's possible to add new keys to the list keyring and also send replies to outside email addresses. This is how Tails does support. Schleuder is ok to use once you've mastered it. But that's a process which made some people really unhappy. Also the software is in bad shape right now (probably it won't be in Debian Jessie).
In any cases, this mean that these OpenPGP-encrypted exchanges would likely be out of RT.
All of this seems like a lot of pain for little gain. We have a process that works pretty much alright right now. I don't see an easy way to introduce OpenPGP in there that will not make us loose email, fail to follow-up on users, and the like.
What if we start using PGP in RT (for the reason stated above) in short term and slowly get to Schleuder or some other alternative when we're ready?
-
Replying to mrphs:
when a user contacts RT it usually means they were unable to use Tor, meaning they're sending a plaintext email over the clearnet on the same network (which they're trying not to use,) about their issue. Even if we keep the data unencrypted in our database, PGP could still add a good layer of protection from their adversary, while their message is traveling on the wire.
I believe that's not actually true.
Most users will connect to their mail provider using encrypted channels (IMAPS, POP3S, SMTPS, or HTTPS webmail). Tor mail server offers opportunistic STARTTLS, so delivery from user's mail provider to RT is likely to be also encrypted.
I'm sure this is true for GMail and riseup.net. Here's some quick research:
The RT database currently holds 2987 different domains. Top twenty used over 22378 email addresses:
rt=> select lower(split_part(emailaddress, '@', 2)) as domain, count(*) from users group by domain order by count desc limit 20; domain | count ----------------+------- gmail.com | 10178 yahoo.com | 2866 hotmail.com | 1351 qq.com | 327 aol.com | 219 live.com | 174 mail.ru | 157 outlook.com | 156 hushmail.com | 155 ymail.com | 141 googlemail.com | 138 tormail.org | 116 yahoo.co.uk | 116 comcast.net | 115 me.com | 106 163.com | 97 riseup.net | 95 yandex.ru | 91 safe-mail.net | 89 hotmail.co.uk | 82Yes, I know users can use other SMTP server to send their emails, but I believe these days most will use the one given by their provider.
So, most of them are webmail. And according to Google's reports a good amount of them have STARTTLS enabled on their SMTP servers.
What if we start using PGP in RT (for the reason stated above) in short term and slowly get to Schleuder or some other alternative when we're ready?
Switching our support handling from RT to straight email would really feel like going backward to me. We have currently 11 people that work on tickets on a more or less regular basis, spread over 6 different language (and growing). Using only email, and encrypted it's going to be tougher, would really really make the job harder for everyone involved.
Yes, I know that some people are really efficient with emails. But it's not possible to coordinate a team that large without a common database.
moved to tpo/community/support#12842 (closed)
