El interrogador proporcionó los siguientes detalles: “¿Hay alguna posibilidad de que el atacante pueda engañar a otras personas simulando a otros y enviando una clave pública falsa?”
En una configuración PKI configurada correctamente, la respuesta es no. Los clientes se han configurado con la clave pública de muchas autoridades de certificación (CA). Esto lo hace el navegador o el fabricante del sistema operativo para las CA raíz de confianza y la organización del usuario para sus propias CA. Los clientes no están programados con certificados para servidores individuales. La infraestructura de CA hace que esto sea innecesario, como veremos.
Los certificados se presentan cuando un cliente necesita autenticar o identificar un recurso, como un servidor web. El servidor presenta un conjunto de certificados, que incluye una firma digital firmada por la clave privada del servidor. (Estoy ignorando algunos detalles del protocolo aquí.) El cliente puede verificar que la firma coincida con la clave pública proporcionada por el servidor.
- ¿Qué es una herramienta interna en la detección dinámica de malware?
- ¿Cuál es el alcance de la informática forense en la India y en el extranjero?
- ¿Qué tan seguro es un sistema de seguridad inalámbrico para el hogar? ¿Se puede hackear?
- Cómo detener el spyware
- Cómo evitar los sistemas de seguridad
Pero el cliente no sabe nada sobre la clave pública del servidor correcto. Si simplemente nos detuviéramos aquí, un atacante podría enviar cualquier clave y el destinatario creería que se están conectando al servidor correcto. Entonces, como parte de la cadena de certificados, el servidor proporciona otra firma digital: su clave pública firmada por una CA. Esto le dice al cliente que la CA confía en este certificado del servidor y, por extensión, en la identidad del servidor. Esta CA todavía no es la CA raíz que el cliente conoce. En cambio, el servidor proporciona otra firma en la que una segunda CA firma la clave pública de la primera CA. De esta manera, se puede encadenar un número arbitrario de CA, hasta que finalmente se alcance una de las CA raíz de confianza preprogramadas. Los certificados se emitieron en orden inverso de verificación: la CA raíz emitió un certificado a otra CA, que emitió un certificado a otra CA, que emitió un certificado al servidor.
Este sistema funciona perfectamente en papel, pero tiene algunos problemas:
- Se basa totalmente en el funcionamiento seguro y adecuado de las AC. Cualquier incumplimiento o mal uso rompe todo el sistema. Y, de hecho, a las AC se les han infringido reiteradamente y se han emitido certificados incorrectamente. Esta es, con mucho, la mayor debilidad del sistema.
- Una vez que se compromete un certificado y se descubre el compromiso, no hay buenas medidas de recuperación. El bloqueo del certificado se puede realizar a través de una Lista de revocación de certificados, pero al hacerlo invalida todo el contenido firmado previamente, lo que causa enormes problemas funcionales, como el rechazo de la ejecución del software y los sitios web que se niegan a cargar.
- La decisión de qué hacer cuando se presenta un certificado incorrecto a menudo se deja al usuario, quien puede ignorar la advertencia y conectarse al servidor del atacante.
- Ha habido algunas vulnerabilidades en implementaciones específicas. Por ejemplo, ha habido errores en los que el cliente identifica correctamente que el certificado no es válido, pero luego ignora el error. Todos esos errores conocidos han sido reparados.
