Una vez que se haya validado un certificado, ¿es seguro hacer coincidir la cadena en el campo del emisor?

2

Primero, algunos antecedentes de la pregunta:

Tengo un dispositivo Pulse Connect Secure VPN en un entorno de múltiples inquilinos, y me han contactado con la tarea de admitir la autenticación de certificados (utilizando tarjetas inteligentes específicamente, pero no creo que los detalles sean relevantes para la pregunta). Cada cliente tiene su propia autoridad de certificación que emite certificados de cliente a los usuarios finales.

Desafortunadamente, en el dispositivo Pulse Connect Secure VPN, solo es posible configurar CA de confianza a nivel mundial para todo el dispositivo. No es posible definir esto en el nivel Servidor de autenticación o en el nivel User Realm .

Esto está bien si no necesita segmentar la confianza para diferentes CA: s dependiendo de a qué clientes atiende, pero realmente no admite muy bien un entorno de múltiples inquilinos.

La amenaza específica contra la que estoy tratando de protegerme es que si la CA de un cliente se ve comprometida, puede emitir certificados de VPN con sujetos que pertenecen a un cliente diferente. Por lo tanto, solo se puede confiar en que la propia CA del cliente firme los certificados de cliente para su propia organización, no los certificados que otorgan acceso a otras organizaciones.

Después de comunicarme con el departamento de soporte de Pulse Secure, me ofrecieron una solución alternativa, en la que configuraría múltiples Reinos de autenticación (cada uno de ellos conectado a una política de inicio de sesión específica y una URL de inicio de sesión específica, que está bien, porque así es como segmentamos a nuestros inquilinos hoy).

La autenticación tendría éxito sin importar qué certificado de cliente se presentara. Cuando se llegó a la etapa de asignación de roles (autorización), se insertaría una regla en la parte superior, que básicamente hace una coincidencia de cadena en el campo "Emisor" de la CA.

La regla sería algo como esta captura de pantalla (esto no se ha probado para que funcione exactamente como está escrito, el nombre del atributo del emisor podría ser incorrecto, etc.):

Lareglaseinsertaráenlapartesuperioryserálaprimerareglaquesecomparará.Coincidiríaconelnombredelemisorenelcertificado,ysinocoincideconelnombredelemisoresperado,noasignarároles,yalmarcarlacasillaDetenerlasreglasdeprocesamientocuandoestareglacoincida,laetapademapeoderolesterminaríasinrolesasignados,yporlotanto,elintentodeiniciodesesiónfallaríadebidoaquenoseasignaronroles.

Mirazonamiento/suposiciones:

EsciertoquelosCA:deconfianzaagregadosaldispositivoPulseConnectSecureseexaminanparacontenernombresduplicadossolosiesosCA:spertenecenalamismaorganización.Estosignificaquesepuedeconfiarenqueelnombredelemisorseaúnicoparaundominiodeconfianzaespecífico.

Tambiénesunhechoquelaasignaciónderolesceroaunusuarioquehapasadolaautenticacióngarantizaquenotendránaccesoaningúnsistemaprotegido.

Cualquierintentodeiniciodesesiónquelleguehastalaasignaciónderoleshapasadolavalidacióndelcertificadoy,porlotanto,es"válido", lo que implicaría que se podría confiar en que el campo del emisor contenga datos válidos. Supongo que un certificado emitido por una autoridad de certificación válida, pero donde el nombre del emisor es diferente de lo esperado fallaría la validación del certificado antes de que llegara a la etapa de asignación de roles.

Por lo tanto, la concordancia de cadenas en el campo del emisor en estas circunstancias debería ser una forma segura de garantizar que solo los certificados emitidos por una CA específica tengan acceso.

Riesgos conocidos:

Durante el inicio de sesión, se envía al cliente una lista de CA válidas con el fin de filtrar su vista de los certificados de inicio de sesión válidos en un proceso conocido como negociación de certificados. Esto puede potencialmente filtrar una lista de clientes que utilizan ese dispositivo en particular, así como causar un problema de usabilidad para los usuarios que forman parte de varias organizaciones. En vista de no tener una forma alternativa de resolver esto, encuentro que este riesgo es manejable.

Límite del alcance:

Me gustaría dirigir esta pregunta solo a la seguridad de autenticación y autorización, en lugar de preguntas más amplias de diseño de red detrás del dispositivo VPN.

Mi pregunta:

Entonces, después de explicar todos estos antecedentes, creo que mi pregunta en la línea de asunto tiene más sentido:

  

Una vez que se haya validado un certificado, ¿es seguro que coincida con una cadena en el campo del emisor?

(¿O va a morderme el culo de alguna manera que no había considerado)?

    
pregunta Per von Zweigbergk 04.07.2018 - 14:49
fuente

1 respuesta

5

Si considera que la CA está comprometida, la CA también puede emitir certificados intermedios con el tema de la CA intermedia igual o similar al de una CA raíz en la que confía. Esta CA intermedia "mimikri" se puede usar para emitir el certificado de hoja, a menos que la CA raíz tenga un conjunto de rutas de acceso que lo prohíba y que la ruta de acceso se verifique en la aplicación.

Luego, el cliente puede autenticarse con el certificado de hoja más el certificado intermedio de mimikri y la autenticación se aceptará ya que en última instancia, el certificado de hoja es (indirectamente) emitido por una CA de confianza. Pero si luego se verifica el emisor del certificado de hoja, verá los datos falsos del emisor.

O como una imagen:

   compromised CA "Bad"                trusted CA "Good"
        |                                    |
   intermediate CA "Good"              real good leaf certificate
   issuer "Bad"                        issuer "Good"
        |
   fake good leaf cert
   issuer "Good"                   

Si necesita distinguir qué CA raíz se utilizó para crear el certificado hoja, debe verificar el asunto de la CA raíz y no el emisor del certificado hoja. No tengo idea si la aplicación específica lo admite.

    
respondido por el Steffen Ullrich 04.07.2018 - 15:07
fuente

Lea otras preguntas en las etiquetas