Ataques en SSL y SSH

Debido a que la conexión SSH intercambia una clave de tal manera que solo los titulares de las dos claves privadas pueden tener acceso a la clave compartida, no hay forma de que los enrutadores puedan inyectar información significativa. Podrían intentar inyectar información, pero como la información que inyectan no está encriptada con la clave de encriptación compartida mutuamente acordada, solo saldría como basura en el otro extremo y, si la transmisión estaba en un modo de encadenamiento, también podría potencialmente corromper toda la sesión.

SSL utiliza un mecanismo similar en el que el usuario final podrá indicar a qué servidor se envió la información y solo el servidor con el que el usuario final pudo hablar puede obtener acceso a la clave de cifrado que el cliente selecciona.

Lo único que no se puede determinar necesariamente es si el cliente B es en realidad el cliente a menos que también tengan un par de claves pública / privada que sea CA firmado o conocido anteriormente. Tanto SSL como SSH tienen mecanismos para admitir la autenticación mutua, pero con frecuencia solo el servidor se autentica contra una CA.

En cualquier caso, aunque R1 o R2 (o cualquiera) pueden reclamar ser B, no sabrían cuál era la solicitud de B bajo ninguno de los dos sistemas, por lo que no podrían tratar de convencer a B de que en realidad eran A siempre que B intente un apretón de manos con la clave pública de A.

La razón principal por la que se definieron SSL y SSH fue precisamente para evitar ataques pasivos y activos desde cualquier punto entre los dos puntos finales. En particular, sus enrutadores R1 y R2:

1. no puede aprender los datos que se transfieren de A a B ( confidencialidad );
2. no puede alterar los datos transferidos ( integridad );
3. no puede hacerse pasar por A o B ( autenticidad ).

En el caso específico de insertar nuevos datos dentro del túnel, veamos cómo se evita en el caso de SSL (SSH es similar): en SSL / TLS , los datos se envían como registros sucesivos. Cada registro contiene hasta 16 kB de datos. Una vez que se haya realizado el handshake inicial (aquí es donde tienen lugar los certificados y la criptografía asimétrica), ambos puntos finales comparten una clave de sesión K (denominada "clave maestra" en SSL terminología), a partir de la cual computan algunas claves que se utilizan para cifrar y autenticar el registro. En particular, para cada registro se calcula un código de autenticación de mensaje , que se puede ver como un tipo de hash con clave; el remitente calcula el MAC y el receptor lo vuelve a calcular. La propiedad criptográfica del MAC es que, sin el conocimiento de la clave MAC, no es posible forjar un par (d, m) de manera que m sea el MAC para datos d .

El MAC se calcula sobre la concatenación de los datos de registro y, de manera crucial, un número de secuencia de registro. Debido al MAC, los atacantes no pueden insertar registros adicionales, reproducir registros antiguos, eliminar registros o alterar el orden de los registros, ya que esto requeriría volver a calcular el MAC para los nuevos datos o el número de secuencia, y, sin la clave, eso no es necesario. .

Tenga en cuenta que sus enrutadores R1 y R2 aún pueden modificar los datos o bloquearlos; Las alteraciones son detectadas de manera confiable por el receptor, pero si el atacante simplemente quiere cortar los cables, bueno, puede hacerlo. Nada en SSL (o SSH) intenta recuperarse de las alteraciones.