HTTP Public Key Pinning ( HPKP ) es un mecanismo de seguridad de Internet obsoleto distribuido a través de un encabezado HTTP que permite a los sitios web HTTPS resistir la suplantación de identidad por parte de atacantes que utilizan certificados digitales mal emitidos o fraudulentos . [1] Un servidor lo utiliza para entregar al cliente (por ejemplo, un navegador web ) un conjunto de hashes de claves públicas que deben aparecer en la cadena de certificados de futuras conexiones al mismo nombre de dominio .
Por ejemplo, los atacantes pueden comprometer una autoridad de certificación y luego emitir certificados incorrectos para un origen web . Para combatir este riesgo, el servidor web HTTPS ofrece una lista de hashes de claves públicas "fijados" válidos durante un tiempo determinado; en las conexiones posteriores, durante ese tiempo de validez, los clientes esperan que el servidor use una o más de esas claves públicas en su cadena de certificados. Si no lo hace, se muestra un mensaje de error, que el usuario no puede eludir (fácilmente).
La técnica no fija certificados, sino hashes de claves públicas . Esto significa que se puede utilizar el par de claves para obtener un certificado de cualquier autoridad de certificación, siempre que se tenga acceso a la clave privada. Además, el usuario puede fijar claves públicas de certificados raíz o intermedios (creados por autoridades de certificación), restringiendo el sitio a los certificados emitidos por dicha autoridad de certificación.
Debido a la complejidad del mecanismo HPKP y la posibilidad de un uso indebido accidental (que podría causar una condición de bloqueo por parte de los administradores del sistema), en 2017 los navegadores dejaron de usar HPKP y en 2018 eliminaron su soporte a favor de la Transparencia de Certificados . [2] [3]
El servidor comunica la política HPKP al agente de usuario a través de un campo de encabezado de respuesta HTTP llamado Public-Key-Pins(o Public-Key-Pins-Report-Onlysolo para fines de informes).
La política HPKP especifica los hashes de la información de la clave pública del sujeto de uno de los certificados en la cadena de certificados de clave pública X.509 auténtica del sitio web (y al menos una clave de respaldo) en pin-sha256directivas, y un período de tiempo durante el cual el agente de usuario debe aplicar la fijación de clave pública en max-agela directiva, includeSubDomainsdirectiva opcional para incluir todos los subdominios (del dominio que envió el encabezado) en la política de fijación y report-uridirectiva opcional con URL a donde enviar informes de violación de fijación. Al menos una de las claves públicas de los certificados en la cadena de certificados debe coincidir con una clave pública fijada para que el agente de usuario considere válida la cadena.
Al momento de la publicación, el RFC 7469 solo permitía el algoritmo hash SHA-256 . (El Apéndice A del RFC 7469 menciona algunas herramientas y argumentos necesarios que se pueden utilizar para producir hashes para políticas HPKP).
Un operador de sitio web puede optar por anclar la clave pública del certificado raíz de una autoridad de certificación raíz particular, permitiendo que solo esa autoridad de certificación (y todas las autoridades intermedias firmadas por su clave) emitan certificados válidos para el dominio del sitio web, y/o anclar la(s) clave(s) de uno o más certificados emisores intermedios, o anclar la clave pública de la entidad final.
Se debe fijar al menos una clave de respaldo, en caso de que sea necesario reemplazar la clave fijada actual. El HPKP no es válido sin esta clave de respaldo (una clave de respaldo se define como una clave pública que no está presente en la cadena de certificados actual). [4]
HPKP está estandarizado en RFC 7469. [1] Amplía la fijación de certificados estáticos , que codifica hashes de clave pública de sitios web o servicios conocidos dentro de navegadores web y aplicaciones. [5]
La mayoría de los navegadores desactivan la función de fijación de cadenas de certificados con certificados raíz privados para habilitar varios escáneres de inspección de contenido corporativo [6] y herramientas de depuración web (como mitmproxy o Fiddler ). El estándar RFC 7469 recomienda desactivar los informes de violación de la función de fijación para los certificados raíz "definidos por el usuario", donde sea "aceptable" que el navegador desactive la validación de la fijación. [7]
Si el agente de usuario realiza una validación de PIN y no encuentra una huella digital SPKI válida en la cadena de certificados entregada, enviará un informe de violación en formato JSON al host especificado en la directiva report-uri que contiene los detalles de la violación. Esta URI se puede entregar a través de HTTP o HTTPS ; sin embargo, el agente de usuario no puede enviar informes de violación de HPKP a una URI HTTPS en el mismo dominio que el dominio para el que está informando la violación. Los hosts pueden usar HTTP para el report-uri, usar un dominio alternativo o usar un servicio de informes. [8]
Algunos navegadores también admiten el Public-Key-Pins-Report-Only, que solo activa este informe pero no muestra un error al usuario.
Durante su pico de adopción, se informó que HPKP era utilizado por 3.500 de un millón de sitios de Internet importantes, una cifra que disminuyó a 650 a fines de 2019. [9]
Las críticas y la preocupación giraban en torno a escenarios de errores humanos o maliciosos conocidos como HPKP Suicide y RansomPKP. [10] En tales escenarios, el propietario de un sitio web vería gravemente obstaculizada su capacidad de publicar nuevos contenidos en su dominio, ya sea perdiendo el acceso a sus propias claves o teniendo nuevas claves anunciadas por un atacante malicioso.