La seguridad se refiere a la emisión de certificados comodín a empleados individuales

Question

La seguridad se refiere a la emisión de certificados comodín a empleados individuales

#1 de Kotzu (48 votos)
#2 de a CVn (3 votos)
#3 de Mehrdad (0 votos)
#4 de Kirill Sinitski (0 votos)

15

Recientemente hemos configurado una autoridad de certificación interna de dos niveles. También distribuimos CA raíz a través de Active Directory, por lo que todos los sistemas (Windows) de nuestra red confían en los certificados de nuestra CA interna.

Nuestros desarrolladores necesitan certificados SSL para sus estaciones de trabajo locales. Una opción sería generarles un certificado comodín como *.foo.bar.com .

Los beneficios son la facilidad de implementación y la verificación futura (si creamos nuevos subdominios en el futuro, los cubrirá automáticamente).

Sin embargo, la otra cara es que si emitiéramos un certificado comodín, ¿cómo puede estar seguro de que un empleado malintencionado no lo abusará?

Imagine una situación en la que un desarrollador malintencionado configura un sitio web en su estación de trabajo local (mail.foo.bar.com) y, de alguna manera, puede envenenar también el DNS o modificar el archivo local host de un usuario. Ese certificado de comodín otorga credibilidad a su sitio web malicioso, lo que lo hace parecer más auténtico.

¿Estoy siendo demasiado paranoico? ¿Deberíamos emitir comodines y facilitar el mantenimiento de los certificados o deberíamos generar certificados únicos para cada nombre de DNS para limitar el alcance del uso?

¿Alguien tiene algún pensamiento? ¿Experiencias?

EDITAR

A mi parecer, hay dos soluciones muy buenas publicadas aquí:

Dev / test separado y producción en CA independientes como recomendado por @Kotzu. Para nosotros personalmente No puedo justificar la creación de una segunda CA solo para ese propósito. Es demasiado esfuerzo para la cantidad de certificados que tenemos (40 en total de los cuales 10-20 son dev). Dicho esto, totalmente creo que es la mejor respuesta.
Modifique la estructura de nombres de DNS como recomendado por @immbis para que la parte "dev" del nombre sea el subdominio, no el subdominio. De este modo, hacer el comodín más obviamente un dominio dev. Esto aliviaría mis preocupaciones acerca de la emisión de certificados de comodines en gran medida. Entonces, la suplantación solo puede ocurrir para *.dev.ourdomain.com , con lo que estoy de acuerdo. Dicho esto, simplemente lo hemos codificado en demasiados lugares para que esto sea práctico.

Creo que lo que terminaremos haciendo es continuar emitiendo certificados SSL completos a cada desarrollador. Eso se siente más seguro, ya que deja mucho menos margen de maniobra para que una persona maliciosa abuse o se haga pasar por un recurso legítimo. Toda esta situación es un poco de un caso de colas de todos modos. Espero que nuestros desarrolladores en general no actúen maliciosamente y traten de crear sitios falsos. Es solo que no quiero entregar certificados de comodines de confianza como dulces gratis solo para que luego se puedan usar de una manera inesperada.

Si necesitamos más y más certificados y la emisión de certificados individuales se vuelve inmanejable, consideraremos configurar una segunda CA en la que solo confían las estaciones de trabajo dev (no toda la compañía) y emitir nuevos certificados comodín.

public-key-infrastructure tls wildcard

pregunta Brad 01.06.2017 - 22:21

fuente

4 respuestas

3

Voy a asumir que sus desarrolladores necesitan certificados SSL de confianza local. Como se señaló anteriormente, podría valer la pena considerar si realmente necesitan a esos en primer lugar.

Un certificado comodín se refiere a un certificado con un CN o SAN en la forma *.something.example.com .

El * se expande a una sola etiqueta; no se expande a múltiples etiquetas. Por lo tanto, lo anterior coincidiría con foo.something.example.com ( * expandiéndose a una sola etiqueta) pero no con foo.bar.something.example.com (dos etiquetas) y mucho menos con foo.example.com (etiqueta faltante).

También tenga en cuenta que si recuerdo correctamente, varias etiquetas * están específicamente prohibidas en los campos de certificados SAN y CN. Por lo tanto, no puede crear un certificado válido para, por ejemplo, %código%; eso sería rechazado porque tiene múltiples *.*.something.example.com en un solo nombre. (Creo que este fue uno de los problemas de Stack Exchange con el que se encontraba la empresa cuando trabajaba para configurar HTTPS en toda la red).

Presumiblemente, cada estación de trabajo de desarrollador tiene un nombre diferente. Por lo tanto, es posible que tengas estaciones de trabajo de desarrollador como * , dev033.internal.example.com , o lo que sea.

Por lo tanto, otorgue a cada desarrollador un solo certificado para un solo comodín SAN con el nombre completo de su propio host más el nombre completo de su propio host. Configúrelo para que no se le permita utilizar para firmar otros certificados (certificado en hoja).

Por ejemplo, proporcione al desarrollador que usa dev7g-vm2.example.com un certificado válido solo para solo dev033.internal.example.com y dev033.internal.example.com .

De esa manera, el desarrollador puede configurar alias para su propio host (por ejemplo, *.dev033.internal.example.com y api.dev033.internal.example.com ambos trabajarían con dicho certificado) pero no pueden configurar ningún SSL para nada que no esté bajo su Nombre de host de la propia estación de trabajo. Suponiendo que no exponga web.dev033.internal.example.com a ningún host externo, fuera de su red, el desarrollador tampoco puede hacer nada con el certificado que no pudo hacer con un certificado autofirmado.

Para obtener puntos de bonificación, pero en realidad no es necesario: fírmelos con una CA interna que solo se use para dichos certificados de desarrollo (o prueba, o lo que sea).

respondido por el a CVn 02.06.2017 - 12:00

fuente

0

Dadas sus restricciones, diría que debe configurar un script que use Let's Encrypt (o su propio generador de certificados, lo que sea que funcione) para generar automáticamente cualquier certificado de subdominio solicitado para cualquier desarrollador en su red, con la restricción crítica fuerte> el sufijo del nombre de dominio es obviamente desagradable .

Por ejemplo, permita que cualquiera en su coporación cree subdominios arbitrarios como X-untrustworthy-danger-danger-danger.company.com donde X es lo que quieran (solo ASCII, preferiblemente). Eso debería ser suficiente para realizar pruebas sin engañar a nadie.

respondido por el Mehrdad 02.06.2017 - 13:18

fuente

0

Considere restringir los certificados emitidos a los desarrolladores con el campo extendedKeyUsage a solo lo que sea absolutamente necesario. Si no hay un propósito de autenticación del servidor, se rechazará cuando sea presentado por un servidor web.

También considera usar extensiones. Por ejemplo, la extensión basicConstraints diferenciará entre los certificados que pueden firmar certificados adicionales ( CA:TRUE ) y los que no pueden ( CA:FALSE ). De esta manera, si un empleado malintencionado emite cualquier otro certificado que use su certificado, será rechazado en todas partes que admita esta extensión (por lo tanto, cualquier X509v3).

De esta manera, si tiene un empleado malintencionado con un certificado restringido de la siguiente manera, no podrán abusar de él de tantas formas:

X509v3 Basic Constraints: 
    CA:FALSE
X509v3 Key Usage: 
    Digital Signature, Non Repudiation, Key Encipherment, Data Encipherment, Key Agreement

respondido por el Kirill Sinitski 02.06.2017 - 18:43

fuente

Lea otras preguntas en las etiquetas public-key-infrastructure tls wildcard

Clave firmada de Yubikey / GPG con OpenSSH La contraseña se muestra en la pantalla después de un fallo en Linux, ¿alguna idea de por qué?

score 48 · Accepted Answer

Creo que deberías segregar tu entorno. Solo los certificados de producción deben ser confiables en toda su red. Los certificados de desarrollo y prueba solo deben ser confiables en las computadoras donde trabajan los desarrolladores. En un entorno más seguro, ni siquiera utilizaría la misma CA raíz para los entornos de producción y desarrollo.