2012-07-16 26 views
10

Estoy mirando la guía de referencia JSSE, necesito obtener una instancia de SSLContext para crear un SSLEngine, así que puedo usarlo con Netty para habilitar la seguridad.inicialización SSLContext

Para obtener una instancia de SSLContext, utilizo SSLContext.getInstance(). Veo que el método se reemplaza varias veces, por lo que puedo elegir el protocolo y el proveedor de seguridad para usar.

Here, puedo ver la lista de algoritmos que se pueden utilizar. ¿Qué algoritmo debería usar para habilitar la comunicación segura?

Además, dado que es posible especificar el proveedor de seguridad a usar, ¿qué proveedor debo usar?

Gracias

Respuesta

3

No hay valor predeterminado para el protocolo, por lo que usaría el último de ellos el apoyo de su JDK, que es ya sea TLSv1, TLSv1.1 o TLSv1.2: ver cuál funciona, o echar un vistazo al getSupportedProtocols(). El proveedor de seguridad predeterminado se utiliza al evitar todas las API donde lo especifique, o bien, p. KeyStore.getDefaultType().

Y cuando llegue a obtener sus SSLEngines, asegúrese de usar el método que toma un nombre de host y un puerto. De lo contrario, no recibirá ninguna sesión de SSL compartida.

+0

Hola EJP, ¿te refieres al uso de 'SSLContext.getDefault()'? Además, ¿cuáles son los valores predeterminados? –

+0

@MickaelMarrache Ver la edición. – EJP

21

Como puede ver en el standard names documentation, todas las entradas (SSLv3, TLSv1.0, TLSv1.1, ...) dicen que pueden admitir otras versiones.

En la práctica, en Oracle JDK (y OpenJDK), todos lo hacen. Si nos fijamos en el source code, la clase TLS10Context es lo que se usa para TLS, SSL, SSLv3 y TLS10, TLS11Context se usa para TLSv1.1 y TLS12Context para TLSv1.2. Todos son compatibles con todas las versiones de SSL/TLS, es lo que está habilitado por defecto que varía.

Esto puede ser diferente con otro proveedor o proveedor de JRE. Por supuesto, debe elegir uno que al menos vaya a ser compatible con la versión de protocolo que desea utilizar.

Tenga en cuenta que el protocolo utilizado se determina más adelante utilizando SSLSocket.setEnabledProtocols(...) o su equivalente SSLEngine.

Como regla general, use el número de versión más alto que pueda (SSLv3 < TLSv1.0 < TLSv1.1 ...), que puede depender de lo que admitan las partes con las que desea comunicarse.


Los protocolos que están habilitados de forma predeterminada varían según la versión exacta de Oracle JRE.

Al mirar the source code for sun.security.ssl.SunJSSE in OpenJDK 7u40-b43, TLS es simplemente un alias para TLSv1 (y por lo tanto son SSL y SSLv3), en términos de SSLContext protocolos. En cuanto a los diversos implementations of SSLContextImpl (que son las clases internas de SSLContextImpl sí mismo):

  • Todo el apoyo todos los protocolos.
  • Todos los protocolos están habilitados en el lado del servidor de forma predeterminada.
  • los protocolos de cliente activado por defecto varían:
    • TLS10Context (utilizado para el protocolo SSL, SSLv3, TLS, TLSv1) permite SSLv3 a TLSv1.0 de forma predeterminada en el lado del cliente.
    • TLS11Context (usado para el protocolo TLSv1.1) también habilita TLSv1.1 por defecto.
    • TLS12Context (utilizado para el protocolo TLSv1.2) también habilita TLSv1.2 de manera predeterminada.
  • Si FIPS está habilitado, SSL no es compatible (por lo que no está habilitado de manera predeterminada).

Esto cambia en Java 8, junto con la propiedad del sistema the new jdk.tls.client.protocols.

vez más, cuando mirando the source code for sun.security.ssl.SunJSSE in OpenJDK 8u40-b25, SSLContext protocolos TLSv1, TLSv1.1 y TLSv1.2 también hacer uso de TLS10Context, TLS11Context y TLS12Context, que siguen la misma lógica que en Java 7.

Sin embargo, el protocolo TLS ya no es alias a cualquiera de ellos. Más bien, usa TLSContext que se basa en los valores en las propiedades del sistema jdk.tls.client.protocols. Del JSSE Reference guide:

Para habilitar protocolos SunJSSE específicos en el cliente, especifíquelos en una lista separada por coma entre comillas; todos los demás protocolos compatibles se desactivan en el cliente. Por ejemplo, si el valor de esta propiedad es "TLSv1, TLSv1.1", las configuraciones de protocolo predeterminadas en el cliente para TLSv1 y TLSv1.1 están habilitadas en el cliente, mientras que SSLv3, TLSv1.2 y SSLv2Hello están deshabilitadas en el cliente.

Si esta propiedad está vacía, todos los protocolos están habilitados por defecto tanto en el lado del cliente como del servidor.

Por supuesto, en recent versions of Oracle JRE 8, SSL is also completely disabled by default (tan eliminado de esas listas).

Nótese que en ambos casos (JRE 7 y 8), el SSLContext se obtiene de forma predeterminada a través de SSLContext.getDefault() fuera de la caja es más o menos equivalente a una SSLContext obtenido con el protocolo TLS y inicializado con los parámetros trustStore por defecto, etc. .

+0

¿Puede reformular su respuesta en términos de lo que sucede cuando dice getInstance ("SSL") contra getInstance ("TLS") o getInstance ("TLSv1")? ¿Cuáles son los protocolos compatibles para cada uno? ¿Cuáles son los protocolos predeterminados para cada uno y en qué orden de precedencia? La documentación de Java no es muy clara en estos puntos. Por ejemplo, dice que elegir "TLSv1" puede hacer que 1.0, 1.1 y 1.2 estén disponibles. ¿Eso significa que SSLv3 no está disponible? ¿Qué pasa si eliges "TLS" ¿eso hace que SSLv3 no esté disponible? – KyleM

+1

@KyleM He agregado algunos detalles. Elegir un protocolo con una versión superior no deshabilita los que tienen una versión más baja (a menos que lo haga explícitamente). Sin embargo, hay una excepción para SSL, que normalmente también está deshabilitada en versiones recientes. – Bruno

+0

@KyleM se supone que tienes una pregunta por hilo ... y esta respuesta/hilo es de 2012 – eis