Tengo un producto de escritorio que utiliza un servidor web incorporado que utilizará certificados autofirmados.

¿Hay algo que pueda poner en una página web que detecte que no han agregado la CA raíz a su lista de confianza y muestre un enlace o DIV o algo que les indique cómo hacerlo?

Estoy pensando que tal vez un DIV que tenga instrucciones para instalar la CA y un Javascript que ejecute alguna prueba (¿intenta acceder a algo sin advertencias internas?), Y oculta el DIV si la prueba tiene éxito. O algo así...

¿Alguna idea de la brillante comunidad SO? :)

4
DougN 18 may. 2009 a las 18:05

9 respuestas

La mejor respuesta

¿Por qué quieres hacer esto? Es una mala idea capacitar a los usuarios para instalar indiscriminadamente certificados raíz de CA solo porque un sitio web les dice que lo hagan. Estás socavando toda la cadena de confianza. Un usuario consciente de la seguridad ignoraría sus consejos para instalar el certificado y podría concluir que no se está tomando en serio la seguridad ya que no se molestó en adquirir un certificado de una CA existente.

¿Realmente necesitas HTTPS? Si es así, probablemente debería morder la viñeta y hacer un trato con una CA para facilitarles a sus clientes los certificados de servidor firmados de CA adecuados. Si el servidor web solo se usa para conexiones locales desde la aplicación de escritorio, debe agregar el certificado autofirmado a la lista de confianza como parte del proceso de instalación o cambiar a HTTP.

10
markusk 22 may. 2009 a las 17:55

Un control ActiveX podría hacer el truco. Pero realmente no intervino para ayudar con la solución, más para estar en desacuerdo con la postura de que lo que está haciendo es un riesgo de seguridad.

Para ser claros, necesita un cifrado seguro (con suerte AES y no DES), y ya tiene el control de sus puntos finales, simplemente no puede descartar por completo los rastreadores de red de modo promiscuo que podrían atrapar contraseñas de texto claro u otros datos confidenciales .

SSL es una "capa de conexión segura" y, por definición, NO depende de NINGÚN certificado.

Sin embargo, todos los cifrados modernos efectivos requieren que autentique los puntos finales del túnel, lo que no siempre es una necesidad para todas las aplicaciones; una frustración con la que me he ocupado en numerosas rutinas de automatización de centros de datos de back-end que utilizan API de servicios web para administrar nodos, donde los "usuarios" eran en realidad procesos que necesitaban un intercambio de claves cifradas antes de una negociación de comando RESTful.

En mi caso, las VLAN estaban protegidas mediante ACL, por lo que realmente "podía" enviar encabezados de autenticación de texto sin cifrar. Pero solo escribir eso me hizo vomitar un poco en mi boca.

Estoy seguro de que me criticarán por escribir esto, pero estoy extremadamente endurecido por la batalla y te hubiera hecho los mismos comentarios en los años 10-15 de mi carrera en TI. Así que empatizo con sus preocupaciones y aprecio mucho si les apasiona lo suficiente la seguridad como para quemarme. Eventualmente lo resolverán .....

Pero sí estoy de acuerdo con el hecho de que es una MALA idea "capacitar" a los usuarios para que instalen CA raíz por su cuenta. Por otro lado, si usa un certificado autofirmado, debe capacitarlos para instalarlo. Y si un usuario no sabe cómo determinar si un CA Cert es confiable, definitivamente no podrá determinar un certificado autofirmado de un CA Cert y, por lo tanto, cualquiera de los procesos tendría el mismo efecto.

Si fuera yo, automatizaría el proceso en lugar de hacerlo ayudar a los usuarios finales, de modo que quede lo más oculto posible, tal como lo haría una PKI adecuada para una empresa.

Hablando de eso, solo pensé en una posible solución. Utilice el modelo PKI de Microsoft. Con Server 2012 R2, puede entregar claves confiables a puntos finales que ni siquiera son miembros del dominio que usan "control de dispositivo" a través de "espacios de trabajo", y las máquinas cliente pueden suscribirse a múltiples espacios de trabajo, por lo que no se comprometen únicamente con el suyo si se suscriben. Una vez que lo hagan y se autentiquen, el rol de Servicios de certificados de AD empujará todos los certificados raíz de CA necesarios, tal como están presentes en el directorio activo o en el servidor LDAP especificado. (En caso de que esté utilizando servidores de CA sin conexión)

Además, me doy cuenta de que este hilo tiene como 7 años, pero estoy seguro de que todavía es referenciado por un buen número de personas que necesitan soluciones similares, y me sentí obligado a compartir una opinión contrastante. (Ok Microsoft, ¿dónde está mi soborno por el enchufe que te di?)

-hombre de dinero en efectivo

0
Chris Cashman 16 mar. 2016 a las 12:07

La única idea que tengo es usar marcos y algunos javascript.

El primer elemento del marco actuará como un perro guardián que espera x cantidad de tiempo (javascript setTimeout) antes de mostrar su mensaje de falla de SSL personalizado al usuario con hipervínculos o instrucciones para descargar el certificado autofirmado.

El segundo elemento de trama intenta la conexión https y, si tiene éxito, restablece la trama de vigilancia para que nunca se active. Si falla (suponga que falló la validación del certificado https), el mensaje de vigilancia se disparará y se presentará al usuario.

Dependiendo de su navegador, lo más probable es que aún vea algunas advertencias de seguridad con el enfoque, pero al menos podrá empujar su propio contenido sin requerir que los usuarios ejecuten código no confiable sin una cadena de confianza adecuada (Esto sería mucho peor por una seguridad POV que aceptar los errores de validación del certificado y establecer una sesión SSL no confiable)

Las mejoras al concepto pueden ser posibles utilizando otros métodos de prueba como XMLHttpRequest et al.

2
Einstein 20 may. 2009 a las 05:45

Puede intentar agregar un elemento Flex (oculto) o un Applet Java una vez por sesión de usuario. Simplemente descargará cualquier página https de su servidor y obtendrá toda la información sobre la conexión:

com.sun.deploy.security.CertificateHostnameVerifier.verify()
or
javax.security.cert.X509Certificate.checkValidity()

Supongo que Flex (que es más común para los usuarios) debería tener formas similares de validar el certificado https desde el punto de vista del usuario. También debe compartir el certificado de confianza del sistema operativo. almacenar mientras que Java podría tener el suyo.

0
Alexander Kosenkov 21 may. 2009 a las 22:00

En resumen: está configurando servidores web en aplicaciones de escritorio; cada computadora de escritorio tendrá su propio servidor web, pero desea usar SSL para asegurar la conexión a ese servidor web.

Supongo que aquí hay varios problemas con los certificados, uno de los cuales es que el nombre de host utilizado para acceder al escritorio debe coincidir con el certificado. En este caso, tiene pocas opciones más que generar certificados en el cliente. Deberá permitirle al usuario alguna forma de especificar el nombre del host en caso de que el nombre utilizado por personas externas no pueda detectarse desde el host.

También sugeriría permitir que un administrador instale un certificado de confianza, para aquellos que no quieren confiar en certificados autofirmados. De esta forma, también puede descargar el costo del mantenimiento de certificados de confianza a los administradores que realmente lo deseen.

Finalmente, en mi experiencia, los navegadores permiten o rechazan el certificado autofirmado y no hay forma de que el servidor sepa si el certificado es denegado, o aceptado temporalmente o aceptado de forma permanente. Supongo que debe haber un mecanismo en algún lugar para manejar las fallas SSL, pero la programación web típica no funciona en esa capa. En cualquier caso, lo único que puede hacer un servidor web si falla SSL es recurrir a no SSL, y usted ha indicado en un comentario que no puede tener nada que no sea SSL. Creo que deberías tratar de eliminar esa restricción; una página de inicio que no sea SSL sería extremadamente útil en esta situación: puede probar (usando marcos o imágenes o JSON o AJAX) la conexión https, y puede vincular a la documentación sobre cómo configurar el certificado o dónde descargar un instalador para el cert.

Si el navegador no se conecta debido a un certificado autofirmado y no se le permite usar HTTP simple, ¿de qué otro modo podría comunicarse con el usuario? No hay otros canales y no puede establecer uno porque no tiene ninguna comunicación.

Usted mencionó en un comentario escribir una aplicación win32 para instalar el certificado. Puede instalar un certificado en el momento en que instala la aplicación, pero eso no ayuda a ningún navegador remoto, y un navegador local no necesita SSL para acceder a localhost.

0
Mr. Shiny and New 安宇 25 may. 2009 a las 14:28

Suponiendo que conoce C # y desea instalar un archivo pfx. Cree un exe que se ejecutará desde una url. Siga esta URL

2
abmv 18 may. 2009 a las 14:12

No deberías hacer esto. Los certificados raíz no son algo que simplemente instala, ya que agregar uno podría comprometer la seguridad que le brinda https.

Sin embargo, si está creando una aplicación de escritorio, solo escuche 127.0.0.1. De esa manera, el tráfico nunca sale de la computadora del usuario y ningún atacante puede escucharlo.

2
tomjen 23 may. 2009 a las 09:50

Dado que el servidor se está ejecutando en la máquina cliente (producto de escritorio), ¿no puede verificar los navegadores compatibles para ver si hay certificados instalados utilizando las funciones de winapi / os? Sé que Firefox tiene una base de datos cert en el directorio de perfil del usuario e IE probablemente guarda información en el registro. No sería confiable para todos los navegadores, pero si el servidor simplemente elige entre "Certificado encontrado" y "Por favor, asegúrese de haber instalado el certificado antes de continuar", entonces no se hace daño ya que el usuario puede elegir continuar de cualquier manera.

También podría simplificar las cosas al proporcionar un navegador incrustado (es decir, gecko), de esta manera solo tiene que lidiar con un navegador que simplifica muchas cosas (incluida la preinstalación de la CA raíz).

0
SpliFF 24 may. 2009 a las 13:40

Hemos estado trabajando en un proyecto JavaScript de código abierto, llamado Forge, que está relacionado con este problema. ¿Tiene un sitio web al que sus usuarios puedan acceder? Si es así, puede proporcionar una conexión segura a esas aplicaciones de escritorio a través de su sitio web utilizando una combinación de Flash para dominios cruzados + JavaScript para TLS. Será necesario que implemente algunos servicios web en su sitio web para manejar los certificados de firma de los certificados de la aplicación de escritorio (o que sus aplicaciones de escritorio carguen los certificados autofirmados para que se pueda acceder a ellos a través de JavaScript). Describimos cómo funciona aquí:

http://blog.digitalbazaar.com/2010/07/20/javascript-tls-1/

Una alternativa a la configuración de un sitio web, pero es menos segura porque permite un ataque MiTM es alojar el JavaScript + Flash directamente en el servidor de la aplicación de escritorio. Puede hacer que sus usuarios accedan a su aplicación de escritorio a través de http regular para descargar el certificado JS + Flash + SSL, pero luego comiencen a usar TLS luego a través del JS. Si tiene una conexión de host local, el ataque MiTM puede ser un poco menos preocupante, tal vez lo suficiente para que considere esta opción.

0
dlongley 22 jul. 2010 a las 15:48