Sin revelar DEMASIADA información, necesito configurar un servidor web sistema que está destinado a ser utilizado por los usuarios finales en todo el internet.

el caso de uso es tal que:

  • los usuarios finales (por lo general) en sus casas detrás de su cortafuegos locales para la conexión al sistema.
  • El sistema consta de un servidor remoto alojado por nosotros, estrictamente a través de https (con SSL)
  • El mecanismo de autorización requiere que el usuario de la cuenta de la auto-creación en el servidor remoto que, tras la exitosa creación de la cuenta, por lo tanto, requieren de una pieza de software para ser descargado e instalado en el extremo del ordenador de los usuarios. Este software contiene, entre otras cosas, un servidor web local.
  • Este «local» web también debe permitir sólo las conexiones https en el navegador del usuario.

Desde el software distribuido será un servidor web único en cada individuo de los usuarios de la máquina, estoy seguro de cómo, o incluso si es posible, para obtener un TERCERO FIRMADO certificado SSL que no causa la confiabilidad de errores cuando el usuario se conecta a través del navegador web. Claro que se puede usar SSL auto-firmado certs, pero la idea es evitar las advertencias del navegador, de modo que los usuarios finales implícitamente la «confianza» de los datos provenientes de su propia aplicación que se ejecuta en su servidor web a través de SSL.

Es esto posible?

  • De interés, ¿por qué la conexión con el servidor local, escuchando sólo en 127.0.0.1, deben ser a través de SSL? Quién es el hombre en el medio va a ser?
  • Alice decide que Bob el servidor web recibe información valiosa y así mata el proceso del servidor web y se inserta su propia para tomar su lugar. Ahora Alice recibe nombre de usuario/contraseña, etc.
  • Donde hizo Alice obtener la contraseña de root para matar el proceso del servidor web desde? Y ¿por qué molestarse matar el proceso del servidor web cuando se puede simplemente instalar un registrador de teclas?
  • La pregunta es un poco confuso, así que he creado mi propia pretender escenario: que yo había imaginado el escenario como el diseñador del software que está siendo paranoico de otras aplicaciones en ejecución en la máquina. Con el fin de evitar que otra aplicación de desfilar como su aplicación para el usuario final que quiere certificado SSL de validación. Ahora, su aplicación tiene el servidor de la web así como de otras cosas que pueden obtener información de otros lugares/control de otras cosas y él no quiere que el usuario sea engañado con un falso interfaz de usuario que hace otras cosas como recoger información y retransmitirla en otros lugares.
  • si el sitio web remoto intenta acceder a la página web a continuación, usted será bloqueado si sirve mezclado el contenido está bloqueado.
  • También, tenga en cuenta que localhost compartir cookies, localstorage, etc entre todas las aplicaciones, incluso en puertos diferentes. Para este caso de uso lo que realmente queremos hacer es tener localhost.yourthingmabob.com y el conjunto de la caché DNS del tiempo a los años en lugar de minutos, días u horas.
  • Si ya la instalación de software en los ordenadores de otras personas, entonces ¿por qué no acaba de instalar también cert en la raíz de confianza repositorio?
  • (También, este sistema podría ser objeto de abuso por los chicos malos. Por ejemplo, podría ser utilizado para colarse bot software en un sistema y permitir que el C&C para comunicarse con el zombie través de una conexión cifrada.)

InformationsquelleAutor Rimer | 2011-07-22

5 Comentarios

  1. 2

    Probablemente nos puede hacer de esta oferta de GlobalSign (otros CAs ofrecen servicios similares). En breve, el ofrecimiento que le permite disponer de un certificado de CA (e inscribir los certificados de usuario final para localhost /lo que sea ) que será firmada por GlobalSign certificado. El costo puede ser significativos, aunque (creo que se determinan sobre la base de caso por caso).

    • ¿Significa esto que debo crear mi propia CA en orden para que esto funcione?
    • Con el fin de evitar un navegador de advertencia en el lado del cliente, que necesita para construir un certificado de confianza de la cadena, es decir, el certificado utilizado en la web implementados en el servidor (el que se ejecuta en el lado del cliente) debe ser firmado con el certificado de la CA que en vez de debe ser de confianza por el navegador o ser firmado por una CA de confianza. Esto es lo que GlobalSign y otros conocidos CAs ofrecer. Ahora usted no necesita crear una CA – si usted ha construido una compleja aplicación, agregar la generación de certificados para el servidor requiere 15 minutos de codificación.
    • Supongo que mi pregunta entonces es, ¿es posible obtener una CA de confianza para FIRMAR un certificado para un servidor que se tendrá acceso en «127.0.0.1» o «localhost» ?
    • Supongo que no, usted debe convertirse en una CA de confianza de sí mismo (es decir, obtener un certificado especial de un conocido de CA como se discutió anteriormente) y, a continuación, emitir los certificados y realizar la revocación del certificado de gestión.
    • pensar acerca de este enigma interesante: dicen que usted obtenga una CA de confianza para firmar el cert para localhost. ¿Qué sucede si un atacante podría entonces tomar su firmó cert para las víctimas de la computadora?
  2. 24

    localhost

    Que nunca se emitió una adecuada https cert para localhost. Es estrictamente prohibido. Porque razones.

    En resumen:

    • Mal configurado los dispositivos realmente existen, en la naturaleza, que se espera para las búsquedas antes de resolver localhost de /etc/hosts
    • Si un router define localhost.foo.local puede causar localhost para resolver de forma incorrecta (usted probablemente ha visto que esta clase de error antes)

    Puede crear un certificado raíz y luego crear lo que llaman «firmados» certificado firmado por la ca raíz que ha creado. Usted todavía tiene la fea la pantalla de advertencia, pero lo hará.

    localhost.YOURSITE.com (puntos a 127.0.0.1)

    En lugar de la real localhost certs, yo hago lo que Eugene sugiere crear un 127.0.0.1 registro de un dominio público.

    Usted puede obtener gratuitamente los certificados HTTPS para localhost.YOURSITE.com a través de Vamos a Cifrar a través de https://greenlock.domains. Sólo tienes que elegir la opción DNS en lugar de la Carga de Archivo HTTP opción

    Punto de tu localhost.MI-SLD.MI-TLD a 127.0.0.1

    • La compra de un *.localhost.example.com cert y el número de cada instalación un secreto xyz.localhost.example.com (e incluir en el público lista de sufijos para prevenir los ataques contra example.com)
    • Uso un greenlock-aplicación habilitada para generar este tipo de certificados sobre la marcha (a través de https://letsencrypt.org) directamente en el cliente (o se pasan al cliente)

    Si no se incluirán en el PSL tenga en cuenta que:

    • sesiones, localstorage, indexeddb, etc, que son compartidos por dominio
    • cambiar el puerto no cambia su sharedness

    Ser Su Propio Certificado Raíz

    Actualización: con cosas como greenlock que use ACME /Vamos a Cifrar, este no es especialmente relevante.

    Esta es probablemente una mala idea porque no queremos que los usuarios se habitúen a la instalación de ca Raíz queramos o no (y sabemos lo que resultó para Lenovo), pero para las empresas o clonar máquinas puede ser razonable bajo la opción de presupuesto.

    • Impresionante! Me ayudará a prueba la viabilidad de mi proyecto antes de registrar mi propio certificado, muchísimas gracias!
    • Sólo recuerde que localhost.daplie.com se han compartido las cookies, localStorage, indexeddb, etc, entre todos los que lo usan, por lo que finalmente quiere conseguir su propio.
    • Estoy un poco preocupado por un usuario malintencionado se tiene la capacidad para revocar certificados por conocer la clave privada, véase: letsencrypt.github.io/acme-spec/… no estoy seguro de si «antes de la clave» se refiere a la cuenta de la clave privada o el certificado de la clave privada (que para localhost.daplie.com está disponible públicamente)
    • Usted debe estar mucho más preocupados por un usuario malintencionado suplantación de DNS y la dirección de su ‘localhost’ tráfico a un lugar que no está. Esto no es una solución de producción (ver los enlaces acerca de por qué es prohibido). También, Greenlock (ACME / Vamos a Cifrar) ahora soporta dns-01 desafíos de modo que usted puede obtener su propio certificado sin claves privadas expuestas queramos o no.
    • MITM es una posibilidad con la consulta DNS respuesta de suplantación de identidad de sí, a pesar de que puede ser mitigado con DNSSEC. Pero un ataque MITM sólo afectaría a una dirigidos víctima, mientras que un usuario malintencionado revocar el certificado de localhost.daplie.me gustaría ser capaz de hacer caer potencialmente cientos de aplicaciones y todos sus usuarios finales, si logró ser revocada por el «estado de la tecla» mecanismo.
    • El localhost.daplie.me certificados de no trabajar en junio de 2017 (macos, chrome)

  3. 15

    Yo tenía este mismo requisito. Así que la razón por la que usted tiene que usar SSL es porque casi todos los navegadores ahora barfs si se utiliza https e intenta conectarse a un recurso http incluso si el recurso http es en localhost que es tonto para mí.

    Porque de JS SOP nuestro localhost servidor web sirve un archivo js y luego el JS dentro de la webapp puede hacer llamadas a este localhost servidor web.

    Lo que hemos hecho local.example.com punto a 127.0.0.1 y en realidad compró un certificado SSL para este nombre de host. Entonces nosotros enviamos la clave privada en el interior de este servidor web que se instala en el ordenador del usuario. Sí, estamos locos.

    Todo esto en realidad funciona bastante bien. Estamos estado corriendo como este con un par de cientos de usuarios alrededor de 6 meses.

    El único problema que a veces es que esto no funciona bien cuando un usuario está utilizando un servidor proxy. Las solicitudes se envían al servidor proxy y se intenta conectarse a 127.0.0.1 en el servidor proxy que, obviamente, no funciona. La solución es agregar una exclusión para el proxy server config para que omite el servidor proxy para las solicitudes de local.example.com

    Otro escenario donde se hará un poco complicado es cuando los usuarios intentan utilizar Citrix o Terminal Services. Usted tiene que asegurarse de que el servidor web para cada usuario se está ejecutando en un puerto diferente y, a continuación, informe a su servidor web remoto del número de puerto para que las páginas generadas por el servidor tendrá el derecho de número de puerto. Afortunadamente no hemos tenido todavía. También parece que más personas están usando máquinas virtuales en estos días en lugar de Citrix.

    ¿Alguna vez encontrar una mejor manera?

    • Esta es una excelente idea (registro DNS apuntando a 127.0.0.1). Aunque es un poco hackish para incluir su clave/cert con la app, creo que esta es casi la única manera de ir. ¿Cómo lidiar con vencimiento? Tiene la descarga de la aplicación de un nuevo cert?
    • Estoy de acuerdo, parece de locos paquete de la clave privada con la aplicación. Simplemente no usar este certificado en un servidor real en algún otro lugar y está muy bien. Nuestra aplicación es una aplicación SAAS así que siempre estamos liberando las actualizaciones. Utiliza la aplicación Java Web Start, de modo que se actualiza automáticamente. Usted también puede conseguir un certificado SSL para $5 por año en estos días así que acaba de obtener uno de 5 años y usted no tiene que preocuparse acerca de esto por un tiempo.
    • Tengo exactamente el mismo problema. Me pregunto si hay implicaciones de seguridad de decisiones de la clave privada del certificado esencialmente público.
    • Además, ¿de dónde obtienen los certificados SSL de $5/año?
    • Google acaba de certificado ssl o ir a http://www.ssls.com
    • Gracias por tu experiencia! Pero no te entiendo, que tiene Man-in-the-Middle riesgo de ataque? Un atacante puede suplantar su dominio, si obtiene su clave privada. Vamos a hacer algo similar servidor local, pero vamos a generar propio de la CA Raíz y el certificado SSL para «127.0.0.1» de dominio. En la primera ejecución en el servidor local instala el certificado de CA Raíz para Almacenamiento de Certificados de Windows. Pero no funciona bien en Firefox, debido a que Firefox usa un certificado propio de almacenamiento.
    • Tenga en cuenta que esto sin duda dará lugar a la revocación de su certificado por parte de la autoridad. La incrustación de las claves privadas en un software es considerado como una violación del uso del certificado. Las compañías bien conocidas han tenido sus certificados revocados por esta misma razón: ver, por ejemplo, Ciso caso, Blizzard caso, y ha habido reportes de Spotify, GitHub, Dropbox, así, y probablemente más… Así que esta bajo su propio riesgo.

  4. 1

    Desde que está en localhost, usted puede decirle a su navegador que confiar en cualquier certificado que desee.

    Hacer un certificado auto-firmado por localhost, y dígale a su navegador para confiar en él.

    • Puede hacer que el uso de otro programa de la lógica, por ejemplo, a través de una aplicación Java? Sería un dolor tener que hacerlo a mano en cada una de las máquinas que necesita tener acceso a un servidor con dicho certificado. Si la aplicación puede hacer que el sistema operativo o cualquier navegador web confiar en el certificado, que probablemente iba a estar bien, ¿verdad?
  5. 0

    La solución «Punto de tu localhost.MI-SLD.MI-TLD a 127.0.0.1» proporcionado por la proporcionado por CoolAJ86 funciona bien, y puedes ver una explicación más detallada aquí:

    Cómo PLEX está haciendo https para todos sus usuarios

    PS: yo no sé cómo sostenible, esto es, porque alguien con un escenario similar tenía su clave revocado como si la clave había sido comprometida.

    • telebit.en la nube utiliza Greenlock y Vamos a Cifrar para emitir certificados en el dispositivo de modo que no se ha revocado.

Dejar respuesta

Please enter your comment!
Please enter your name here