¿Es seguro ignorar SslPolicyErrors mientras se hace SSL Pinning seguro?

2

Estoy implementando la fijación de SSL como un requisito de seguridad para un proyecto y el punto final HTTPS me está dando SslPolicyErrors. Ocurren los siguientes errores,

RemoteCertificateChainErrors
    RevocationStatusUnknown
    UntrustedRoot

Esto solo ocurre para nuestro punto final de control de calidad y no para nuestro punto final PROD, así que creo que podría haber un problema con el certificado. Ambos tienen una cadena de certificados.

Si ignoro estos problemas y solo compruebo que la clave pública certificate.GetPublicKeyString () coincide, ¿será segura o los piratas informáticos podrán falsificar nuestro certificado porque no estamos revisando la cadena?

Aquí está el código que comprueba si hay SslPolicyErrors que estoy considerando eliminar.

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;
}

Aquí está el código .NET de ejemplo de 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;
    }
    
pregunta sissonb 17.04.2015 - 19:53
fuente

2 respuestas

2

TL; DR sí, es seguro siempre que confíe en los medios por los que encontró el valor almacenado en PUB_KEY .

Aquí hay algunos antecedentes que se necesitan para comprender primero el propósito de la fijación, y por qué su escenario permite ignorar el error. Me concentraré específicamente en PKI en una implementación ideal.

Una clave privada es un número muy, muy grande que cumple con ciertos criterios matemáticos. Con dicha clave privada es posible derivar una clave pública específica, pero el proceso inverso es tan costoso desde el punto de vista computacional que puede considerarse imposible.

La "aplicación" de una clave pública a los datos se "deshace" mediante la aplicación posterior de la clave privada asociada, y viceversa. De este modo, el propietario de una clave privada puede publicar libremente su clave pública para recibir mensajes que, para todos los propósitos, solo ellos pueden leer. A la inversa, pueden publicar datos "firmados" a los que se les haya aplicado su clave privada "; esto permite que los destinatarios se aseguren de que los datos fueron publicados por el propietario de la clave privada al verificar que "deshacer" la firma produce los mismos datos.

Este proceso es bueno siempre y cuando las partes de la comunicación tengan conocimiento de la propiedad de las claves públicas. En tal situación, las comunicaciones proceden de la siguiente manera:

A -> B
B -> A

Sin embargo, un adversario puede explotar la falta de conocimiento con respecto a la verdadera propiedad de las claves públicas para actuar como un "hombre en el medio" (MITM) al afirmar falsamente que es el receptor esperado:

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

A y B no son más sabios. Aquí es donde entra en juego el certificado raíz. El certificado raíz es propiedad de un tercero de confianza llamado entidad emisora de certificados (CA) que (i) verifica a los propietarios de las respectivas claves públicas, y luego (ii) utiliza su propia clave privada (vinculada al certificado raíz) para firmar un mensaje al efecto de "Persona (A | B) posee clave pública (X | Y)". A y B, que ya conocen la clave pública de la CA pueden verificar que la firma es válida. E ya no puede hacerse pasar por A o B sin comprometer a la CA.

La clave pública de la CA es conocida por A y B a través de medios distintos a la red no confiable en la que se comunican. En el caso de que A y B ya estén informados con respecto a la clave pública del otro, se elimina la necesidad de la CA; esta es la clave de fijación.

Ha "anclado" la clave pública de su punto final de servidor al codificarla en el valor de PUB_KEY .

Las CA pueden publicar listas de revocación a los efectos de "Dije que A posee la clave pública X, pero ahora debe ignorar que" (por ejemplo, si la clave privada está comprometida) y el error 'RevocationStatusUnknown' habla de ese efecto.

El error 'UntrustedRoot' dice que la persona que actúa como CA en este caso no es realmente confiable. Quién es de confianza y cómo se distribuyen sus claves está fuera del alcance de esta respuesta.

    
respondido por el Arran Schlosberg 18.04.2015 - 12:44
fuente
2

Una raíz de confianza solo es relevante si necesita validar la cadena de confianza del certificado hasta que obtenga la raíz. Si solo espera un certificado específico o una clave pública, no es necesario verificar ninguna cadena y, en muchos casos, no hay una cadena de confianza de todos modos (es decir, certificados autofirmados).

En caso de revocación, es posible que en realidad agregue una URL al certificado desde donde el cliente puede obtener las CRL o donde también puede enviar consultas de OCSP y, por lo tanto, tener una forma de revocar incluso los certificados anclados. Pero es probable que esto no funcione con certificados autofirmados porque las respuestas OCSP y CRL deben estar firmadas por la CA emisora (o alguna otra CA confiable para este propósito) y en el caso de certificados autofirmados, el certificado de emisores es el que usted desea para verificar el estado de revocación, lo que no tendría sentido.

Es posible que tenga un vistazo a la información OWASP sobre la fijación que viene con ejemplos de código sobre cómo implementar fijando adecuadamente.

    
respondido por el Steffen Ullrich 17.04.2015 - 20:26
fuente

Lea otras preguntas en las etiquetas