Corrijo una parte que acabo de ver. Autistici ya usa Let's Encrypt desde hace un tiempo.
http://www.autistici.org/en/ssl.html
On Thu, Aug 11, 2016 at 06:37:45PM +0200, drymer wrote:
>Hola
>
>Contesto algunas cosillas en el mail.
>
>On Thu, Aug 11, 2016 at 02:12:33PM +0200, guifipedro wrote:
>>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.
>>
>
>Precisamente por eso es tan importante usar GPG, por que no hace falta confiar en que el servidor esté haciendo lo correcto. Siempre es mejor que lo haga, obviamente. Pero para que confiar si no es necesario.
>
>>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).
>>
>
>No creo que es que sea dificil, es que no tiene sentido. OTR, por poner un ejemplo, debe ser gestionado a mano. No hay manera de automatizar los dispositivos con los que se habla, y no deberia haberla. Su posible sustituto, OMEMO, lo facilita mucho en comparación, pero se sigue teniendo que validar el dispositivo.
>
>>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!!!!!!!!!!!)
>>
>
>Esto es que no quieren, sin más. Cómo dices, bien facil de hacer.
>
>>----------------------
>>
>>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]
>>
>
>El tema de los servidores de correo creo que es un tema a parte. No es tanto cuestión de hacerlo facil sino de que se adapta a muchas necesidades distintas, algo muy importante. Btw, poner TLS dificil no es de hace unos pocos años, como dices, pero es cómo todo, hay que saber hacerlo.
>
>También opino que uno de los motivos principales de no poner por defecto un cifrado estricto es el tema de la compatibilidad, ya que desde que se activa puede haber un espacio de tiempo en el que los clientes no serian capaces de gestionarlo. Esto pasó con SCRAM en prosody y los clientes XMPP, por ejemplo.
>
>>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 dicho, yo creo que es por mantener la compatibilidad (que no lo justifico, pero eso).
>
>>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@???
>>
>
>Lo que planteas es una solución, pero bueno, poca es la gente que solo tiene una cuenta de correo, creo yo. Siempre se puede tirar por otra.
>
>>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
>>
>
>Un apunte. En autistici no usan un certificado ni de let's encrypt ni de otra CA por que consideran, con razón, que el sistema de las CA no tiene seguridad ninguna. Y de hecho, hasta antes de let's encrypt o CACERT (que estaban antes), estaba limitado a la gente que se lo podia permitir.
>
>Yo estuve bastante tiempo sin usar let's encrypt por lo mismo, creo que una CA autofirmada es mucho más segura. Pero al final caí por que no lo veo practico si no ofreces servicios cómo hace autistici, si sólo tienes web y alguna cosa más, mejor tirar a lo sencillo por que lo otro no se hará.
>
>
>>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/
>
>Saludos
>
>>_______________________________________________
>>list_criptica mailing list
>>list_criptica@???
>>Lista de correo de debate de Criptica
>_______________________________________________
>list_criptica mailing list
>list_criptica@???
>Lista de correo de debate de Criptica
