[kwlug-disc] Secure email alternative

[Allan Zhang]

在 2016年06月21日 星期二 上午04时15分 -0400, Nick Guenther 写道：
>
>On Jun 21, 2016 03:09, Paul Nijjar via kwlug-disc <kwlug-disc at kwlug.org> wrote:
>>
>> I am looking for the following communications platform:
>>
>> - Allows asynchronous communications, like email.
>> - Is based on a client-server model, with clients for multiple
>>   platforms (Windows, Linux, Mac OS X) and a server that is FLOSS and
>>   installable on Linux.
>> - Requires registration to use (preferably by submitting a public SSH
>>   key).
>> - Does NOT have a web client or web interface.
>> - If the server requires opening a port on the Internet, the
>>   communications to that port should be authenticated and preferably
>>   encrypted.
>>
>> I do NOT want email with GPG or S/MIME or whatever. The service does
>> NOT need to be federated. I am indifferent whether whether the data is
>> encrypted on the server so that sysadmins cannot snoop on it.

>> Yes, I understand that this is an odd set of requirements. Does such a
>> thing exist already? I am not sure what search terms to use.

Seems like your own mail server is what you want. Host one with no web interface. You could force it to use passwordless SSH to register and login. Use TLSv1.2 and SASL to encrypt in transport.
You did not state requirements for data encryption, so all the boxes are checked.

>There's no way you're going to find something with good clients for all platforms and also without a web interface. WhatsApp, Signal, and Slack fit a lot of your requirements and have great UI, except the first has web.WhatsApp.com and the second has a chrome extension to do the same, and Slack is a web app first and mobile apps second.

Signal is GPL but both Slack and WhatsApp are proprietary.

>That said, of you can tolerate crappier clients, an XMPP server is a good option. Install prosody, disable federation (see https://prosody.im/doc/s2s) and get your desktop users to install Pidgin/Adium/Gajim, your iOS users Monal.im, and Android users Conversations.im.

>Registration is by prosodyctl on the command line unless you configure something else, since by default `allow_registration=false;` That's not quite sending an ssh key but it's pretty close. If you have ssh keys, I assume you have unix accounts too? In that case you could look into plugging prosody into PAM (https://prosody.im/doc/authentication).
>
>`c2s_require_encryption = true;` by default. This authenticates the server to the client via TLS, and also gives confidentiality and integrity of course. The client authenticates with a password to the server or via SASL (note: I've never used SASL myself). With federation turned off, all messages are secured with these, since you only have traffic flowing from your users, to your server, and back again. While the server is processing or store-and-forwarding the messages are cleartext. Is that secure enough?
>
>The default async behaviour of mod_offline ("if I have no record of active presences, store and forward at next sign in") is enough for daily use, and is a primacy reason I advocate XMPP over IRC. But you can install https://modules.prosody.im/mod_mam.html and/or https://modules.prosody.im/mod_smacks.html to give better asynchronous guarantees (without this, clients dropping offline improperly may lose messages sent in the window before the server realizes). Caveat: MAM doesn't work with Pidgin/Adium yet. Bonus: MAM lets clients in principle forget all history and only query it online as needed, much like an email client.
>
>Depending on your use case, MUCs can be really useful too. MUCs a) store room history reliably---multiple clients for a single user can all see the same history (but each room's history length needs to be configured by the initial owner) ( MAM cleans all that mess up, and makes using MUCs just for history less reasonable ) b) allows group chat. To configure MUCs, you need a spare subdomain (beware: a lot of client software incorrectly assumes the subdomain is *always* conference.example.com) and a one line change to your config, which you can see how to do at https://prosody.im/doc/components#adding_an_internal_component
>
>Bonus: Gajim and Conversations (sadly not Pidgin/Adium nor Monal) speak the experimental OMEMO protocol which gives multi-device asynchronous end-to-end encryption so the admins *can't* snoop, if you train your users to turn it on. More clients support OTR, but that's decidedly *not* asynchronous.

Yes, from what I have read, the recent E2E protocols like OMEMO, Axolotl/SignalProtocol are a strong choice if you want repudiation.
Again, I do not know if Nick wants data encryption at all. Plain XMPP with transport security would satisfy his checklist.

>Double bonus: investigate mod_http_upload to get Messenger/Signal/WhatsApp-style picture, voice and video messaging going. (normally file transfer in XMPP requires synchronous comms; mod_http_upload removes that requirement).
I'm assuming these are pre-recorded voice/video clips or picture messages. I don't know if even those messengers can send clips, but sending voice clips is a very popular feature in the Chinese WeChat.
>
>Triple bonus: if you change your mind, https://getkaiwa.org or https://candy-chat.github.io/candy are good web clients (and you can use the same SSL cert on them so it's not really any less secure).

>XMPP is much maligned, but it's the strongest thing we've got right now for building sensible telecom infrastructure. It's starting to get a series of much improved clients.
Signal is not based on XMPP because it did not want to include legacy code. Do you think XMPP has a stronger future than Signal?

>------
>
>You *could* also just put up an IRC server and run znc instances for everyone with only TLS. This gets the same security guarantees as above, and znc provides something between mod_offline and mod_smacks, and you've got lots and lots of clients to choose from.
>
>---
>
>Good luck. Tell us how it goes.
>_______________________________________________
>kwlug-disc mailing list
>kwlug-disc at kwlug.org
>http://kwlug.org/mailman/listinfo/kwlug-disc_kwlug.org