La mancanza di blocco del certificato può essere considerata una vulnerabilità?

The use of certificate (or public key) pinning can be considered as a good practice for defense in depth

HPKP può essere considerato valido solo quando è attentamente progettato e implementato. In teoria, il blocco della chiave pubblica è più sicuro perché riduce l'attacco di superficie limitando un certo numero di certificati (trust ancore) dei trust dell'applicazione. Il problema più grande con il blocco delle chiavi pubbliche è la gestione dei certificati. Qui è dove finisce la maggior parte delle storie HPK.

Se ti fidi solo di un particolare certificato / chiave pubblica, è irrevocabile. Se la chiave è compromessa, l'applicazione diventa immediatamente vulnerabile, perché è codificata nell'applicazione. La stessa storia è quando si sostituisce semplicemente il certificato. Dovrai aggiornare l'applicazione, caricarla su App Store e attendere che i client aggiornino l'app sui loro dispositivi. La sicurezza è sempre un compromesso tra sicurezza e flessibilità.

Una soluzione migliore sarebbe quella di spedire una serie di ancore fidate (certificati radice attendibili) che l'applicazione considera affidabili e configurare la logica di convalida dei certificati (built-in nel sistema operativo, non eseguire il crypto della propria crittografia) per utilizzare solo queste radici come ancore affidabili. Cioè, le catene devono ancora essere convalidate, il controllo delle revoche deve essere eseguito anche se si utilizza HPKP. Questo approccio presuppone che il compromesso della chiave CA sia meno probabile della compromissione della chiave del server SSL. In questo caso, hai maggiore sicurezza e flessibilità. Tuttavia, è ancora possibile mantenere l'elenco di ancore affidabili e aggiornarli quando necessario (perché non si fa più affidamento sull'archivio di fiducia del sistema).

Di nuovo, è in teoria. In pratica, alla maggior parte degli sviluppatori di app non interessa affatto e la loro implementazione di HPKP è peggiore (più vulnerabile) rispetto all'archivio di fiducia standard del sistema.

Vale la pena leggere su HPKP: link .

Non utilizzerei HPKP per nulla, specialmente se il team utilizza certificati autofirmati, HPKP non dovrebbe mai essere considerato un'opzione.

HPKP aiuta ad attaccare gli attaccanti dello stato nazionale, che potrebbero essere in grado di possedere un'autorità di certificazione, e ottenere il proprio certificato. Altrimenti, il buon vecchio HSTS dovrebbe essere sufficiente, perché pochissimi hacker hanno la capacità di ottenere un certificato valido per un dominio che non controllano.

L'unico DRAWBACK di HPKP, può causare seri problemi (!). Se si ospita un sito Web su un server con HPKP e il server esplode o si perdono le chiavi, questo è catastrofico.

Questo è successo a SmashingMagazine, che coprono in questo blogpost . In breve, lo riassumono meglio di quanto posso:

Key pinning protects against a relatively rare attack that’s very hard to pull off and that’s not a major threat scenario against a content-driven website like Smashing Magazine, but it does so at the cost of potentially causing major — in the worst case even catastrophic — outages

Il suicidio dell'HPKP è cattivo, ma peggio ancora è HPKP Ransom. Quando un utente malintenzionato accede al tuo sito, scambia le chiavi e imposta HPKP, solo per tornare indietro e cancellare quella chiave un po 'più tardi. I visitatori che sono venuti sul tuo sito mentre HPKP è stato impostato, ora dovranno passare attraverso enormi anelli per visitarti di nuovo.

Ed è per questo che Google smetterà di supportare HPKP in Chrome questo maggio: link

In breve, se la tua squadra sta ancora utilizzando il certificato autofirmato --- non sei sicuramente abbastanza sofisticato per HPKP.