TL;DR
Hablamos de poner cifrado GPG a gente que no tiene ni idea. Mientras que
los servicios servidor a servidor, cliente a servidor, que los expertos,
competentes y profesionales podrían implementar NO LO HACEN. En parte,
porque el problema no es muy visible.
Porque la seguridad by default en diseño es muy difícil punto a punto
(ya sea desarrollar aplicaciones que cumplan con este diseño, como la
experimentación necesaria por el usuario para manejarse con ello).
En cambio, la seguridad por política [0]; de un sysadmin que lo
configure correctamente; es totalmente invisible para el usuario. Tanto,
que no sabes si lo está haciendo bien o mal. Probablemente demasiado
invisible ahora.
Ejemplo: los correos del ayuntamiento de Barcelona que recibo en Gmail
me dice que no llevan cifrado (de servidor a servidor de correo). Grave,
no? (Y fácil de arreglar!!!!!!!!!!!)
----------------------
Estos días he tenido la oportunidad que muy poca gente tiene, incluso
entre los informáticos, ya que hay:
- mucha desincentivación y desmotivación en Internet sobre el tema [1]
- y porque una configuración sirve para miles, millones de personas:
gmail, riseup
En fin, si lo he hecho, es porque lo tenía que hacer, y cagándome en to.
Añadiría que hay un interés, una gente que se gana la vida con eso; que
son reacios a facilitar las cosas. Ya que por ejemplo, postfix (servidor
de correo), a Febrero de 2016 por fin tiene, en teoría un método para
hacer el TLS "fácil" (no lo he probado) entre servidor y cliente [2].
Que en el fondo no es tan difícil de montar, lo que viene siendo un
servicio cualquiera que requiere mucha configuración específica/de detalle.
Sí, se podría hacer una configuración por defecto que más o menos todo
funciona. De ahí, proyectos como freedombox [3]
Bien, pues es "divertido" ver que por ejemplo,a día 11 de Agosto de
2016, a pesar de este elitismo con los pocos servidores de correos que
hay, todavía hay cifrado oportunista. Es decir, que el envío de emails
en texto plano es aceptado (!!).
Lo cual quiere decir que llegamos a la reflexión del horror: "No tiene
sentido prohibir un cifrado roto en los servidores de correo, total, es
mucho mejor que texto plano". Una perspectiva gráfica [4]
Y lo que es peor, quiere decir, que una negligencia de un sysadmin en un
dominio de correo podría obligar al resto de servidores de correo a usar
texto plano en el envío/recepción de mensajes. Y TODO ESTO SIN QUE EL
USUARIO LO SEPA [5]. La solución no es desincentivar los servidores de
correos; si no implementar un sistema mejor.
Claro, os imagináis el problema? Supongamos que todos los servidores de
correo no aceptan texto plano. Trato de enviar un mensaje de correo mal
configurado (sin cifrados) a un servidor; y me lo rebota porque la
negociación de cifrado no ha sido aceptada; (ya que no hay un cifrado
común para comunicarse). Entonces, cómo le comunico a la
persona/sysadmin que no funciona si no puedo escribirle? Aquí el atasco
con el tema. El email es un servicio demasiado importante para ponerse
firme. Por otro lado; es EL SERVICIO MÁS IMPORTANTE DE INTERNET.
Si hubiera en cambio, un estándar, un servicio "a prueba de fallos" de
un correo sin cifrar para este tipo de mensajes, problema resuelto,
verdad? Por ejemplo, la posibilidad de hacer excepciones con buzones que
sí acepten texto plano para avisar al administrador:
report-plaintext@???
alarmas@???
old-1984-service@???
En paralelo y otro asunto, "La gente" sufría con el HTTP vs HTTPS hasta
que apareció letsencrypt [6]. Éxito que muy probablemente podemos
atruibir a la GRAN labor de la EFF con el tema.
[0] Aprovecho para poner esta diapositiva que me gustó mucho del último
taller en Cinètika
https://dhole.gitlab.io/criptica_presentacions/2016-08-08_Taller_Cinetika/#3
[1]
https://www.digitalocean.com/community/tutorials/why-you-may-not-want-to-run-your-own-mail-server
[2]
Véase quick-start TLS with postfix, requiere versión 3.1 que solo está
disponible en versión reciente; no está obviamente en debian estable.
http://www.postfix.org/TLS_README.html#quick-start
http://www.postfix.org/announcements.html
[3]
https://wiki.debian.org/FreedomBox
[4]
https://ssl-tools.net/mailservers/gmail.com
esta es la configuración a la que podemos aspirar todos: certificado
letsencrypt + configuración bastante por defecto de postfix
ejemplo de que hay protocolos que no se aceptan; a pesar de que como he
comentado, podríamos mandarlo en texto plano sin ningún problema
https://ssl-tools.net/mailservers/riseup.net
es decir, que lo rojo no debería sorprendernos, lo rojo rojo, lo grave,
es el texto plano
https://ssl-tools.net/mailservers/inventati.org
inventati podría haber usado un certificado letsencrypt gratis,
opensource y autorenovable
https://ssl-tools.net/mailservers/eff.org
ejemplo de que certificado letsencrypt está aceptado
[5] creo que el único que ha puesto un servicio de conciencia sobre esto
es google. Nada como concienciar al usuario final; sus razones tendrán,
santos no son; quizá para decir que se pongan un gmail y adiós problemas.
[6]
https://letsencrypt.org/stats/
