SSL mutuo (CCA) con TLS 1.x: ¿cómo selecciona el cliente el certificado apropiado y envía el certificado único o en cadena?

1

Tenemos una interesante discusión entre el equipo del operador del servidor y los desarrolladores de una aplicación cliente.

Nuestra configuración en general es así: Hay una raíz-ca, llamémosla "raíz-1". Esto tiene un sub-ca, llamémoslo "sub-1". Ambos están contenidos en el almacén de confianza del servidor. El cliente tiene un almacén de claves / confianza combinado (es decir, el mismo archivo de almacenamiento de claves), que contiene la cadena de ca mencionada anteriormente y un certificado de cliente emitido por sub-1. Llamemos a esto "cliente-1".

Durante el protocolo de enlace TLS, el servidor envía un mensaje de solicitud de certificado, que contiene una lista de DN confiables (porque están en el almacén de confianza), es decir ["root-1", "sub-1"].

El cliente comprueba la lista, reconoce que tiene un certificado emitido por "sub-1" y lo envía como una lista de certificados con una sola entrada: el certificado del cliente.

Los operadores del servidor están indicando que el cliente debe enviar toda la cadena de certificados, pero puede omitir la raíz-ca. Básicamente, les gusta eliminar "sub-1" de su almacén de confianza para que el servidor solo solicite "root-1". El cliente debe encontrar el "cliente-1" emitido por "sub-1" que se emite por "root-1" y luego enviar toda la cadena de certificados.

Los desarrolladores del cliente están indicando que esto es una violación de la seguridad o es al menos menos seguro que la solución actual. Dicen que parece que el servidor validará el certificado del cliente de nuevo en la cadena de confianza que el cliente ha enviado por sí mismo.

Desde mi punto de vista, hay dos preguntas que resultan de esta discusión: 1. Si el servidor solo solicita "root-1", ¿debe el cliente encontrar "client-1" como certificado apropiado y usarlo para la comunicación? 2. Si la respuesta a la primera pregunta sería sí, ¿debería el cliente enviar la cadena de certificados, es decir, [cliente-1, sub-1] (omitiendo la raíz ca según rfc)?

El RFC 5246 podría estar un poco borroso en esa sección:

7.4.6.  Client Certificate
[...]
Client certificates are sent using the Certificate structure
      defined in Section 7.4.2.

Y la sección 7.4.2 dice:

    7.4.2.  Server Certificate
[...]
   Structure of this message:

      opaque ASN.1Cert<1..2^24-1>;

      struct {
          ASN.1Cert certificate_list<0..2^24-1>;
      } Certificate;

   certificate_list
      This is a sequence (chain) of certificates.  The sender's
      certificate MUST come first in the list.  Each following
      certificate MUST directly certify the one preceding it.  Because
      certificate validation requires that root keys be distributed
      independently, the self-signed certificate that specifies the root
      certificate authority MAY be omitted from the chain, under the
      assumption that the remote end must already possess it in order to
      validate it in any case.

El desarrollador del cliente ahora está interpretando esta sección de esta manera:

Each following certificate MUST directly certify the one preceding it.

Esto significa que no DEBE haber un certificado después del "certificado de remitente", es decir, el certificado del cliente. Debido a que la misma estructura se usa para el servidor y el certificado del cliente, la lista de certificados tiene una longitud de 0..2 ^ 24-1. Esto significa que la lista es válida con 0, 1 o varias entradas.

Mi pensamiento sobre eso es este:

  • si el servidor no tiene "sub-1" en su almacén de confianza, usará la ca que el cliente está enviando para validación, lo que me suena menos seguro. Un atacante podría producir un "sub-2" válido de alguna manera, luego crear un certificado de cliente usando "sub-2", enviar la cadena y se autenticará.
  • Una lista de revocaciones para las AC no funcionará entonces, porque se desconoce el "sub-2" caudo no autorizado
  • ¿Cuál es la ventaja de tener solo la raíz-ca en el almacén de confianza del servidor y que un cliente envíe toda la cadena de certificados?

Información adicional: el cliente también es un middleware, por lo que no hay posibilidad de interacción por parte del usuario.

Los desarrolladores del cliente temen que el procesamiento previsto por los operadores del servidor genere serios problemas de seguridad, que de otro modo se evitarían fácilmente. Para ellos no tiene sentido enviar el sub-ca junto con el certificado del cliente, ya que el servidor debería CONFIANZA el sub-ca. Es por eso que el sub-ca debe residir en el almacén de confianza del servidor.

Los operadores del servidor están diciendo que sería de gran esfuerzo mantener siempre un conjunto de sub-cas válidos en el almacén de confianza de su servidor, porque puede haber sub-cas nuevos que se presenten, sin su conocimiento o atención. Además, dicen, el comportamiento del cliente no es compatible con TLS 1.2 y se les insta a usar TLS 1.2.

Pero no puedo encontrar ninguna diferencia en el área CCA (Autenticación de certificado de cliente) entre TLS 1.0 y TLS 1.2. Es el mismo texto allí.

Apreciaré cualquier aclaración de este problema por parte de cualquiera de los expertos en seguridad aquí.

  • ¿Cómo mantienes escenarios similares en tus proyectos? Al implementar clientes compatibles con TLS 1.2, ¿está enviando la cadena de certificados o un solo certificado?
  • ¿Pones el sub-cas en el almacén de confianza de tu servidor o no? ¿Y por qué?

Lo siento por el extenso texto, pero creo que esta es una situación difícil y debe explicarse en detalle. Además, creo que rfc 5246 es confuso en el aspecto de cómo se realizará exactamente el protocolo de enlace SSL mutuo.

    
pregunta Rambler 30.03.2017 - 15:51
fuente

1 respuesta

2
  

Dicen que parece que el servidor validará el certificado del cliente contra la cadena de confianza que el cliente ha enviado por sí mismo.

La validación correcta del certificado nunca se basa completamente en los certificados enviados por el par, pero siempre implica un ancla de confianza local . Esto es cierto para los certificados de cliente y servidor.

Por lo tanto, existen las siguientes posibilidades:

  • El servidor envía root-1 como CA aceptado: el cliente envía client-1 y también sub-1 para que el servidor pueda crear una ruta de confianza al root-1 de confianza local.
  • El servidor envía el sub-1 como CA aceptado: el cliente envía el cliente-1 y el servidor crea una ruta de confianza utilizando el sub-1 conocido localmente al root-1 de confianza local.
  • Si el servidor envía tanto el sub-1 como el root-1 como de confianza, el cliente podría enviar el cliente-1 o el cliente-1 combinado con el sub-1.

Lo importante en todos estos casos es que el final de la cadena de confianza es siempre un certificado de confianza local. Si el cliente también envía root-1, este certificado generalmente se ignorará, pero algunas implementaciones también pueden generar un error, ya que se supone que el cliente no debe enviar el certificado raíz.

    
respondido por el Steffen Ullrich 30.03.2017 - 17:31
fuente

Lea otras preguntas en las etiquetas