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. .
Hola EJP, ¿te refieres al uso de 'SSLContext.getDefault()'? Además, ¿cuáles son los valores predeterminados? –
@MickaelMarrache Ver la edición. – EJP