TLS y Java Client

1

Trabajo con un cliente y un servidor Java que nuestra startup adquirió recientemente con un acceso muy limitado a los desarrolladores que lo crearon. Hay documentación muy limitada. Parece que el cliente Java solía conectarse a su servidor con TLS, hay una regla de servidor Nginx para el punto final correcto y un certificado y una clave privada asociada a él. Sin embargo, el desarrollador afirma que no necesitaban tener una clave pública presente en la máquina que ejecuta el cliente Java.

Hasta ahora he aprendido que Java almacena estos certificados de confianza en el archivo jre/lib/security/cacerts . Después de instalar un certificado autofirmado allí, pude hacer que el cliente Java se conectara al servidor con cifrado.

Ahora la pregunta es: ¿cómo está disponible el certificado para Java? ¿Debe instalarse cada vez manualmente en cacerts ? ¿O estará disponible para Java después de que obtengamos un certificado legítimo de alguna autoridad como Thawte? Por "estar disponible" quiero decir, ¿irán las libretas HTTP de Java y encontrarán ese certificado con la autoridad de clave pública? (No estoy familiarizado con cómo funciona la verificación de certificados con clientes que no son navegadores).

El desarrollador del cliente y servidor de Java me dice que la clave pública se descarga desde el servidor durante la conexión, lo que para mí no tiene sentido y no respeta el propósito de la seguridad, tanto si la clave pública como la la clave privada proviene de la misma fuente, ¿cómo podemos confiar en ella?

Estoy aprendiendo mucho a medida que avanzo (es un inicio) y solo sé criptografía pública en teoría de la universidad, pero en la práctica parece un poco diferente. :) Gracias.

    
pregunta Serge Poele 10.11.2016 - 00:44
fuente

2 respuestas

1

Un certificado de confianza es firmado ( please lea toda la respuesta en el enlace ) por un certificado intermedio que a su vez está firmado por un certificado raíz. Puede haber más de un intermedio en la cadena, uno tras otro. Oracle distribuye el certificado raíz (y probablemente también Microsoft y Apple en las actualizaciones del sistema operativo y las distribuciones de Linux en el paquete de certificados basado en el programa raíz de Mozilla).

Durante el protocolo de enlace TLS, el servidor TLS envía el certificado de hoja y todos los intermedios al cliente TLS. El cliente TLS verifica todas las firmas digitales (el protocolo de enlace está firmado por la clave en el certificado de hoja, que está firmado por la clave para el intermediario, etc.) hasta el certificado raíz que es de confianza implícita, no debido a la criptografía sino porque alguien puso ese archivo de certificado raíz en el directorio correcto.

No hay un directorio de certificados o claves públicas para dominios, el servidor le entrega un certificado. Google inicia un proyecto llamado Certificado de Transparencia para lograr un registro público de todos los certificados de confianza pública para todos los servidores accesibles públicamente, pero no está destinado a Se utilizará para establecer conexiones TLS, aunque los navegadores requieren los certificados de EV y los certificados emitidos por las entidades de propiedad de Symantec y, en 2017, Google planea exigir una prueba de registro de todos los certificados.

No es necesario contactar a la CA para verificar el certificado.

Si desea verificar que el certificado no ha sido revocado, el cliente TLS debe comunicarse con la CRL de la CA u obtener una respuesta OCSP grapada del servidor TLS. Los certificados se pueden configurar (en el momento de la creación) para que digan "No confíe en este certificado sin verificar la revocación", esto se denomina "OCSP debe grapar". No sé si su cliente incluso intenta verificar la revocación, muchos no.

Los certificados que no son de confianza pueden ser como los de confianza pero firmados por una CA cuya raíz no es de confianza para su cliente. Muchas organizaciones ejecutan su propia CA interna, que es de confianza para todos sus clientes (TI agrega la raíz de la CA a todas las computadoras) y esta CA se usa para emitir certificados para sus servidores internos. La CA también puede emitir certificados SSH y VPN. Para un cliente TLS que no esté familiarizado con la CA interna, un certificado emitido por uno no sería confiable.

Los certificados que no son de confianza también pueden ser autofirmados. Para validar dicho certificado, el cliente debe tener, antes de establecer una conexión, una copia del certificado en sí, no de ninguna raíz, que adquirió "fuera de banda" (es decir, un desarrollador lo copió y pegó). Recomendaría pasarlo (el certificado autofirmado y codificado) a la API que realiza la conexión de red en lugar de convertirlo en un certificado raíz de confianza para la computadora en la que está instalado el software cliente.

    
respondido por el Z.T. 10.11.2016 - 01:28
fuente
1

Una vez que obtenga un certificado "legítimo", Java confiará en ese certificado de forma nativa. Java se envía con una lista de CA estándar (como lo hace su navegador) y podrá encadenarlo.

Hay muchas cosas que pueden salir mal. Si no funciona, debes asegurarte:

  • El servidor está configurado correctamente (envía el certificado y certificados intermedios que se encadenan a la CA)
  • La CA está en el almacén de confianza de java (cacerts)
  • El cliente está codificado para usar el almacén de confianza java predeterminado, aprovechando el java La clase de URL suele ser la forma más sencilla de hacerlo
respondido por el Egret 12.11.2016 - 02:42
fuente

Lea otras preguntas en las etiquetas