Los responsables de la aplicación de mensajería Signal, aseguran que Amazon les ha amenazado con sacarlos de CloudFront si siguen utilizando la técnica llamada "domain fronting". Dicha técnica permite a los desarrolladores de aplicaciones y páginas web engañar a las herramientas de censura. Sirve para que el tráfico parezca que procede de una fuente diferente, permitiendo evitar las prohibiciones de ciertos países.
#2:
¿Y eso será un problema técnico para Amazon o simplemente buscan tener contentos a los gobiernos de según qué países para no tener problemas con ellos en un futuro?
#7:
#2 Si lo siguieran permitiendo, el pais de turno podría decidir bloquear toda la red en la que se encuentra el dominio que se pretende capar, en este caso el de Signal, con lo que en la práctica supondría que la mitad de AWS, Google Cloud, o lo que fuera no funcionaría en ese país al completo, una gracia para el resto de clientes. Tratan de evitar efectos colaterales al resto de clientes (o eso parece).
#15:
Eso pasa por usar servidores que no están bajo tu control.
Lo que van a tener que hacer es montar sus propias granjas de equipos.
#1:
No sabía que la pasta de dientes usaba esas cosas... Me voy a pasar a Colgate.
¿Y eso será un problema técnico para Amazon o simplemente buscan tener contentos a los gobiernos de según qué países para no tener problemas con ellos en un futuro?
#2, lo mismo el país puede responsabilizar en parte al proveedor del hosting o similar. Veo sentido a que Amazon quiera que no se hagan cosas "ilegales" a través de ellos sin tener que implicar motivos oscuros detrás.
#2 Si lo siguieran permitiendo, el pais de turno podría decidir bloquear toda la red en la que se encuentra el dominio que se pretende capar, en este caso el de Signal, con lo que en la práctica supondría que la mitad de AWS, Google Cloud, o lo que fuera no funcionaría en ese país al completo, una gracia para el resto de clientes. Tratan de evitar efectos colaterales al resto de clientes (o eso parece).
DNS over TLS es una nueva especificación del protocolo DNS que aún no está extendida, pero que cuando lo ese, la resolución del dominio DNS será cifrada punto a punto.
#13 en eso estamos de acuerdo.
1. DNS over TLS te da la ip a llamar
2. Iniciar a TLS handshake a la ip
3. Censor puede ver el dominio en la primera request de TLS porque va sin cifrar
2 debe incluir el dominio para especificar que certificado y CA es esperada.
#16 la ip siempre va sin cifrar, el protocolo tpc-ip es de más bajo nivel que HTTPS
Incluso usando domain fronting, el censor sabe a qué ip haces las peticiones.
No creo que sea posible un protocolo IP, en el que la IP va cifrada punto a punto, no sería posible enrutar la petición.
A no ser que el paquete se propagase inicialmente en todas direcciones, y solo el que sabe que es para él, respondiese en sentido inverso marcando la ruta... no sé... no soy teleca, pero me parece ciencia ficción un IP cifrado punto a punto.
#18 si lees él post de Signal, la censura se hace al inicio de TLS.
El primer paquete de TCP es un CONNECT , y este va en claro. Como parte de esta retirar va hacer un upgrade a TLS, por lo que el segundo paquete intercambiado ya va cifrado.
Es en ese primer paquete dónde Irán estaba cortando la comunicación, leyendo el dominio de Signal. Para evitarlo, habían puesto un dominio tercero con alojamiento en un CDN que le el header con el forwarding. Es hacer una especie de túnel haciendo TCP/TLS
#18 En tor los paquetes van encapsulados, como muñecas matrosca, cuando un nodo recibe un paquete quita una capa y solo sabe quien se lo ha mandado y a quien debe pasárselo, desconoce el inicio y el final del circuito (salvo que seas nodo de entrada o salida, claro) y el contenido, el siguiente nodo hace lo mismo .
#34 No, simplemete elige el destino final del paquete, la red elige por que nodos va a pasar, los miembros de esa red no saben el origen o fin del circuito, el nodo de salida del circuito tampoco sabe del origen por lo que se mantiene su privacidad, solo los nodos de salida están expuestos.
#10 Cuando inicias una conexión HTTPS con un servidor se envía en plano el nombre de la máquina a la que vas a conectarte, lo que incluye el dominio. Ese nombre va en plano en la negociación, como parte del SNI https://en.wikipedia.org/wiki/Server_Name_Indication y un firewall que analice el tráfico puede decidir bloquear si ve que te conectas a un dominio "prohibido".
eso viene porque rusia si bloqueo una parte de google, azure y amazon por culta de este truco, las empresas afectadas se quejan a los que dan el servicio como es de esperar
#42 Me voy a mirar mejor "ring.cx", pero que actualmente funcione rápido, no significa que escale bien. A ver como logran lidiar con multitud de usuarios, sin petar el sistema.
Mientras tanto seguiré con https://riot.im y mi servidor federado, ya que es el que utilizan mis contactos.
#41
1 el hecho de que sea federado es irrelevante si el servidor esta comprometido adios a la seguridad/privacidad
2 arriba de dicho ring.cx si las vídeo llamadas con son "instantáneas" no se lo que es
#14#5 Los navegadores web están preparados para formatear correctamente documentos html en los que faltan etiquetas de cierre implícitas, como por ejemplo o .
#4 aunque un navegador no va a hacer uso de esta técnica, si alguien es capaz de usar domain fronting desde una web, podría enmascarar peticiones a a dominios lícitos y enrutarlas a sus propios servidores.
AWS y Google están aplicando parches para evitar que sus CFNs permitan esto por las consecuencias de seguridad.
También está el problema de que gobiernos cómo Irán, corten acceso a dominios lícitos usados por Signal para evitar la censura, dejando a estas empresas algo cabreadas con sus proveedores, Amazon y Google.
Es sin duda un tema muy interesante por ser usado para temas de libertad de expresión pero al mismo tiempo ser un exploit.
#19 Si no vas o te comunicas con alguien de los países de los que habla la noticia técnicamente para ti no cambiará nada (aunque está bien preocuparse por lo que le pasa a otra gente).
Comentarios
¿Y eso será un problema técnico para Amazon o simplemente buscan tener contentos a los gobiernos de según qué países para no tener problemas con ellos en un futuro?
#2, lo mismo el país puede responsabilizar en parte al proveedor del hosting o similar. Veo sentido a que Amazon quiera que no se hagan cosas "ilegales" a través de ellos sin tener que implicar motivos oscuros detrás.
#2 Si lo siguieran permitiendo, el pais de turno podría decidir bloquear toda la red en la que se encuentra el dominio que se pretende capar, en este caso el de Signal, con lo que en la práctica supondría que la mitad de AWS, Google Cloud, o lo que fuera no funcionaría en ese país al completo, una gracia para el resto de clientes. Tratan de evitar efectos colaterales al resto de clientes (o eso parece).
#7 Sep, suena a efectos colaterales del bloqueo por parte de Rusia de chorrocientos millones de IP's de Amazon y Google tratando de bloquear Telegram.
#20 pues precisamente aquí hablamos de Rusia...
#24 y que tiene que ver rusia con signal? en serio piensas que han sido los rusos los que han puesto firme a bezos? no me hagas reir.
#2 los gobiernos de segun que paises? se reducen a uno, el de gringolandia que es el que sostiene al gobierno golpista de egipto.
#2 No es un problema técnico. Están lamiendo las manos que deben lamer.
No sabía que la pasta de dientes usaba esas cosas... Me voy a pasar a Colgate.
Eso pasa por usar servidores que no están bajo tu control.
Lo que van a tener que hacer es montar sus propias granjas de equipos.
#15 muchisimo mas facil de bloquear. precisamente el objtivo de tener servicios cloud es que puedes cambiar IP cada hora por ejemplo.
#32 ¡Cierto!
Supongo que lo ideal es llegar a algún equilibrio entre equipos propios y equipos "cloud".
DNS over TLS
jaque mate, censores.
#10 eso no resuelve este problema. El problema está en TLS que necesita en público el nombre del dominio y TLS es parte de TCP.
#12 no
DNS over TLS es una nueva especificación del protocolo DNS que aún no está extendida, pero que cuando lo ese, la resolución del dominio DNS será cifrada punto a punto.
#13 en eso estamos de acuerdo.
1. DNS over TLS te da la ip a llamar
2. Iniciar a TLS handshake a la ip
3. Censor puede ver el dominio en la primera request de TLS porque va sin cifrar
2 debe incluir el dominio para especificar que certificado y CA es esperada.
#16 la ip siempre va sin cifrar, el protocolo tpc-ip es de más bajo nivel que HTTPS
Incluso usando domain fronting, el censor sabe a qué ip haces las peticiones.
No creo que sea posible un protocolo IP, en el que la IP va cifrada punto a punto, no sería posible enrutar la petición.
A no ser que el paquete se propagase inicialmente en todas direcciones, y solo el que sabe que es para él, respondiese en sentido inverso marcando la ruta... no sé... no soy teleca, pero me parece ciencia ficción un IP cifrado punto a punto.
#18 si lees él post de Signal, la censura se hace al inicio de TLS.
El primer paquete de TCP es un CONNECT , y este va en claro. Como parte de esta retirar va hacer un upgrade a TLS, por lo que el segundo paquete intercambiado ya va cifrado.
Es en ese primer paquete dónde Irán estaba cortando la comunicación, leyendo el dominio de Signal. Para evitarlo, habían puesto un dominio tercero con alojamiento en un CDN que le el header con el forwarding. Es hacer una especie de túnel haciendo TCP/TLS
#21 https://hpbn.co/transport-layer-security-tls/ el problema esta con Server Name Indication (SNI)
#28 ummmm
parece que tienes razón
#18 En tor los paquetes van encapsulados, como muñecas matrosca, cuando un nodo recibe un paquete quita una capa y solo sabe quien se lo ha mandado y a quien debe pasárselo, desconoce el inicio y el final del circuito (salvo que seas nodo de entrada o salida, claro) y el contenido, el siguiente nodo hace lo mismo .
#33 en TOR el nodo que inicia la comunicación no decide qué nodo va a ser el que finalmente envíe el paquete a internet
No creo que pueda aplicarse el modelo de TOR a un sistema que conecte de punto específico a punto específico
¿paso algo por alto?
#34 No, simplemete elige el destino final del paquete, la red elige por que nodos va a pasar, los miembros de esa red no saben el origen o fin del circuito, el nodo de salida del circuito tampoco sabe del origen por lo que se mantiene su privacidad, solo los nodos de salida están expuestos.
#10 Cuando inicias una conexión HTTPS con un servidor se envía en plano el nombre de la máquina a la que vas a conectarte, lo que incluye el dominio. Ese nombre va en plano en la negociación, como parte del SNI https://en.wikipedia.org/wiki/Server_Name_Indication y un firewall que analice el tráfico puede decidir bloquear si ve que te conectas a un dominio "prohibido".
eso viene porque rusia si bloqueo una parte de google, azure y amazon por culta de este truco, las empresas afectadas se quejan a los que dan el servicio como es de esperar
#42 Me voy a mirar mejor "ring.cx", pero que actualmente funcione rápido, no significa que escale bien. A ver como logran lidiar con multitud de usuarios, sin petar el sistema.
Mientras tanto seguiré con https://riot.im y mi servidor federado, ya que es el que utilizan mis contactos.
#40 Nos es p2p, pero es federado. Todavía no veo una mensajería instantanea p2p.
#41
1 el hecho de que sea federado es irrelevante si el servidor esta comprometido adios a la seguridad/privacidad
2 arriba de dicho ring.cx si las vídeo llamadas con son "instantáneas" no se lo que es
#22
No, lo usan.
El domain fronting también lo usa Telegram.
#17 usaba, lo tuvieron que quitar.
Controlan nuestras comunicaciones y no quieren que escapemos a otros canales.
Recomiendo usar Whatsapp, que tiene la ventaja de que en Rusia no está prohibido.
#3
#14 #5 Los navegadores web están preparados para formatear correctamente documentos html en los que faltan etiquetas de cierre implícitas, como por ejemplo o .
#3 deberías usar ring.cx
#9 O https://riot.im
#38 matrix no es p2p debes pagar el server o confiar en uno
#3 Miradlo, ¿no es adorable?
El artículo tambien dice que Google lo prohibio hace tiempo. El problema no parece que sea que Amazon lo prohiba, sino que no hay alternativas.
#4 aunque un navegador no va a hacer uso de esta técnica, si alguien es capaz de usar domain fronting desde una web, podría enmascarar peticiones a a dominios lícitos y enrutarlas a sus propios servidores.
AWS y Google están aplicando parches para evitar que sus CFNs permitan esto por las consecuencias de seguridad.
También está el problema de que gobiernos cómo Irán, corten acceso a dominios lícitos usados por Signal para evitar la censura, dejando a estas empresas algo cabreadas con sus proveedores, Amazon y Google.
Es sin duda un tema muy interesante por ser usado para temas de libertad de expresión pero al mismo tiempo ser un exploit.
Joooder, me lo instalé hace 2 dias escapando de Telegram y ya empiezan?
#19 Te pasa por hipster
#19 escapando de telegram por? incluso en rusia o iran donde estan prohibidos funcionan si usas i2p o proxys.
Tambien un grupo ha sacado
https://github.com/Moonshotgroup/TelegramDR--AndroidNative
https://play.google.com/store/apps/details?id=org.telegram.digitalresistance
(hice un diff, mas de 400.000 lineas de diferencia entre el fuente de ese repositorio y el oficial de android)
#19 Si no vas o te comunicas con alguien de los países de los que habla la noticia técnicamente para ti no cambiará nada (aunque está bien preocuparse por lo que le pasa a otra gente).