SoapUI sí consume servicios web TLS v1.3

Me consultan si SoapUI 5.5 (u otra versión) soporta Transport Layer Security en su versión 1.3 y puede consumir servicios web que pasen a usar ese protocolo en lugar de TLS v1.2. Yo no he tenido la necesidad todavía de comunicarme con un servicio que demande exclusivamente la versión 1.3 de dicho protocolo usando SoapUI. Una búsqueda rápida tampoco arroja resultados precisos, centrándose más bien en TLS v1.2. Así que, para salir de dudas, me dispuse a probar y a analizar dicho soporte a lo largo de diferentes versiones de la herramienta de Smartbear.

Elección del servicio de prueba

Para realizar las pruebas, localicé un servicio web público que permite validar si un cliente (SoapUI en este caso) consigue negociar y establecer una conexión TLS v1.3, ahorrándome así la implementación de uno. El servicio escogido fue el validador TLS 1.3 de Akamai Technologies, una empresa dedicada a soluciones de seguridad, redes de distribución de contenido y edge computing.

Lo bueno que tiene este validador es que ofrece una versión a modo de API REST que devuelve el resultado como una respuesta JSON tras invocar el endpoint https://check-tls.akamai.io/v1/tlsinfo.json mediante el método HTTP(S) GET.

Probando con la versión de SoapUI más reciente

Tras la elección del servicio, descargué e instalé SoapUI en su última versión, la 5.7 para establecer un punto de partida. Creé un nuevo proyecto REST, indicándole la ruta del validador TLS de Akamai que responde con JSON.

Al nuevo proyecto lo denominé Prueba endpoint TLS v1.3 y modifiqué la petición por defecto para que fuese con el método GET y no POST.

Si se observa el JSON devuelto por Akamai, en particular el atributo "tls_version": "tls1.3", se confirma que por defecto y sin necesidad de configuraciones adicionales, SoapUI 5.7 soporta TLS 1.3.

¿Y si se quiere forzar a que el SoapUI sólo use la versión 1.3 del protocolo? Pues bastaría con añadir la línea –Dsoapui.https.protocols=TLSv1.3 al final del fichero VMOPTIONS tal que así:

-XX:MinHeapFreeRatio=20
-XX:MaxHeapFreeRatio=40
-Xms128m
-Xmx1000m
-Dsoapui.properties=soapui.properties
-Dsoapui.home=C:\Program Files\SmartBear\SoapUI-5.7.0/bin
-Dsoapui.ext.libraries=C:\Program Files\SmartBear\SoapUI-5.7.0/bin/ext
-Dsoapui.ext.listeners=C:\Program Files\SmartBear\SoapUI-5.7.0/bin/listeners
-Dsoapui.ext.actions=C:\Program Files\SmartBear\SoapUI-5.7.0/bin/actions
-Dwsi.dir=C:\Program Files\SmartBear\SoapUI-5.7.0/wsi-test-tools
-Djava.library.path=C:\Program Files\SmartBear\SoapUI-5.7.0/bin -Djava.util.Arrays.useLegacyMergeSort=true
-splash:SoapUI-Spashscreen.png
--illegal-access=permit
-Dlog4j2.formatMsgNoLookups=true
-Dsoapui.https.protocols=TLSv1.3

También se puede forzar la conexión mediante una versión anterior del protocolo, como TLS 1.2 editando el VMOPTIONS con la línea -Dsoapui.https.protocols=TLSv1.2. Si realizamos este cambio e iniciamos de nuevo el SoapUI, el WS de Akamai ahora devuelve que la conexión se estableció vía TLS 1.2 (valor esperado).

Además, es posible especificar múltiples versiones del protocolo, separándolas por comas: -Dsoapui.https.protocols=TLSv1.1,TLSv1.2

Probando con SoapUI 5.5

Veamos ahora qué ocurre con la versión 5.5 del SoapUI objeto de la consulta. Para ello, la busqué y descargué del repositorio de versiones antiguas que ofrece Smartbear.

Como instalé esta versión 5.5 sin interferir con la 5.7 previa, al iniciarla me detectó el espacio de trabajo previamente creado y el proyecto de prueba, por lo que emergió un cuadro de diálogo con la siguiente advertencia:

Si realizamos la petición contra el servicio de Akamai con SoapUI 5.5 sin manipular el VMOPTIONS, se verifica que la versión de TLS por defecto es la 1.2.

Ahora bien, si se modifica el fichero de configuración para forzar TLS 1.3 con esta versión del SoapUI tal que así:

-XX:MinHeapFreeRatio=20
-XX:MaxHeapFreeRatio=40
-Xms128m
-Xmx1000m
-Dsoapui.properties=soapui.properties
-Dsoapui.home=C:\Program Files\SmartBear\SoapUI-5.5.0/bin
-Dsoapui.ext.libraries=C:\Program Files\SmartBear\SoapUI-5.5.0/bin/ext
-Dsoapui.ext.listeners=C:\Program Files\SmartBear\SoapUI-5.5.0/bin/listeners
-Dsoapui.ext.actions=C:\Program Files\SmartBear\SoapUI-5.5.0/bin/actions
-Dwsi.dir=C:\Program Files\SmartBear\SoapUI-5.5.0/wsi-test-tools
-Djava.library.path=C:\Program Files\SmartBear\SoapUI-5.5.0/bin -Djava.util.Arrays.useLegacyMergeSort=true
-splash:SoapUI-Spashscreen.png
-Dsoapui.https.protocols=TLSv1.3

Y se realiza la petición tras iniciar de nuevo el programa, no se obtiene respuesta de Akamai. En su lugar, en la parte inferior izquierda de la ventana de petición, se lee Error getting response; java.lang.IllegalArgumentException: TLSv1.3, confirmando esta excepción que SoapUI 5.5 no soporta TLS 1.3.

Esto sucede porque el programa hace uso de una máquina virtual de Java embebida distinta en sus diferentes versiones y TLS 1.3 se incluyó en Java 1.8 a partir de la actualización 261:

• Java SE Runtime Environment 1.8.0_181 para SoapUI 5.5
• OpenJDK Rntime Environment 16.0.1 para SoapUI 5.7

Conclusiones

SoapUI soporta TLS 1.3 de forma nativa a partir de su versión 5.6 por incluir el entorno de ejecución de Java OpenJDK 11. En versiones anteriores, como la 5.5, sería posible usar TLS v1.3 mediante soluciones como:

• Disponer de una VM de Java 1.8.0_261 o superior configurada en el equipo y hacer que SoaUI la use mediante la manipulación del fichero VMOPTIONS
• Usar un ESB como Mule, un microservicio Spring Boot o un sistema similar que haga de pasarela, ofreciendo un interfaz HTTP a SoapUI pero estableciendo conexión mediante TLS 1.3 contra el WS destino

Por último, aunque es posible manipular y forzar mediante el VMOPTIONS que SoapUI use versiones concretas de TLS es recomendable evitarlo, puesto que:

• Es mejor disponer del software actualizado (se evitan vulnerabilidades como la de Log4j y bugs)
• Java por defecto ya elige en función del servicio a consumir la mejor opción de TLS y encriptado