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

[Jose Legido]

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
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: </pipermail/hackmeeting/attachments/20200427/ae957418/attachment-0001.html>