Porque resulta que sí, que somos de alguna manera productores de contenido y no basta con retocar algunos navegadores web. Hay que actualizar el resto.
lunes, 27 de julio de 2020
Y aquí estamos, entre el drama de no haber enviado ningún resumen más desde últimos del mes pasado y comprobar que lo que tengo hecho estas semanas no sirve ni para completar un párrafo completo.
Y al hilo del problema del otro día con los TLS me he dado cuenta de que tenemos bastantes servidores web que también deberían actualizar su configuración y desechar las versiones obsoletas de los protocolos de cifrado. Y allá con ello que voy.
Había pensado en hacer una lista de servidores web e importancia dentro de la empresa pero veo que es una de las mías y que en realidad sólo es necesario tener la fórmula para modificar su configuración según sean nginx o apache2. Y ya.
Lo vuelvo a poner aquí como referencia. Si el servidor es nginx es necesario retocar la directiva ssl_protocols teniendo en cuenta que es un valor global pero que generalmente estará replicado en cada servidor virtual.
ssl_protocols TLSv1.2;
Y si es un servidor Apache2 la configuración es prácticamente la misma:
SSLProtocol TLSv1.2
Me voy a hacer un poco el loco y trataré como casos especiales cualquier problema con el tipo de cifrado en aplicaciones antiguas.
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:
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
