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.