Normalmente, los certificados se validan al verificar la jerarquía de firmas; MyCert está firmado por IntermediateCert que está firmado por RootCert , y RootCert se encuentra en la lista de "certificados para confiar" de mi computadora.
La fijación de certificados es donde se ignora todo esto, y se confía en solo este certificado o tal vez solo en certificados firmados por este certificado .
Por ejemplo, si va a google.com, su navegador confiará en el certificado si está firmado por Verisign, Digicert, Thawte o la oficina de correos de Hong Kong (y docenas más). Pero si usa (en las versiones más recientes) Microsoft Windows Update, SOLO confiará en los certificados firmados por Microsoft. No Verisign, Digicert, ni la oficina de correos de Hong Kong.
Además, algunos navegadores más nuevos (Chrome, por ejemplo) realizarán una variación de la fijación de certificados utilizando el mecanismo HSTS . Precargan un conjunto específico de hashes de clave pública en esta configuración de HSTS, que limita los certificados válidos a solo aquellos que indican la clave pública especificada.
Es ambiguo, pero se refiere a soluciones para un problema en la verificación de la cadena de certificados SSL. Esencialmente, la confianza en SSL se reduce a los certificados raíz, los certificados en los que su sistema confía para ser genuinos. Esos vienen con tu sistema operativo o con tu navegador. Si uno de ellos está comprometido, todos los certificados firmados por este y los certificados firmados de manera transitoria deben tratarse como comprometidos.
TACK o la Extensión de Fijación de Clave Pública (aparentemente conocida como certificación por chrome) permite que el administrador de un servidor "fije" la firma de la clave pública de una autoridad certificadora (CA) a un certificado, que es verificado por El cliente (entregado a través de extensión SSL). Si la clave del certificado de CA es diferente al recuperar la cadena de certificados, es probable que el certificado de CA esté comprometido. Fuente
La fijación de certificados también puede referirse a importar un certificado de host en su almacén de confianza, en lugar de confiar en certificados de CA. Esto mitiga el riesgo de que un certificado CA se vea comprometido, pero lo obliga a actualizar los certificados si caducan manualmente. Source
certificados de servidor SSL provienen del mundo X.509 . El cliente verifica la validez del certificado del servidor al validar una gran cantidad de firmas criptográficas de Autoridades de certificación . La belleza del esquema es que es sin estado : un servidor determinado podría cambiar su certificado cada cinco minutos, y seguiría funcionando con los clientes.
Se ha argumentado que, si bien la compatibilidad con certificados de rápida rotación es impresionante pero inútil, en la práctica, un servidor determinado cambia su certificado una vez por año año ; de hecho, un cambio de certificado temprano es indicativo de algunos negocios pesqueros en curso. Fijación de certificados es una forma en que un servidor puede afirmar que esto no debería suceder en condiciones normales, y que cliente debería levantar una ceja metafórica en caso de que ocurra un cambio de certificado inesperado. Esta es una extensión de protocolo, sugerida pero no ampliamente soportada todavía. En realidad, parece que hay varias propuestas relativamente similares que compiten entre sí.
Vea también Convergence , otra extensión de protocolo que se puede considerar como "identificación de certificados por parte de terceros de confianza". La convergencia y las propuestas de fijación de certificados se centran en la misma idea central, que es tener algún estado en el cliente (o en algún lugar, al menos), y activar advertencias de seguridad cuando los certificados cambian con demasiada frecuencia o demasiado pronto. . Cualquiera de estas propuestas alguna vez alcanzará una amplia aceptación (es decir, se implementará de manera compatible con IE, Firefox, Chrome y Safari, y serán utilizados por la mayoría de los administradores de servidores SSL). / p>
En general, lo que sucede en las conexiones https es que el cliente solicita el certificado SSL del servidor compatible con SSL con el que se está comunicando a través de https. El servidor proporcionará un certificado de su almacén de claves. Una vez que el cliente recibe este certificado, valida sus credenciales dependiendo de si
Ahora, si las conexiones tienen un proxy y puede hacer que el dispositivo confíe en su certificado de CA raíz (no autorizado), entonces puede interceptar las conexiones seguras. Esto es esencialmente el ataque del hombre en el medio. Ahora, esto es lo que sucede en el anclaje SSL, que potencialmente agrega una capa de seguridad adicional de los ataques de intermediarios -
La aplicación agrupa los certificados de servidor conocidos con ella. Cuando la aplicación trata de establecer una conexión segura con el servidor, valida el certificado recibido por el servidor con los que ha incluido. Por lo tanto, incluso si el sistema operativo valida la cadena de certificados recibidos contra una CA raíz (potencialmente deshonesta), la aplicación rechazará la conexión que muestra un error de red.
Nota: He intentado responder a esta pregunta desde una perspectiva de fijación de SSL en las aplicaciones de Android. La fijación de SSL es fácilmente posible en tales aplicaciones porque la aplicación ya conoce el servidor (nombre de host) al que se va a conectar. Sin embargo, lo mismo puede ser difícil de implementar en los navegadores. Creo que el navegador Chrome ya implementa esto.
También escribí un código de muestra que demuestra el pinte de certificados en Android. Puede encontrarlo en github . También puede encontrar la misma aplicación en playstore .
Más información:
Los certificados SSL / TLS están firmados por otros certificados. Los navegadores normalmente reconocen un certificado como válido cuando en algún punto de esta cadena de firmas se encuentra una entidad confiable. Las firmas de las entidades de confianza vienen en la instalación básica del sistema operativo y los navegadores. Es una lista incrustada de alrededor de 100 entidades.
Si una de las autoridades de certificación de confianza está comprometida o si la autoridad de certificación es víctima de un fraude, puede emitir un certificado válido a un delincuente. El criminal tendrá un certificado SSL / TLS perfecto en su nombre. El criminal podrá realizar ataques de "hombre en el medio" exitosos y creíbles. El usuario verá una información de certificado válida para su sitio web.
Además, no es difícil convencer al usuario de que instale una nueva autoridad de certificación de confianza. Por ejemplo, en Brasil, la autoridad de certificación oficial no es reconocida por los navegadores principales y todos tienen que instalar una autoridad de certificación adicional. Los navegadores se mostraron muy buenos en esto: solo haga clic en un enlace y responda que sí. Para alcanzar este nivel de usabilidad, creo que esta es una tarea común en todo el mundo.
Las autoridades de certificación no pueden ser completamente confiables. El proceso para obtener un certificado no es de ninguna manera seguro. Ya compré uno en una empresa y no pagué mucho más por eso. Por supuesto es mucho mejor que nada. Pero necesita mejorar.
En el primer acceso al sitio web secure.example.com, el sitio web envía un mensaje oculto al navegador del cliente que se traduce como:
"en los próximos N días, el sitio web secure.example.com usará el certificado CECECECE. En ese período no acepte otro certificado, incluso si la autoridad de certificación afirma que es válido para este sitio web. Si sucede notifícame en enlace ".
No resuelve la debilidad del proceso de firma de certificados de las autoridades de certificación. Pero minimice la ventana de oportunidad de un criminal para sobrevivir con un hombre en el ataque central. El ataque solo funcionará si el usuario accede por primera vez al sitio web.
Es similar a la seguridad SSH. En el primer acceso se guarda la firma de la clave del servidor. Si en el acceso futuro la identificación no coincide, el sistema genera una advertencia. La advertencia se toma en serio porque solo sucede cuando se realizan cambios reales.
Lo mejor para una empresa grande es recibir notificaciones a través de los clientes quejas de que alguien ha emitido un certificado TLS / SSL real en su nombre a un criminal. Según entiendo, el mecanismo de anclaje fue propuesto por Google
La fijación también se puede realizar fuera del navegador, compilando la huella digital del certificado real en una aplicación.
Lea otras preguntas en las etiquetas public-key-infrastructure tls certificates certificate-pinning