Ignora SslPolicyErrors mentre si esegue SSL Pinning Secure?

2

Sto implementando il blocco SSL come requisito di sicurezza per un progetto e l'endpoint HTTPS mi fornisce SslPolicyErrors. Si verificano i seguenti errori,

RemoteCertificateChainErrors
    RevocationStatusUnknown
    UntrustedRoot

Questo si verifica solo per il nostro endpoint QA e non per il nostro endpoint PROD, quindi penso che potrebbe esserci un problema con il certificato. Entrambi hanno una catena di certificati.

Se ignoro questi problemi e ti basta controllare che la chiave pubblica certificate.GetPublicKeyString () corrisponda, sarà sicuro, o gli hacker saranno in grado di falsificare il nostro certificato perché non stiamo controllando la catena?

Ecco il codice che controlla SslPolicyErrors che sto considerando di rimuovere.

if (sslPolicyErrors != SslPolicyErrors.None) {
    Debug.Log(sslPolicyErrors);

    for(int i=0; i<chain.ChainStatus.Length;i++){
        Debug.Log("-");
        Debug.Log(chain.ChainStatus[i].Status);
        Debug.Log(chain.ChainStatus[i].StatusInformation);
    }
    return false;
}

Ecco il codice .NET di esempio da OWASP.

ServicePointManager.ServerCertificateValidationCallback = PinPublicKey;

-

    public static bool PinPublicKey(object sender, X509Certificate certificate, X509Chain chain, SslPolicyErrors sslPolicyErrors) {
        if (certificate == null || chain == null)
            return false;

        if (sslPolicyErrors != SslPolicyErrors.None)
            return false;

        // Verify against known public key within the certificate
        String pk = certificate.GetPublicKeyString();
        if (pk.Equals(PUB_KEY))
            return true;

        return false;
    }
    
posta sissonb 17.04.2015 - 19:53
fonte

2 risposte

2

TL; DR sì è sicuro se ti fidi dei mezzi con cui ti sei imbattuto nel valore memorizzato in PUB_KEY .

Ecco alcuni elementi di base necessari per comprendere innanzitutto lo scopo del blocco e perché il tuo scenario consente di ignorare l'errore. Mi concentrerò specificamente su PKI in un'implementazione ideale.

Una chiave privata è un numero molto, molto grande che soddisfa determinati criteri matematici. Con la suddetta chiave privata è possibile derivare una chiave pubblica specifica, ma il processo inverso è così dispendioso dal punto di vista computazionale che può essere considerato impossibile.

"Applicare" una chiave pubblica ai dati è "annullata" dall'applicazione successiva della chiave privata associata e viceversa. Il proprietario di una chiave privata può quindi pubblicare liberamente la propria chiave pubblica per ricevere messaggi che, a tutti gli effetti, solo loro possono leggere. Al contrario, possono pubblicare dati "firmati" che hanno "applicato" la loro chiave privata; ciò consente ai destinatari di essere certi che i dati sono stati pubblicati dal proprietario della chiave privata controllando che "annullando" la firma risulti negli stessi dati.

Questo processo va tutto bene finché le parti della comunicazione sono a conoscenza della proprietà delle chiavi pubbliche. In tale situazione le comunicazioni procedono come segue:

A -> B
B -> A

Tuttavia un avversario può sfruttare la mancanza di conoscenza riguardante la vera proprietà delle chiavi pubbliche per agire come un "uomo nel mezzo" (MITM) affermando falsamente di essere il destinatario previsto:

A -> E -> B
B -> E -> A

A e B sono nessuno più saggio. È qui che entra in gioco il certificato di origine. Il certificato di origine è di proprietà di una terza parte attendibile denominata autorità di certificazione (CA) che (i) verifica i proprietari delle rispettive chiavi pubbliche e quindi (ii) utilizza la propria chiave privata (collegata al certificato di origine) per firmare un messaggio all'effetto di "Persona (A | B) possiede la chiave pubblica (X | Y)". A e B, già conoscendo la chiave pubblica della CA, possono verificare che la firma sia valida. E ora non può più impersonare A o B senza compromettere la CA.

La chiave pubblica della CA è nota per A e B attraverso mezzi diversi dalla rete non affidabile su cui comunicano. Nel caso in cui A e B siano già ben informati riguardo alla chiave pubblica dell'altro, la necessità della CA viene eliminata; questa è la chiave pinning.

Hai "appuntato" la chiave pubblica dell'endpoint del tuo server inserendola nel valore di PUB_KEY .

Le autorità competenti possono pubblicare elenchi di revoca con l'effetto di "Ho detto che A possiede la chiave pubblica X, ma ora dovresti ignorarlo" (ad esempio se la chiave privata è compromessa) e l'errore "RevocationStatusUnknown" parla in questo senso.

L'errore 'UntrustedRoot' indica che chiunque stia agendo come CA in questo caso non è veramente affidabile. Chi è affidabile e come vengono distribuite le chiavi va oltre lo scopo di questa risposta.

    
risposta data 18.04.2015 - 12:44
fonte
2

Una root attendibile è rilevante solo se è necessario convalidare la catena di fiducia del certificato fino a quando non si ottiene la root. Se si prevede solo un certificato specifico o una chiave pubblica, non è necessario controllare alcuna catena e in molti casi non esiste comunque alcuna catena di fiducia (cioè certificati autofirmati).

In caso di revoca potreste effettivamente aggiungere un URL al certificato da cui il cliente può ottenere i CRL o dove può inviare anche le interrogazioni OCSP e quindi avere anche la possibilità di revocare i certificati aggiunti. Ma questo probabilmente non funzionerà con certificati autofirmati poiché le risposte OCSP e CRL devono essere firmate dalla CA di emittenti (o un'altra CA attendibile a questo scopo) e nel caso di certificati autofirmati il certificato di emittenti è quello che si desidera per controllare lo stato di revoca, che non avrebbe senso.

Potresti dare un'occhiata alle informazioni OWASP sul blocco che viene fornito con esempi di codice su come implementare inchiodare correttamente.

    
risposta data 17.04.2015 - 20:26
fonte

Leggi altre domande sui tag