Si no se mantiene la integridad, un atacante podría alterar las páginas web en tránsito y, por ejemplo, modificar el código Javascript contenido en estas páginas. El cifrado, por sí mismo, no evita alteraciones relativamente precisas, siempre que el atacante tenga alguna idea sobre qué son los datos cifrados. En la mayoría de los contextos web, el atacante también puede registrarse como un usuario normal, por lo que puede ver la estructura de las páginas web que obtienen los usuarios normales.
Cuando la conexión utiliza RC4 , se genera un flujo pseudoaleatorio dependiente de la clave y se XORea, poco a poco, con Los datos a cifrar. Por lo tanto, si el atacante "adivina" que un byte dado es el cifrado de una 'A' (código ASCII 0x41) y desea convertirlo en el cifrado de una 'm' (código ASCII 0x6D), entonces solo tiene que XOR el byte encriptado con 0x2C (que es el XOR de 0x41 con 0x6D) para obtener otro byte encriptado que, al descifrar, producirá una 'm' en lugar de una 'A'. Nada más sería impactado; Por lo tanto, con el cifrado RC4, las alteraciones quirúrgicas son fáciles.
Con un cifrado de bloque en modo CBC , las cosas son menos fáciles para el atacante , pero aún puede hacer algo malo: si quiere modificar un byte específico, puede hacerlo, pero esto dañará el bloque anterior. Específicamente, con un cifrado de bloque, los datos son una secuencia de bloques de 8 o 16 bytes (según el cifrado: 8 bytes para 3DES, 16 bytes para AES). El atacante puede modificar a voluntad un bloque, con precisión quirúrgica, siempre que conozca el valor inicial de ese bloque y no le importe cambiar el bloque anterior en una basura aleatoria incontrolable.
Tomemos un ejemplo. Supongamos que un sitio web tiene una página de inicio de sesión, con un formulario HTML, que tiene este aspecto:
<form action="https://www.example.com/authenticate.php">
Login: <input type="text" name="login" /><br />
Password: <input type="password" name="password" /></br />
<input type="submit" name="Submit" />
</form>
Sé que es feo; Es solo un ejemplo. Cuando el usuario hace clic en el botón "enviar", el navegador envía una solicitud POST a la página https://www.example.com/authenticate.php .
Ahora suponga que esta página está cifrada con CBC con 3DES (bloques de 8 bytes) y que el '.' de '.com' pasa a estar al comienzo de un bloque. El atacante puede luego XORAR los 8 bytes encriptados anteriores (los bytes correspondientes a .example ) con lo siguiente:
00 01 0E 09 01 07 0D 5B
En el navegador de la víctima, el formulario se descifra como:
<form action="https://www########.bad.fx/henticate.php">
Login: <input type="text" name="login" /><br />
Password: <input type="password" name="password" /></br />
<input type="submit" name="Submit" />
</form>
Donde el "########" será algunos bytes aleatorios. Siempre que ninguno de ellos sea un cero o una comilla doble (las posibilidades de que esto suceda son bajas), entonces el navegador los considerará como parte de la URL de destino. El atacante controla el dominio bad.fx (el TLD "fx" no existe realmente; siéntase libre de reemplazarlo con su "TLD favorito para personas malvadas"); el DNS del atacante redirige alegremente todas las solicitudes de cualquier cosa .bad.fx a la dirección IP de su servidor; y el atacante compró (completamente legalmente) un certificado comodín para "* .bad.fx". Cuando el usuario ingresa su contraseña, su navegador se conecta al sitio web controlado por el atacante, hace el SSL, está perfectamente contento con el certificado del atacante (asumiendo que ninguno de los "#" es un punto; de nuevo, esto es probable), y envía la contraseña.
Afortunadamente , SSL incluye una fuerte protección de integridad, que evita tales ataques. Con cifrados de flujo como RC4 y cifrados de bloque en modo CBC, la protección de integridad utiliza HMAC ; las versiones más nuevas de TLS también pueden usar cifrados de bloque en el modo GCM , que integra una protección de integridad igualmente buena. Si el atacante intentó alguno de los trucos descritos anteriormente, el cliente (navegador web) detectaría la alteración y la protesta y se negaría a usar la página desencriptada. Consulte el estándar , sección 6.2.3.