ok, a mi tambien me parecía el tema gravísmo, pero hay que descartar el error por tema de certificado.
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? 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 > <http://www.womenonweb.org> -connect 67.213.76.19:443 > <http://67.213.76.19:443> -prexit > openssl s_client -showcerts -servername womenonweb.org > <http://womenonweb.org> -connect 67.213.76.19:443 > <http://67.213.76.19:443> -prexit > > La web womenonweb.org <http://womenonweb.org> redirije a > www.womenonweb.org <http://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 > <http://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 > <http://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 > <http://www.womenonweb.org> -connect 67.213.76.19:443 > <http://67.213.76.19:443> -prexit > > Salut > > > On Mon, 27 Apr 2020 at 03:28, fadelkon <fadel...@posteo.net > <mailto:fadel...@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> <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> > <http://womenonweb.org> www.womenonweb.org <http://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 > <http://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 > <http://www.womenonweb.org:443> |& grep issuer > > issuer=C = ES, ST = Madrid, L = Madrid, O = Allot, OU = Allot, CN = > allot.com/emailAddress=i...@allot.com > <http://allot.com/emailAddress=i...@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 <fadel...@posteo.net > <mailto:fadel...@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@listas.sindominio.net > <mailto:HackMeeting@listas.sindominio.net> > https://listas.sindominio.net/mailman/listinfo/hackmeeting > > > > _______________________________________________ > HackMeeting mailing list > HackMeeting@listas.sindominio.net > https://listas.sindominio.net/mailman/listinfo/hackmeeting
_______________________________________________ HackMeeting mailing list HackMeeting@listas.sindominio.net https://listas.sindominio.net/mailman/listinfo/hackmeeting
