java https: // localhost (SSL) – posible sin instalar certs en el cliente?

Después de leer lo siguiente, todavía estoy atascado en hacer la aplicación java del server web sin installation https : // localhost independiente mínimo. Debe estar libre de bibliotecas, usar Java 8 y aceptar conexiones desde el browser sin instalar primero ningún certificate de cliente especial. No estoy seguro si esto es posible con los certificates autofirmados porque solo tiene que funcionar para "localhost".

  • ¿Cómo hacer que el socket del server SSL sea compatible tanto con http como con https en Java?
  • Mi server java HTTPS simple solo funciona para localhost
  • Servidor Java HTTPS simple

Hasta ahora he generado algunos files key usando

openssl genrsa -aes128 -out privkey.pem 2048 # makes privkey.pem openssl req -new -x509 -key privkey.pem # makes cert.crt 

y he improvisado la function mínima de configuration de Kotlin

 private fun ssl():SSLServerSocketFactory { val password = "MYPASSWORD".toCharArray() val kmf = KeyManagerFactory.getInstance("SunX509") val tmf = TrustManagerFactory.getInstance("SunX509") val sslContext = SSLContext.getInstance("TLS") // initialise the keystore KeyStore.getInstance("JKS").let { ks-> FileInputStream("lig.keystore").use { ks.load(it, password) } kmf.init(ks, password) tmf.init(ks) } // setup the HTTPS context and parameters sslContext.init(kmf.getKeyManagers(), tmf.getTrustManagers(), null) return sslContext.serverSocketFactory } ssl().createServerSocket().use { serverSocket -> serverSocket.reuseAddress = true serverSocket.bind(InetSocketAddress(port)) logger.info { "WebServer ready and listening on ${serverSocket.localPort}" } 

Pero tengo problemas para terminarlo: ¿necesito hacer un file lig.keystore ? ¿Se puede hacer esto incluso sin instalar certs en el browser del cliente?

    Existen dos enfoques comunes para get una connection segura entre un cliente (browser) y un server a través de HTTPS:

    1. Puede get un certificate SSL para el server que está firmado por una autoridad de certificación raíz (CA) que es de confianza por el browser web del usuario de forma pnetworkingeterminada.

    2. Puede generar un certificate SSL autofirmado y hacer que el usuario lo importe en su browser web como certificate de confianza.

    Lo que ha hecho hasta ahora parece ser generar un almacén de keys del lado del server con un certificate autofirmado y (más o less) configurar el server de Kotlin para usarlo. El problema es el cliente (browser). No existe una forma segura de que el browser confíe en el certificate autofirmado sin la participación del usuario. (¡Seguro … como seguro para el usuario!)

    Y ninguna CA legítima debería emitir un certificate SSL para "localhost"; eg https://www.ssl2buy.com/wiki/how-to-get-ssl-certificate-for-web-applications-that-runs-on-localhost

    Punto muerto.

    OK, así que vamos a dar un paso atrás. El propósito de usar HTTPS / SSL es garantizar que:

    1. El browser web del usuario está hablando con el server correcto y no con otro server que lo esté haciendo pasar por otro.

    2. La connection entre el browser y el server está encriptada para que ningún tercero pueda husmear en el tráfico.

    Pero estás tratando de hacer esto para una connection de localhost . La dirección IP del host localhost es una dirección de bucle invertido. A less que el núcleo del sistema operativo se vea comprometido, se le garantiza que los packages de networking enviados a través de una connection de bucle invertido no saldrán del host.

    1. Puede descartar el problema de "suplantación". Suponiendo que la máquina del usuario no se ha visto comprometida, nadie más puede iniciar un server "falso" en la máquina del usuario.

    2. Puede descartar el problema de "fisgoneo". Suponiendo que la máquina del usuario no se ha visto comprometida:

      • Los packages no se desactivarán, por lo que no se pueden interceptar en ninguna networking "externa".
      • La única persona que puede "husmear" los packages en la networking de bucle invertido es el usuario mismo.

    Entonces, la solución es simple. Use "http" para su connection "localhost". Debe ser seguro … suponiendo que la máquina del usuario no se ha visto comprometida.

    Nota: si la máquina del usuario se ha visto comprometida , los delincuentes tienen otras forms de interceptar el tráfico que SSL no protegerá.