El poder en un certificado NO está en el certificado. Está en la clave privada. Cuando un servidor "usa un certificado", realmente usa la clave privada; y el servidor muestra el certificado (que contiene solo la clave pública) al cliente. El certificado es una prueba de que una clave pública determinada pertenece a una entidad específicamente designada. Por ejemplo, el certificado que utiliza el servidor SSL www.google.com contiene ese nombre ( www.google.com ) y la clave pública de Google. ¡Google no te mostrará su clave privada, por supuesto!
Un certificado no se acepta como prueba simplemente porque existe; se supone que un cliente debe realizar validación de certificados , un proceso complejo y complicado que implica crear cadenas de certificados y verificar muchas firmas, porque un certificado está firmado por una autoridad dotada de la facultad de firmar el certificado y, por lo tanto, se denomina autoridad de certificación (o CA para abreviar).
Los certificados se describen en X.509 , que se describe mejor como "La obra maestra de la confusión del diablo". Para hacer frente a la complejidad de X.509, las implementaciones, en particular los navegadores web y otras aplicaciones de cliente SSL, tienden a "tomar atajos" que permiten que todo el proceso de validación se complete en un tiempo razonable, pero también tiene un efecto perjudicial en general seguridad.
Fijación de certificados es un método mediante el cual algunas implementaciones intentan restaurar un poco de seguridad mientras siguen siendo prácticos. Todo el X.509 es libre de contexto : se supone que un cliente puede validar un certificado de servidor sin memoria o estado guardado de las validaciones anteriores. La fijación de certificados es la negación de esa noción: el cliente "fija" un certificado al recordar que algún servidor utilizó un certificado determinado, y luego usar esa información para "validar" eficazmente ese certificado, si el El cliente se conecta nuevamente al mismo servidor. La fijación incluso va a rechazar un certificado de servidor si no es el mismo que usó el servidor durante una conexión anterior a ese mismo servidor.
La idea es que si un atacante intenta mostrarle un servidor falso, no podrá mostrar el certificado del servidor original; por supuesto, el atacante podría mostrar una copia del certificado verdadero (eso es público El servidor lo envía a todos los clientes que se conectan), pero el atacante no podrá usar la clave privada correspondiente, ya que no la tiene (la clave privada, como su nombre lo dice, es privada). En cambio, para poder hacerse pasar por un servidor falso que puede hacer un protocolo de enlace SSL completo, el atacante debe proporcionar al cliente un certificado falso que contenga la clave pública del atacante, distinto de la del servidor. Con la identificación del certificado, el cliente sospechoso notará que el servidor aparentemente cambió los certificados y encontrará que es sospechoso, y se quejará al usuario, quien luego desactivará la ventana emergente de advertencia y procederá a enviar su número de tarjeta de crédito al atacante porque los usuarios son asi.
Se debe tener en cuenta que la fijación de certificados hace algún bien solo en los casos en que el atacante pueda obtener un certificado que sea aceptado por lo que pasa para el código de validación de certificado en las aplicaciones cliente. Ha habido algunos casos altamente publicitados de soborno o piratería de una CA para emitir certificados falsos; Sin embargo, esto todavía es raro. Además, la fijación de certificados no puede ser realmente absoluta porque los certificados tienen fechas de validez, por varias razones (algunas de ellas incluso son racionalmente aceptables), por lo que debe haber algunas situaciones en las que un cliente con identificación de certificados todavía acepte que el servidor cambió su certificado .
Un ejemplo de protocolo, similar a SSL, y uso de pares de claves públicas / privadas (aunque no certificados X.509, sin embargo) en un modelo de "fijación completa", es SSH. Cuando se conecta a un servidor SSH por primera vez, el cliente pregunta si la clave pública enviada por el servidor es la correcta (se supone que el usuario humano debe verificar el hash de esa clave con alguna fuente autorizada); luego, el cliente recuerda esa clave (en el archivo .ssh/known_hosts para clientes SSH basados en Unix) y gritará si el servidor alguna vez cambia su clave.