¿Qué hay de malo con el intercambio físico de certificados en lugar de un protocolo de enlace?

4

La organización XYZ prefiere no confiar en ninguna CA sino solo en sí misma. Cuenta con un conjunto de certificados que se almacenan físicamente en cada cliente y servidor y que son de confianza solo para su CA de empresa. Todos los navegadores internos están configurados para confiar en esta CA empresarial. Así que, naturalmente, todos los demás sitios web (como Google) no son confiables, como lo indica el navegador.

Todos los demás programas (Java, Node.js, .NET, etc.) mantienen un subconjunto de los certificados necesarios y los utilizan para conectarse entre sí.

¿Qué está mal con esta imagen? ¿Qué argumentos se deben utilizar para convencer a la gerencia de usar la práctica común?

Después de todo lo que dice la administración: confiamos el uno en el otro y aquellos que quieran trabajar con nosotros deben confiar en nosotros. No hay otra forma de comunicarse para nosotros.

Aclaración de la pregunta: Tal vez me equivoque, pero siento que la solución explicada es incorrecta. Simplemente no puedo convencer a la gerencia de que esto está mal y le pedí a la comunidad que me diera algunos argumentos.

Personalmente (teniendo en cuenta las respuestas descritas en el costo adicional) solo veo un problema, ya que todos los sitios externos ya están marcados como no privados / peligrosos. El usuario habitual no prestará atención a dicha advertencia. No se convirtió en una advertencia, pero se sabe que la web es peligrosa y la navegación es su propio riesgo. Lo peor: confiamos solo en la red interna, pero como las computadoras individuales son más vulnerables, cualquier ruptura con cualquier computadora expondrá la red interna completa ya que confía en sí misma.

En realidad, para ser honesto, ese no es mi problema en absoluto. Mi problema es que cuando trato de usar cualquier otro enfoque o programa estándar (como ejemplo, Node.js intenta alcanzar la api interna de la web) dice (como un programa honesto): "certificado autofirmado en la cadena local" y se niega a acceder a esta conexión . Entonces, para mí es una pesadilla (o un costo real) encontrar una solución para cada programa (Node.js, Java, VuGen, QTP, .NET, etc.) obtener certificados y mantenerlos sincronizados.

Mi pregunta es cuáles son los argumentos que puedo usar para convencer a la administración de que esta solución es incorrecta.

    
pregunta Alex 15.12.2016 - 03:43
fuente

3 respuestas

5
  

La organización XYZ prefiere no confiar en ninguna CA, sino solo en sí misma ... Todas   Los navegadores internos están configurados para confiar en esta CA de empresa. Así que, naturalmente,   Todos los demás sitios web (como Google) no son confiables, lo cual es   indicado por el navegador.

     

¿Qué está mal con esta imagen?

Lo que está mal es que la Organización XYZ está utilizando el punto de aplicación incorrecto .

Si no confían en el mundo exterior, deberían eliminar los proxies web salientes y asegurarse de que las reglas del cortafuegos no permitan el acceso saliente en los puertos 80/443.

O podrían implementar un proxy draconiano con TLS MITM que limita el acceso solo a aquellos sitios externos que consideren legítimos. (Y si lo hacen, por supuesto, deberían confiar nuevamente en las autoridades de certificación externas, ya que el proxy está ejecutando el acceso a los sitios aprobados, no en la capa de certificado TLS).

Si la Organización XYZ no está dispuesta a tomar estos pasos, aunque son bastante drásticos, deben reconsiderar seriamente por qué están estigmatizando lo que es, por su propia admisión, un acceso aceptable. Debido a que desconfían de todas las demás entidades emisoras de certificados, colocan los certificados de Validación extendida en el mismo nivel que los certificados Snakeoil autofirmados. Si va a deshacerse de eso, debería bloquear todos los ... Oh, espera, ese fue el paso 1.

    
respondido por el gowenfawr 15.12.2016 - 04:24
fuente
3

En tu pregunta hay dos partes:

¿Es incorrecto utilizar una CA interna dentro de una organización?

Nada está mal aquí, siempre que el proceso de entrega de los certificados sea correcto. Eso supone que los certificados de máquinas solo se establecen en el nivel administrativo adecuado, y solo los administradores los instalan en la máquina y nadie más puede robarlos. Eso también supone que si los certificados se entregan a los empleados o socios, hay cierta información sobre sus usos y el proceso garantiza que solo puedan ser utilizados por la persona correcta.

Ahorra algo de dinero al costo de que los certificados no sean confiables en el mundo externo. Sería problemático para los procesos de Business to Client, pero está bien para intercambios internos o intercambios con un número limitado de socios conocidos

¿Es incorrecto eliminar todos los certificados predeterminados de los navegadores internos?

Es extraño a menos que las máquinas internas no tengan permiso para acceder a Internet global. Si la red interna está físicamente aislada de los accesos a Internet o si un proxy bloquea todo excepto una pequeña cantidad de máquinas, los otros certificados son simplemente inútiles y pueden eliminarse ... incluso si no proporciona seguridad adicional.

Si los empleados pueden acceder a Internet, la eliminación de los certificados puede evitar la instalación automática de complementos firmados por fuentes bien conocidas, pero a costa de un alto número de falsos positivos. El riesgo aquí es instruir a los usuarios para que acepten cualquier certificado nuevo sin siquiera leer el mensaje, lo que puede ser peor. Entonces, en mi humilde opinión, solo tiene sentido si los usuarios no pueden pasar por alto el estado no confiable de los certificados externos.

Pero mientras las máquinas pertenezcan al empleador, él puede elegir qué se puede instalar o no en ellas, y para qué se pueden usar ... incluso si eliminar el certificado predeterminado puede no ser la mejor manera y no puede ser la solución. solo uno.

Límites del certificado privado

El certificado privado está bien para la autenticación o para cifrar intercambios de datos. Por lo general, están perfectamente bien para HTTPS.

Pero no puede usarlos para no rechazar, al menos con tarjetas inteligentes (*). Si emite y entrega un certificado, nunca podrá demostrar que nunca ha guardado una copia de la clave privada. Ningún tribunal legal aceptará eso porque tiene un interés aquí. Esa es la razón por la que el no repudio se valida mejor a través de un tercero emisor .

(*) Como lo dijo @ AndréBorie, esto no se aplica si solo se intercambió un CSR, pero solo si proporciona una tarjeta inteligente

    
respondido por el Serge Ballesta 15.12.2016 - 10:40
fuente
1

Si he leído esto correctamente, diría que lo que está mal es que el personal está perdiendo tiempo aplicando la confianza del certificado manualmente en lugar de dejar que el navegador y las Infraestructuras de Clave Pública externas hagan lo suyo.

Si bien es cierto que el modelo de confianza del certificado está muy dañado, funciona principalmente. Al menos, siempre que necesite que el navegador verifique la validez del certificado & mantenga el navegador parcheado (para que las confianzas de la CA raíz se puedan actualizar rápidamente).

¿Realmente desea confiar en el personal individual para hacer lo que el navegador puede hacer? ¿Qué gastos generales trae eso? Esos gastos generales se traducen en costo , que es la forma en que convencerías a la "administración" para que cambie de opinión.

    
respondido por el Julian Knight 15.12.2016 - 21:38
fuente

Lea otras preguntas en las etiquetas