Y es que es un buen momento para empezar a molestar. Pero por otro lado me permite no quedarme dormido porque el aburrimiento y la inacción me matan, oiga.

jueves, 23 de julio de 2020

Esta mañana, según llego, comienzan las quejas. Diferentes dispositivos y diferentes navegadores no pueden conectar con nuestro ERP. ¿ El problema ? Algo relacionado con las conexiones seguras.

Mis homínidos se lanzan a una carrera de especulaciones y reinicios en plan mono pero no consiguen nada. Yo pruebo con Firefox en el puesto del almacén y veo que hay un aviso sobre certificados TLS (sobre la versión concretamente) y un botón que me indica que si quiero seguir. Le digo que sí y pasamos de nivel porque lo esencial es producir y trabajar en este mundo idílico que nos ha tocado.

Mientras me centro en qué ocurre con el resto de los navegadores, especialmente Google Chrome y derivados, y veo que es un problema con la versión del protocolo TLS, que debe ser 1.2 o superior.

Vaya. ¿ Justamente hoy ? Bueno, en el fondo hoy o mañana no representa diferencias. Busco en la red y encuentro un aviso en el blog de Google Chrome donde ya avisaban de ésto un par de años atrás.

El problema, entonces, está en el/los servidores web que están empleando versiones inferiores de TLS. Concretamente el servidor nginx sobre odoo. Primero me cercioro de que sea así empleando una herramienta de consola como nmap:

victor@sarajevo:~$ nmap --script ssl-enum-ciphers -p 443 erp.venexma.net
Starting Nmap 7.70 ( https://nmap.org ) at 2020-07-23 09:52 CEST
Nmap scan report for erp.venexma.net (192.168.100.9)
Host is up (0.00021s latency).
PORT STATE SERVICE
443/tcp open https
| ssl-enum-ciphers:
| TLSv1.0:
| ciphers:
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
| TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 1024) - A
| TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (dh 1024) - A
| TLS_ECDH_anon_WITH_AES_256_CBC_SHA - F
| TLS_RSA_WITH_AES_256_CBC_SHA (rsa 4096) - A
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (rsa 4096) - A
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
| TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 1024) - A
| TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (dh 1024) - A
| TLS_ECDH_anon_WITH_AES_128_CBC_SHA - F
| TLS_RSA_WITH_AES_128_CBC_SHA (rsa 4096) - A
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (rsa 4096) - A
| compressors:
| NULL
| cipher preference: server
| warnings:
| Key exchange (dh 1024) of lower strength than certificate key
| Key exchange (secp256r1) of lower strength than certificate key
|_ least strength: F

Cambiar la configuración del servidor web es bastante sencilla. La directriz ssl_protocols es muy directa:

# limit ciphers
ssl_ciphers            HIGH:!ADH:!MD5;
ssl_protocols            TLSv1.2;
ssl_prefer_server_ciphers    on;

Y después de reiniciar muy sencillo de comprobar de nuevo:

victor@sarajevo:~$ nmap --script ssl-enum-ciphers -p 443 erp.venexma.net
Starting Nmap 7.70 ( https://nmap.org ) at 2020-07-23 10:22 CEST
Nmap scan report for erp.venexma.net (192.168.100.9)
Host is up (0.00022s latency).
PORT STATE SERVICE
443/tcp open https
| ssl-enum-ciphers:
| TLSv1.2:
| ciphers:
| TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
| TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (dh 1024) - A
...

Y como vemos a continuación Google Chrome está contento por fin:

¿ Pasará algo por eliminar el soporte de versiones anteriores a la 1.2 en TLS ? ¡ Por supuesto ! Yo me voy a limitar a informar de los cambios y luego, ya si eso, veremos qué dispositivo antiguo y no actualizable tiene problemas con ello y cómo arreglarlo si es que es posible.

Por ahora ya está.

Adenda

En Twitter ya están avisando de ello. ¡ No estoy solo !

Pero también da la solución que consiste en cambiar un valor en la configuración: chrome://flags/#legacy-tls-enforced