¿Puede el ISP bloquear HTTPS de forma selectiva? [duplicar]

Todos los navegadores actuales hacen SNI (Indicación del nombre del servidor) para hacer posible configurar diferentes nombres de host en la misma IP pero con diferentes certificados. Para hacer que esto funcione, el nombre de host del servidor de destino se incluye claramente en el paquete de intercambio inicial del cliente (ClientHello).

Al bloquear selectivamente ClientHello, si contiene cadenas específicas dentro de la extensión SNI, un firewall podría bloquear sitios SSL específicos, incluso sin afectar a otros sitios SSL detrás de la misma IP. En los cortafuegos menos capaces (sin una inspección más profunda), simplemente podría tener reglas más amplias para bloquear el acceso a direcciones IP específicas.

Debido a que se trata de SSL y el firewall no tiene acceso al certificado real, no puede enviar al cliente una página de error adecuada, por lo que el cliente solo recibe un mensaje de error extraño dentro del navegador porque la conexión se restableció o se agota el tiempo, dependiendo sobre cómo los firewalls manejan el bloqueo.

Técnicamente, un ISP puede bloquear cualquier tráfico, ya que son su ruta hacia el resto de Internet. Pueden bloquear cualquier puerto, página web, etc.

Si está preguntando si pueden degradar un sitio que solicita con HTTPS a HTTP regular, es posible que le sirvan esa página. Pero no aparecería como HTTPS, vería la URL como HTTP y no vería un ícono de bloqueo, etc. En el nivel del paquete, HTTPS y HTTP son diferentes y brindan información diferente.

Lo que podría hacer un ISP

• Como operador de red, el ISP podría bloquear todo el tráfico hacia / desde algunas direcciones IP para el puerto 443, que es el puerto TCP estándar utilizado para HTTPS. Eso podría ser una simple regla de firewall. Por "bloque", me refiero a evitar que la conexión TCP se establezca en absoluto. (Reenviar una página de denegación a través de HTTPS es bastante más desafiante, en teoría no es posible).
• Si solicita http://example.com/ y el servidor normalmente enviaría una redirección HTTP que le indica a su navegador que vaya a https://example.com/ en su lugar, el ISP podría interceptar esa respuesta de redirección.

Lo que un ISP no puede hacer

Supongamos que el ISP no puede descifrar o solucionar el problema de la criptografía.

• El ISP no puede distinguir entre una solicitud a https://example.com/some/permissible/location y https://example.com/some/objectionable/location , y por lo tanto no puede bloquear URLs de forma selectiva dentro de un sitio web.
• El ISP no puede distinguir entre https://virtualhost1.example.com/ y https://virtualhost2.example.com/ , si ambos hosts virtuales están alojados en la misma dirección IP, y comparten un certificado SSL comodín. Sin embargo, se puede falsificar el DNS para que esto suceda, ver más abajo.

Advertencias

• Si el usuario descarta de manera inconsciente todas las advertencias de falta de coincidencia del certificado SSL, eso anula toda la protección de intermediario que normalmente proporciona SSL.
• Si el navegador del usuario reconoce que una Autoridad de Certificación corrupta o comprometida está autorizada, entonces el ISP también podría aprovechar esa confianza fuera de lugar para descifrar todo el tráfico HTTPS como si no estuviera cifrado.
• El ISP ejecuta un servidor DNS y es probable que utilice su servidor DNS. Su servidor DNS podría configurarse para devolver respuestas falsificadas, de manera que virtualhost2.example.com o encrypted.google.com se asigne a una dirección IP que bloquean.

Sí, pueden. Por ejemplo, las conexiones https a Google están bloqueadas en China, mientras que el usuario puede acceder a otros sitios web a través de https, como Bing.