Encrypted PGP Messaging

I basically outlined what I was getting at in my previous post attempting to articulate threat models and messaging models. My last post may have distracted from that.

###TLDR:

  1. The social and technical landscape has changed since this thread stopped in 2014.
  2. I really like the implementations of PGP notifications by Facebook and the aforementioned WP plugin. Discourse adding that capability would be helpful.
  3. I’d also love to be able to use Discourse messaging secured by something like Signal Protocol so I could avoid Facebook Messenger altogether for private conversations with forum users (currently, we end up shifting back and forth).
  4. My aesthetic preference for encrypting everything likely does not represent most users.

Email notifications with no content leakage would certainly be less useful, but it would alleviate some of the concerns. Thank you for pointing that out.

I don’t think I have anything further to add.

1 me gusta

The way I see it this completely solves “Thread Model 3”

Big Data: User email providers (Gmail, Yahoo!, Microsoft, etc.). Transactional email providers (Mandrill, etc.). Attacks on email in transmission or at rest.

I would only be comfortable solving

Directly in the Discourse mobile app (or whatever packaged desktop app).

1 me gusta

Hi there,

I work for a consortium of journalists (ICIJ) that investigates on highly sensitive projects. Most known being the Panama Papers and the Paradise Papers.

I’m about to use Discourse to help our network to coordinate and I wonder if anyone ever come out with solution for encrypted private messaging? Our main concern being: if ever the database get leaked, how can we prevent the attackers to read private messages which could reveal sensitive info about our sources.

With our current forum portal, we already setup a “proxy” service in front of our SMTP that uses GPG to automatically encrypt messages for the known keys. If the key for an email has not been provisioned, the email is not sent.

Thanks a ton!

4 Me gusta

My suggestion would be to have the actual source info referenced as a general codename – all direct source communication should be through a highly secure medium like Signal.

Derived from

1 me gusta

Yeah. Where that document says:

Assume that anything you say on Slack or in Twitter direct messages will one day be public.

Apply that to Discourse as well.

Discourse is trying to be a facilitator for public discussion and doesn’t put a lot of focus on protecting users from the admins.
As a case in point, the re-naming of “private messages” to “personal messages” – the forum admins need to be able to audit PMs for harassment etc without the abusive participant noticing.

Make sure that your journalists know how to go from a codename & document number to the actual document, and that this actually WORKS, so you don’t have people uploading documents to the forum in order to get their work done.

2 Me gusta

Yes, we already advise them to use Signal, and of course we have many security instructions like the one @riking mentioned. But each investigation involve hundreds of journalists, not all of them are tech savvy and since there is no ways to ensure they follow our recommendations, we must encrypt as many things as possible to lower risks.

The main things to check with regards to “database being leaked”:

  • anyone who has admin access to your Discourse can download the DB so limit the number of admins, and perhaps only log in as admin when absolutely required, use a “regular” moderator account typically

  • anyone who can log into your hosting server can directly grab the database, so strictly limit and control who has login credentials to your hosting server.

5 Me gusta

Gotcha, I’ll limit the number of admin, thanks!

So I suppose no one ever implemented OTR in PM then?

Es un ámbito de problemas muy complejo. También recomendaría encarecidamente (¿o exigiría?) la autenticación de dos factores para el inicio de sesión en el servidor de alojamiento.

(También soportamos la autenticación de dos factores en Discourse, pero los administradores pueden anularla como herramienta de soporte técnico.)

2 Me gusta

We have 3-factors of authentication in fact, using our own SSO.

1 me gusta

I’d like to add one point:

  • Keep Discourse and the host up to date. As is the case for any complicated software, sometimes, security vulnerabilities surface that could lead to the database being compromised. Assuming you won’t be the target of sophisticated attacks that specifically target you, quickly installing patches can eliminate most of that risk.
3 Me gusta

The underlying issue is that you can not trust the server if you want truly secure messaging between members.

This means that the software used to encrypt and decrypt stuff should not be sent from the discourse server.

I second what was said here, you want something like keybase or signal for secure comms, you have to invest in training here. Treat the info you have on Discourse as potentially leaked, there are just too many vectors. People hosting the service, web browser caches on local computers running old exploitable operating systems and so on.

If I was pushed hard to come up with something for journalists discussing highly sensitive info that is Discourse I would

  1. Host the physical server in my house or somewhere I can see it all the time

  2. Use SSL clearly

  3. Only have myself as admin

  4. Enforce limited user agent support, demand everyone use a very specific browser and only allow that user agent on the site, this browser would not store any cached files on local disk

But… even with all of that … signal/keybase is much better on so many levels

10 Me gusta

Sería genial si hubiera una superposición AutoCrypt para Discourse (o una plataforma de publicación asíncrona similar)

Gestiona la «complejidad» de PGP de forma transparente para el usuario, de manera segura. Su modo de «máximo esfuerzo» aún no hace lo suficientemente claro para el usuario que permite volver a texto plano si no hay una configuración explícita de la sala.

Sí, soy consciente de la diferencia entre el intercambio de claves y la clave pública fuera de la cadena. Esto sería sin confianza ciega.

No. La 2FA no tiene nada que ver con la gestión de identidades (como Shibboleth). ¿Estás haciendo una referencia velada a algo que tengo y algo que sé? ¿En el sentido de que proporcionar la prueba de algo que tengo es, por extensión, una identidad?

También necesitarás confirmaciones DANE.

¿Estás insinuando cuentas «gratuitas»?

Movim también lo hizo, por eso abandonó OMEMO para su plataforma social XMPP.

Un proyecto de GitHub que merece la pena reflexionar es OverSec. Aunque está diseñado para Android, alguien podría recoger el guante y adaptarlo a Android.

Le daré más vueltas a los modelos de amenazas.

¿AutoCrypt es la solución?

La tolerancia hacia los males que se cometen contra la privacidad ha creado el terreno para las amenazas actuales. No sé cómo resolver la indiferencia.

Usando este razonamiento, los invitaría a dejar de usar Internet, que es mucho más anticuado.

El correo electrónico, al igual que XMPP y Matrix, es federado.

Amén. Gracias.

Desactivé el modo de resumen por esta razón.

Necesitan ser reeducados al respecto, como con el bloqueo de anuncios.

¿Esto todavía requiere problemáticamente un número de teléfono móvil?

Respuesta necrófila porque era la mejor coincidencia para una búsqueda.

1 me gusta

También sería genial que la gente usara más la función de búsqueda antes de publicar en un foro público (y/o leyera más antes de escribir).

No me queda claro: ¿estás abogando por más o por menos bloqueo de anuncios?

1 me gusta

Sí, las principales recomendaciones aquí son:

  • Instalar y utilizar el plugin Discourse Encrypt (muy maduro, lo usamos internamente).
  • Activar “medios seguros” (advertencia: esto es extremadamente difícil de configurar).
  • Activar “correo electrónico privado” para que ningún contenido se filtre por correo.
2 Me gusta