Cómo utilizar TLSv1.2 y System SSL en IBM i 7.1
Requisitos del sistema
IBM i 7.1 Technology Refresh 6 (TR6) incluye la funcionalidad System SSL TLSv1.2
. Para admitir y utilizar el nuevo protocolo, también se requieren parches temporales de programa (PTF) en varias áreas del sistema operativo. Después de instalar DCM (5770SS1 opción 34) en el sistema, al solicitar y aplicar
SI48659 se obtendrán todos los PTF compatibles. SI48659 extrae más de veinte PTF como requisitos previos de PTF. Asegúrese de que el PTF necesario para la distribución de aplicaciones y opciones
esté instalado válidamente en el sistema.
Cambios en el valor del sistema
Después de aplicar SI48659, el nuevo soporte se instala pero permanece inactivo en System SSL. El valor del sistema QSSLPCL debe cambiarse mediante Cambiar valor del sistema
(CHGSYSVAL) para activar el nuevo protocolo para el sistema SSL. Cambie el valor predeterminado de *OPSYS a:
*TLSV1.2
*TLSV1.1
*TLSV1
*SSLV3
Si QSSLPCL está configurado en un valor distinto de *OPSYS, agregue *TLSV1.2 y *TLSV1.1 a la configuración existente.
Figura 1. Cambiar valor del sistema
Además del comando CL Cambiar valor del sistema (CHGSYSVAL), también puede utilizar Navigator for i para trabajar con QSSLPCL
valores. Navigator for i se encuentra actualmente en otro ciclo de lanzamiento y las mejoras para admitir TLSv1.2 a través de esta estructura de interfaz estarán disponibles después del verano de 2013. Si bien este nuevo protocolo es compatible a través de
CHGSYSVAL, esta configuración no será visible en Navigator for i hasta que esta actualización esté disponible.
Después de modificar el valor del sistema QSSLPCL, el sistema puede comenzar a utilizar el nuevo protocolo. Ninguna aplicación puede utilizar automáticamente el nuevo soporte; se debe habilitar el soporte para cada aplicación.
Volver al principio
Soporte de aplicaciones
DCM
Muchas de las aplicaciones proporcionadas por IBM i utilizan definiciones de aplicaciones para configurar el certificado de la aplicación. información para el programa. Actualmente, los administradores pueden especificar certificados para definiciones de aplicaciones aprovechando
DCM. Otros campos en la definición de la aplicación determinan si se utiliza la autenticación del cliente y qué autoridades de certificación (CA) están permitidas. Esta interfaz de configuración de DCM
existente se ha mejorado para incluir nuevos campos en la definición de la aplicación.
Uno de los nuevos campos controla qué protocolos admite la aplicación. Debe cambiar este campo para incluir TLSv1.2 para activar este protocolo para esta aplicación. La configuración predeterminada para este campo es
*PGM, lo que permite que el código de la aplicación y la configuración existente determinen qué protocolo usar. Inicialmente, las aplicaciones que utilicen la configuración *PGM no podrán utilizar
TLSv1.2, pero esto cambiará a medida que evolucione la versión.
Este nuevo soporte a nivel de aplicación para el control del conjunto de protocolos y cifrado también tiene algunos inconvenientes. Los administradores ahora pueden configurar atributos de seguridad más débiles para las aplicaciones de IBM que en el pasado.
El Centro de información de IBM i contiene más información sobre los campos definidos por la aplicación que se pueden cambiar.
Algunas aplicaciones no permiten la modificación de uno o más campos nuevos. Si la aplicación bloquea cambios, el panel DCM mostrará un error 4022. IBM HTTP Server
es una de esas aplicaciones que no permite la configuración de protocolos y cifrados a través del panel DCM.
El nivel 18 del grupo PTF del servidor HTTP proporciona
soporte HTTP con TLSv1.2 habilitado.
Interfaz de programación de aplicaciones del entorno de lenguaje integrado (ILE)
La interfaz de programación System SSL se ha actualizado para permitir a los desarrolladores utilizar TLSv1.2. Debe instalar SI48539 (requisito previo de distribución para SI48659
) antes de poder cargar las nuevas versiones de gskssl.h y qsossl.h en su sistema de desarrollo. Se han actualizado las descripciones de GSKit y SSL API en IBM i Information Center.
Una modificación típica de la aplicación GSKit es agregar dos llamadas a gsk_attribute_set_enum(), especificando el identificador del entorno de seguridad devuelto por la llamada
gsk_environment_open() existente.
Listado 1. Código de muestra de GSKit
rc = gsk_attribute_set_enum(env_handle, GSK_PROTOCOL_TLSV12, GSK_TRUE);
if (rc != GSK_OK)
{
printf("gsk_attribute_set_enum() falló con rc = %d.\n", rc);
printf("rc de %d significa %s\n " , rc, gsk_strerror(rc));
break;
}
rc = gsk_attribute_set_enum(env_handle, GSK_PROTOCOL_TLSV11, GSK_TRUE);
if (rc != GSK_OK)
{
printf("gsk_attribute_set_enum() falló con rc = %d.\n", rc);
printf("rc de %d significa %s\n", rc, gsk_strerror(rc));
break;
}
Consulte la documentación de la API para vea más detalles sobre estas propiedades y otras propiedades nuevas o modificadas disponibles para los desarrolladores.
Java Secure Socket Extension (JSSE)
Si es usuario del proveedor IBM Pure JSSE IBMJSSE2, las últimas versiones SR de JDK6 y JDK7 proporcionan TLSv1.2
Compatible y no requiere IBM i 7.1 TR6.
Si es usuario del proveedor nativo de IBM i JSSE IBMi5OSJSSEProvider, debe cumplir con los requisitos enumerados anteriormente, incluido el cambio de QSSLPCL.
JDK7 utiliza SSL_TLSv2 como protocolo de contexto predeterminado. Este protocolo de contexto admite TLSv1.2, TLSv1.1, TLSv1.0 y
SSLv3. Para limitar su sistema a un protocolo, puede usar TLSV1.2 o TLSv1.1 como protocolo para el método SSLContext.getInstance.
Para JDK6, SSL_TLSv2 debe especificarse en el método SSLContext.getInstance
ya que este no es el valor del protocolo predeterminado. También puede utilizar TLSV1.2 o TLSv1.1.
Volver al inicio
Interoperabilidad
El protocolo SSL se diseñó originalmente teniendo en mente la compatibilidad con versiones posteriores.
SSL
El servidor puede admitir múltiples versiones de protocolo al mismo tiempo. Negocia utilizando la versión más alta del protocolo admitida por ambos extremos de la conexión. Lamentablemente, hay indicios de que un pequeño número de implementaciones SSL actuales siguen siendo incompatibles. Esta condición en sí misma causará un error cuando una aplicación cliente SSL recientemente habilitada para TLSv1.2 aprovecha una de estas implementaciones para conectarse a un servidor SSL. Si ocurren problemas de interoperabilidad, los servidores pares deben actualizar su implementación SSL o los clientes deben dejar de usar TLSv1.2 cuando usan el servidor.
Si las pruebas han determinado que todas las aplicaciones pares admiten TLSv1.2, la aplicación se puede configurar para admitir solo
TLSv1.2 para obtener el nivel más alto de seguridad. Para algunas aplicaciones, es posible que esta configuración no siempre sea factible.
Es importante tener en cuenta que el cliente par también debe admitir y habilitar TLSv1.2 para que los dos puedan negociar. Actualmente, muchas aplicaciones cliente no admiten TLSv1.2 debido a un problema "difícil de determinar": dado que los servidores no comprenden TLSv1.2, los clientes no tienen ningún incentivo para integrar este soporte. Ahora que el servidor ya tiene la funcionalidad TLSv1.2, más clientes agregarán gradualmente compatibilidad con TLSv1.2.