¿Puede considerarse la vulnerabilidad la falta de identificación de certificados?

  

El uso de la fijación de certificados (o claves públicas) puede considerarse una buena práctica para la defensa en profundidad

HPKP puede considerarse bueno solo cuando se diseña e implementa cuidadosamente. En teoría, la fijación de claves públicas es más segura porque reduce el ataque a la superficie al limitar una serie de certificados (anclas de confianza) en las que la aplicación confía. El mayor problema con la fijación de claves públicas es la gestión de certificados. Aquí es donde terminan la mayoría de las historias de HPKP.

Si confía solo en un certificado / clave pública particular, es irrevocable. Si la clave está comprometida, la aplicación se vuelve inmediatamente vulnerable, ya que está codificada en la aplicación. La misma historia es cuando simplemente reemplaza el certificado. Deberá actualizar la aplicación, cargarla en la tienda de aplicaciones y esperar hasta que los clientes actualicen la aplicación en sus dispositivos. La seguridad siempre es una compensación entre seguridad y flexibilidad.

Una mejor solución sería enviar un conjunto de anclajes de confianza (certificados de raíz de confianza) en los que su aplicación confía y configurar la lógica de validación de certificados (integrada en el sistema operativo, no cree su propio criptografía) para usar solo estas raíces como anclas de confianza. Es decir, las cadenas aún deben validarse, la verificación de revocación debe realizarse incluso si utiliza HPKP. Este enfoque supone que el compromiso clave de CA es menos probable que el compromiso clave de servidor SSL. En este caso, tienes mejor seguridad y flexibilidad. Sin embargo, aún tiene que mantener la lista de anclajes de confianza y actualizarlos cuando sea necesario (porque ya no confía en el almacén de confianza del sistema).

De nuevo, es en teoría. En la práctica, a la mayoría de los desarrolladores de aplicaciones no les importa en absoluto y su implementación de HPKP es peor (más vulnerable) que el almacén de confianza del sistema estándar.

Vale la pena leer en HPKP: enlace .

No usaría HPKP para nada, especialmente si el equipo está utilizando certificados autofirmados, HPKP nunca debe considerarse una opción.

HPKP ayuda a atacar a los atacantes de estados nacionales, quienes podrían ser capaces de poseer una autoridad de certificación, y obtener su propio certificado. De lo contrario, los buenos HSTS deberían bastar, ya que muy pocos atacantes tienen la capacidad de obtener un certificado válido para un dominio que no controlan.

El único DRAWBACK real de HPKP, es que puede causar problemas graves (!). Si aloja un sitio web en un servidor con HPKP y el servidor explota, o si pierde sus claves, esto es catastrófico.

Esto le sucedió a SmashingMagazine, que cubren en este blogpost . En resumen, lo resumen mejor que yo:

  

La fijación de teclas protege contra un ataque relativamente raro que es muy difícil   para arrancar y eso no es un escenario de gran amenaza contra una   sitio web basado en contenidos como Smashing Magazine, pero lo hace en el   costo de causar potencialmente mayor, en el peor de los casos incluso   catastrófico - apagones

El suicidio de HPKP es malo, pero peor aún es el rescate de HPKP. Cuando un atacante piratea su sitio, intercambia las claves y configura HPKP, solo para regresar y eliminar esa clave un tiempo después. Los visitantes que hayan llegado a su sitio mientras HPKP estaba programado, ahora tendrán que saltar a través de aros masivos para visitarlo nuevamente.

Y es por eso que Google dejará de admitir HPKP en Chrome este mayo: enlace

En resumen, si su equipo sigue utilizando un certificado autofirmado, definitivamente no es lo suficientemente sofisticado para HPKP.