Si un atacante tiene la capacidad de modificar los datos transferidos a través de una conexión a Internet, ¿puede afectar a TLS?

Sí, y esto es exactamente lo que hizo el ataque SSL Strip , al usar la conexión HTTP insegura que giró de manera transparente todos los enlaces HTTPS a los enlaces HTTP y la conexión al proxy, si no se dio cuenta de que no estaba en una conexión HTTPS, podría enviar fácilmente datos confidenciales a través de una conexión no segura.

Como administrador del sitio web, puede combatir esto configurando Seguridad de transporte HTTP estricto , lo que hace esto es una vez que se conecta al sitio una vez que todas las conexiones futuras a ese sitio se realicen a través de HTTPS hasta que el encabezado caduque o la memoria caché de los sitios HSTS del cliente, cualquier intento de conectarse a HTTP se redirigirá automáticamente a HTTPS.

Sin embargo, esto no lo protege si la primera conexión de los clientes con su sitio fue interceptada, pero le ayuda en situaciones como la que describe en su pregunta, donde el navegador intenta HTTP si no tiene ningún prefijo agregado ¹ , HSTS forzará automáticamente el enlace HTTP a un enlace HTTPS si el sitio está almacenado en el caché HSTS del cliente.

^{1: no es ese el navegador que comprueba automáticamente si hay HTTPS si no puede encontrar HTTP. La forma en que funciona es que la página HTTP solo será una página de redireccionamiento a la página HTTPS si la golpeas.}

Un atacante realmente no necesita acceso a la "línea de Internet" para redirigir a alguien a una página web falsa. Si un atacante tiene acceso al servidor, él / ella podría hacer un poco de clonación y cambiar la dirección I.P a lo que quiera, pero puede usar la técnica de "phishing" para redirigir a otra URL. Las computadoras son tan inteligentes como el usuario; por lo tanto, si bien una computadora puede hacer mucho para mantener su seguridad, todavía depende de ese usuario saberlo. Internet podría ser tu amigo o enemigo.

Es posible que desee leer sobre ataques de homógrafos de IDN o falsificación de scripts. Ya que los caracteres que están fuera del habitual a – z (no distingue mayúsculas y minúsculas), 0‒9 y - (guión-menos) ahora pueden usarse , las posibilidades se han ampliado enormemente. Mientras que anteriormente, solo podía esperar engañar a los usuarios utilizando combinaciones como vv para sustituir a w , ahora se pueden emplear homógrafos de Unicode y algunos de estos homógrafos son idénticos cuando se procesan. píxel por píxel! Aquí hay un ejemplo para Twitter (con los puntos de código de Unicode entre paréntesis) generado usando en línea herramienta específicamente para este propósito :

Original: twitter (74,  77,  69,  74,  74, 65,  72)
Fake:     twіttеr (74,  77,  456, 74,  74, 435, 72)

El primero es real, pero el segundo es falso. Dependiendo de la fuente, no todas las versiones "falsas" pueden verse bien. Los caracteres de bloques de código menos compatibles pueden renderizarse utilizando una fuente completamente diferente del resto de la cadena y alertar a la víctima.

Sin embargo, hay una defensa simple contra el ataque: haga que el nombre de dominio Unicode sea el Punycode subyacente (un tema aparte puede leer sobre su cuenta), o renderizar selectivamente como Punycode para nombres de dominio que tienen caracteres de múltiples bloques Unicode.