Quiero certificados SMIME de confianza para terceros. ¿Es esta una configuración razonable?

9

Quiero enviar certificados SMIME con mis correos electrónicos y quiero implementar la siguiente PKI

Root01  (All EKU, All Constrants, No Restrictions)

PolicyInt01 (Internal applications, not trusted by 3rd parties...)
PolicyExt01 (Name constraints = domain.com, EKU=Message signing) 

IssueExt01 (Issues certificates for PolicyExt01)

Mi intención es pedir a las partes externas que confíen en PolicyExt01 y lo agreguen al almacén raíz de confianza. Dado que está restringido y limitado en su uso, creo que la mayoría de los terceros inteligentes no tendrían problemas con esto.

Pregunta

  • ¿Es esta una configuración aceptable para implementar certificados SMIME de confianza fuera de nuestra organización?

  • ¿Qué cambios haría para usted, usted mismo como administrador de seguridad, para este proceso?

  • ¿Existe algún riesgo de que este certificado pkipolext01 coteje / encadene otro certificado, causando una escalada inesperada de los derechos? (restricciones de nombre / EKU)

pregunta random65537 02.03.2015 - 19:22
fuente

2 respuestas

4

Recomendaría el uso de una raíz completamente separada para los certificados externos e internos, para evitar cualquier fuga de información sobre hosts o usuarios internos, a través de Root01, pero también para evitar cualquier confianza implícita por parte del software dañado. Al utilizar 2 raíces separadas para uso externo e interno, no es posible que ninguna confianza se filtre de los certificados Externos a los Internos, sin importar qué tan roto esté el software.

Normalmente, si tenemos rutas de certificación que se parecen a esto:

Root01 --> SubCA01 -> Cert01
Root01 --> SubCA02 -> Cert02

Y SubCA02 se importa como de confianza. En una implementación de PKI válida, Cert01 no debe ser confiable. Pero como sabe, con la codificación perezosa, el software defectuoso y el análisis intrépido de certificados, es posible que la confianza se filtre desde el subCA02 a Root01 y, por lo tanto, la filtración haga que Cert01 sea confiado por alguien que no debería confiar en ese cert, si el La implementación de PKI está muy rota y, por ejemplo, asume que cualquier certificado superior es de confianza automática. Sí, es muy inverosímil, pero es mejor tener en cuenta cualquier software dañado utilizando en su lugar raíces completamente separadas.

También agregaría una restricción básica PathLength = 0, lo que evitaría que el certificado de CA se use para firmar otros certificados de CA, además de la restricción de nombre.

Como sabrá, hay muchos programas defectuosos y un ataque de escalada de privilegios (como lo llama cuando alguien logra firmar un certificado que infringe las restricciones), por ejemplo, si dicho certificado PolicyExt01 se utiliza para firmar una CA subordinada, que a su vez está firmando un certificado S / MIME.

Algunos programas defectuosos solo comprueban, por ejemplo, las restricciones de nombres "1 nivel Profundo", y agregar una restricción de Pathlength causaría que las cadenas más largas fallaran en lugar de ser aceptadas como confiables.

Entonces me gustaría hacer esto:

Root01 (Name constraints = [email protected], PathlenConstraint=0, EKU=Message signing)
Root02 (Internal applications, not trusted by 3rd parties...)

Y luego compartir el certificado Root01 con aquellos terceros que deberían confiar en él, mientras instala tanto Root01 como Root02 en todas las computadoras internas de la Compañía.

Root01 y Root02 son certificados de CA raíz autofirmados.

Al usar Namingconstraint, solo pondría una restricción de nombre de Email@@domain.com, y luego pondré todas las demás restricciones de nombre (IP, DNS, UPN, URI) como comodín excluido, para evitar que se use un certificado como para por ejemplo, un certificado SSL de un sitio web, si un navegador o una implementación de SSL no puede analizar las marcas de uso clave.

Una buena idea también es probar su configuración, preferiblemente exportando el certificado de CA raíz y la clave privada a una computadora segura fuera de línea, y luego intentar firmar certificados "inválidos" con esto. Luego pruebe los certificados "inválidos" con el software cliente común para asegurarse de que las restricciones están activando y marcando el certificado como no confiable.

Personalmente, no conozco ninguna configuración explícita que pueda causar un ataque de "escalada de privilegios", pero, como usted sabe, hay muchas implementaciones SSL rotas y software PKI, por lo que es mejor prevenir que curar y restringir los certificados como tanto como sea posible, y también use raíces separadas para evitar cualquier pérdida de confianza entre los certificados por el software MUY roto.

    
respondido por el sebastian nielsen 10.03.2015 - 04:06
fuente
0

El propósito de los certificados S / MIME es firmar y cifrar mensajes de correo electrónico. Dado su caso de uso, lo que está proponiendo no es apropiado. Para el correo electrónico, desea que los destinatarios puedan verificar los mensajes de correo electrónico sin tener que descargar e instalar la clave raíz de su organización. Por lo tanto, para el correo electrónico, realmente desea utilizar certificados emitidos por un proveedor de certificados S / MIME reconocido mundialmente, como Comodo, VeriSign o StartCom. Puede emitir estos certificados en el sitio si compra el sistema apropiado de estos proveedores.

Si sus usuarios de confianza han eliminado todos sus certificados de sus almacenes raíz, puede, por supuesto, proporcionarles su propio certificado raíz y establecer el alcance tal como lo ha descrito. Sin embargo, una vez más, no es necesario tener una PKI separada para uso interno y externo. Será casi imposible de administrar, y no hay seguridad adicional al hacerlo. Solo usa una sola raíz.

    
respondido por el vy32 31.10.2015 - 05:06
fuente

Lea otras preguntas en las etiquetas