La modalità di blocco SSL di iOS AFNetwork fornisce un ulteriore bonus di sicurezza se viene distribuito un certificato valido

Question

Per quanto mi risulta, SSL Pinning consiste nel confrontare la chiave pubblica o la certificazione di un server con le copie fornite in bundle nel client.

Ho visto in Stackoverflow che molti sviluppatori utilizzano SSL Pinning dalle librerie AFNetwork, ma la maggior parte di essi lo utilizza insieme a un certificato autofirmato.

Ho acquistato un certificato valido da un'autorità di certificazione e ho superato il test per verificare che funzionasse correttamente. Voglio dire, ho impostato il seguente ed ha funzionato

... 
    _sharedHttpsInstance.securityPolicy = [AFSecurityPolicy policyWithPinningMode:AFSSLPinningModeNone]; 
    _sharedHttpsInstance.securityPolicy.allowInvalidCertificates = NO; 
    ... 

Quello che mi chiedo è che se impostare la modalità di Pinning per AFSSLPinningModePulicKey, la mia domanda sarebbe più sicuro in comunicazione con il server in aggiunta a ciò che il certificato valido hanno fornito?

grazie mille.

Answer 1

Io non conosco l'esatta implementazione del pinning SSL in iOS, ma in linea di massima il blocco fornisce sicuramente più sicurezza rispetto alla verifica predefinita rispetto a un insieme di agenzie di certificazione incorporate. Per impostazione predefinita, i sistemi affidano più di 100 CA diverse da tutto il mondo e ciascuna CA ha la possibilità di emettere qualsiasi certificato desiderato, anche se un'altra CA ha già rilasciato lo stesso certificato o un certificato simile. Pertanto, se una di queste 100 o più CA viene compromessa, è possibile rilasciare un certificato per il dominio, che consente di superare i controlli nell'applicazione, a meno che non si utilizzi il blocco dei certificati. Tali compromessi si sono verificati nel 2011 con DigiNotar (non più esistente a causa di ciò) e Comodo (era troppo grande per fallire).

Probabilmente l'utente principale del blocco dei certificati è Google Chrome, in cui è utilizzato per i domini google e questo ha aiutato a rilevare i compromessi di DigiNotar e Comodo.

Uno svantaggio del pinning del certificato potrebbe essere che l'applicazione smetterà di funzionare all'interno di reti che effettuano intercettazioni SSL per motivi di sicurezza. Google Chrome sembra gestire questa situazione accettando il certificato se è firmato da una CA esplicitamente aggiunta dall'utente (cioè senza built-in) in alternativa ai controlli di blocco.

Un'altra domanda che potrebbe essere interessante è se il blocco SSL è sicuro "ENOUTH" per "La maggior parte" dell'applicazione, anche se si lavora con la certificazione autofirmata?

Controllato contro un certificato fisso o chiave pubblica (ad esempio certificato di pinning con o senza auto-firmato) è più sicuro di solo controllare se il certificato è firmato da uno dei 100s CA di fiducia da parte del sistema. E fintanto che lo sviluppatore ha il pieno controllo su entrambi i lati (ad esempio, applicazione e server), anch'esso scala bene. L'unico vantaggio di utilizzare ulteriormente la normale infrastruttura è l'uso del meccanismo di revoca dei certificati. Ma poiché lo sviluppatore ha il controllo delle applicazioni, potrebbe semplicemente sostituire l'appplicazione nel caso in cui il certificato venga compromesso. Quindi sì, nella maggior parte dei casi è abbastanza sicuro fare pinning SSL con un certificato autofirmato ed è più sicuro rispetto all'utilizzo della convalida del certificato standard senza bloccare.

Answer 2

È molto difficile dire in modo categorico se il blocco è migliore o peggiore, poiché sposta il rischio su una parte diversa.

L'applicazione di pinning ti protegge in modo sostanziale contro una potenziale violazione della CA di cui ti fidi. Se una CA viene compromessa e rilasciata un certificato per l'host che stai tentando di contattare, il pinning ti proteggerà da questo perché ti confronterai con il riferimento specifico che hai bloccato, invece di passare attraverso la CA.

Lo svantaggio è che impedirà di utilizzare i meccanismi in atto nella CA per gestire un host compromesso: la revoca del certificato. Se la chiave privata dell'host viene compromessa, passare attraverso il meccanismo di verifica dell'infrastruttura PKI dovrebbe consentire di verificare la revoca e avvisare che si è verificato un problema di questo tipo. Al contrario, non sarai in grado di saperlo con il blocco, dal momento che non stai attraversando la CA per controllare il certificato.

Ovviamente, è possibile combinare entrambi gli approcci, ma ciò potrebbe causare ulteriori problemi (sarebbe necessaria una strategia per gestire i risultati in conflitto in entrambe le valutazioni, altrimenti una CA compromessa che revoca un certificato valido potrebbe causare un DoS).

Non so se il meccanismo di blocco di AFNetworking sostituisce la convalida PKI o lo integra.

In generale, la scelta tra l'uso di pinning o la convalida PKI dipende dal fatto che si pensi che la chiave privata di un particolare host sia più o meno compromessa rispetto alle CA di cui ci si fida.

Un altro svantaggio del pinning è che è necessario aggiornare l'applicazione (o lasciare che l'utente "re-pin") ogni volta che il certificato del server (o almeno la coppia di chiavi, a seconda di ciò che hai bloccato) è cambiato legittimamente. Probabilmente non è una cattiva idea re-key una volta ogni tanto.

(Per essere chiari, non sto dicendo che sono meglio CA, solo che il pinning cambia la serie di problemi.)