[hm] [off-topic] Censurada una web pro-aborto en el estado español por varia ISPs

Jose Legido jose en legido.com
Lun Abr 27 16:43:55 CEST 2020


On Mon, 27 Apr 2020 at 13:57, elle_flane <elle_flane en riseup.net> wrote:

> ok, a mi tambien me parecía el tema gravísmo,
>
> pero hay que descartar el error por tema de certificado.
>
Hola.
Yo creo que el "problema" del certificado es con let's encrypt.
El certificado solo tiene CA y certificado, pero let's encrypt deltro de la
CA pone una CA y una subCA. El navegador lo separa, pero con openssl o curl
no lo hace.
Dicho esto, creo que el certificado está bien. Es decir, si llegas a la IP
y te da el de let's encrypt, es correcto.

El misterio que me queda por resolver es lo de allot.com, me gustaría saber
un caso que le pase.



> Tampoco lo entendía.
>
> El propio hosting puede emitir un certificado, porque no emite un
> certificado válido?
>
> Podeis explicar hacer una mini explicación de como funcionan los
> certificados quien los regula?
>
>
> Los certificados los da letsencrypt (o la CA que sea) validando que tu
eres el propietario del dominio. Si lo hacen bien, consultarán el DNS en tu
DNS principal, así es imposible suplantar la personalidad.


> Gracias, elle
>
>
> El 27/04/20 a les 10:25, Jose Legido escribió:
>
> Hola.
> Si os parece usamos este hilo de los 3  para mirar el problema. A mi me
> interesa mucho entenderlo.
> Yo creo que el bloqueo es solo de DNS, pero si que es verdad que algo pasa
> con el certificado.
> Una vez resuelto el problema de DNS poniendo la IP en /etc/hosts me
> descargo el certificado correcto.
> Es el mismo para los dos dominios aunque cambia el nombre
> openssl s_client -showcerts -servername www.womenonweb.org -connect
> 67.213.76.19:443 -prexit
> openssl s_client -showcerts -servername womenonweb.org -connect
> 67.213.76.19:443 -prexit
>
> La web womenonweb.org redirije a www.womenonweb.org. Si lo grabo en un
> fichero certificado.txt (desde BEGIN CERTIFICAT a END CERTIFICATE)
> Le pongo -L para que siga el redireccionamiento:
> curl -L --cacert certificado.txt https://womenonweb.org
> Me da este error:
> curl: (35) error:1414D172:SSL routines:tls12_check_peer_sigalg:wrong
> signature type
>
> Que es el mismo que si voy directamente a la web final:
> curl -L --cacert certificado.txt https://www.womenonweb.org
>
> Yo en ningún caso veo el certificado que decís de allot.com y me gustaría
> entender en que casos aparece.
>
> Cuando accedo por el navegador añade una CA de "DST Root CA X3" pero la CA
> de let's encrypt y el certificado de www.womenonweb.org son correctos.
>
> En resumen, me gustaría saber si en el algún caso este comando devuelve un
> certificado diferente que el de womenonweb:
> openssl s_client -showcerts -servername www.womenonweb.org -connect
> 67.213.76.19:443 -prexit
>
> Salut
>
>
> On Mon, 27 Apr 2020 at 03:28, fadelkon <fadelkon en posteo.net> wrote:
>
>> Creo que están filtrando por el SNI (server name indication)
>>
>> El 27/4/20 a les 1:49, fadelkon ha escrit:
>> > El 27/4/20 a les 0:19, Jose Legido ha escrit:
>> >> Si de línea de comandos hacen esto:
>> >> openssl s_client -connect 67.213.76.19:443 <http://67.213.76.19:443>
>> >> -prexit
>> >> Tiene que mostrar el certificado original de let's encrypt y
>> >> poniéndose esta línea en /etc/hosts tendrían que poder navegar
>> >> correctamente:
>> >> 67.213.76.19 womenonweb.org <http://womenonweb.org> www.womenonweb.org
>> >> <http://www.womenonweb.org>
>> > Me parece muy interesante. Con openssl (TLS sin nada más) me devuelve el
>> > certificado correcto, con lynx (TLS con HTTP dentro) no.
>>
>> Mirad:
>>
>> > $ openssl s_client -connect 67.213.76.19:443 |& grep issuer
>> > issuer=C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
>>
>> Si llamamos el cliente de openssl con la IP, no sabe nada del server
>> name, así que no añade esta "extensión" al Client Hello de TLS
>> (corroborado con wireshark). En cambio:
>>
>> > $ openssl s_client -connect www.womenonweb.org:443 |& grep issuer
>> > issuer=C = ES, ST = Madrid, L = Madrid, O = Allot, OU = Allot, CN =
>> allot.com/emailAddress=info en allot.com
>>
>> Si llamamos el cliente por el dominio, a parte de resolverlo a una IP,
>> añade el nombre del servidor al Client Hello de TLS (corroborado también).
>>
>> Creéis que puede ser ésto?
>> Qué os sale a vosotrxs?
>>
>> fdk
>
>
>
> On Mon, 27 Apr 2020 at 03:07, fadelkon <fadelkon en posteo.net> wrote:
>
>> Ey
>>
>> El 27/4/20 a les 3:01, chanchan ha escrit:
>> > he pasado por el correo muy en diagonal. está bien eso de jugar con los
>> > parámetros de red y compartirlos cuando no hay otra cosa
>> >
>> > peeero resulta que ahí fuera hay un supuesto pedazo de herramienta para
>> > analizar la censura desde diferentes puntos y con un montón de datos
>> > llamada ooni
>>
>> Sí, empecé por ooni, pero no da tanta información como una captura de
>> wireshark y pruebas complementarias como el traceroute o abrir un tunel
>> con openssl, como propuso Jose. Aportan infomación adicional muy
>> interesante.
>>
>> fdk
>>
>> _______________________________________________
>> HackMeeting mailing list
>> HackMeeting en listas.sindominio.net
>> https://listas.sindominio.net/mailman/listinfo/hackmeeting
>
>
>
> _______________________________________________
> HackMeeting mailing listHackMeeting en listas.sindominio.nethttps://listas.sindominio.net/mailman/listinfo/hackmeeting
>
>
> _______________________________________________
> HackMeeting mailing list
> HackMeeting en listas.sindominio.net
> https://listas.sindominio.net/mailman/listinfo/hackmeeting
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: </pipermail/hackmeeting/attachments/20200427/dd027547/attachment.html>


Más información sobre la lista de distribución HackMeeting