Tengo un servicio OpenVPN privado desde hace diez años. Todos los certificados X.509 de acceso y el certificado X.509 del servidor OpenVPN están firmados por una autoridad de certificación privada.

El problema es que esa autoridad de certificación tiene una validez de diez años, caducando en unos meses. En ese momento OpenVPN dejará de funcionar si no hago nada.

La solución evidente es crear un nuevo certificado para la autoridad de certificación privada, con una validez de otros diez años (por ejemplo). El problema es que eso requiere emitir nuevos certificados X.509 para el servidor OpenVPN y para todos los clientes. Todo el cambio tiene que estar coordinado, porque los certificados X.509 previos dejarían de ser válidos en cuanto se active la nueva clave de la autoridad de certificación.

¿Cómo refrescar una autoridad de certificación para extender su fecha de caducidad manteniendo la validez de los certificados X.509 firmados previamente?

Los certificados X.509 tienen un número de serie y una fecha de mínima y otra máxima de validez. ¿Es posible modificar dichas fechas del certificado X.509 de la autoridad de certificación y que sigan funcionando las firmas antiguas?

Leer más…

En Generar un email diario a partir de un feed RSS (Slashdot) y Mejoras a la hora de generar un email diario a partir de un feed RSS (Slashdot) describo un programa para enviar por email las novedades diarias de un feed RSS.

Aunque al programa le vendría bien una reescritura, todo fue bien hasta hace unos días, cuando el programa falló con un error indicando que no se podía recuperar el estado volcado con pickle debido a una dependencia (inesperada e inadvertida) con beautifulsoup4.

El error en sí era críptico y poco claro, pero ocurrió tras haber actualizado la biblioteca beautifulsoup4. Esto fue una pista crucial. Obviamente todo volvió a la normalidad tras instalar una versión previa y así siguió cumpliendo con su trabajo unos días hasta que encontré tiempo para echarle un vistazo. La actualización de beautifulsoup4 no era urgente y pude aplazar la investigación hasta que me vino bien.

Una vez metido en faena quedó claro que el problema era que la estructura interna de beautifulsoup4 había cambiado y los objetos serializados de la versión anterior de beautifulsoup4 no podían cargarse en la versión actual de la biblioteca. Esto no es ninguna sorpresa, es lo normal. La sorpresa es que estuviera serializando objetos beautifulsoup4 de forma inadvertida.

Leer más…

En Mi IoT ha muerto: Cómo actualizar una instalación LUA sobre ESP8266 para que sea compatible con TLS 1.2 explico que he tenido que compilar una versión nueva de NodeMCU (Lua) para un ESP8266.

Tengo el tema olvidado porque ahora utilizo MicroPython y microcontroladores más capaces, como ESP32 o RP2040 (Raspberry Pi Pico). En su momento usaba una zona SmartOS con personalidad Debian para estas cosas, pero en 2024 hay opciones más sencillas.

El procedimiento que yo he usado está documentado en el manual de NodeMCU y usa Docker: https://github.com/marcelstoer/docker-nodemcu-build.

Los cambios que he hecho:

Leer más…

En Medir y registrar temperatura, humedad relativa y presión atmosférica con un ESP8266: el componente LUA realizo un montaje doméstico para monitorizar la temperatura y humedad de mi casa. Ese montaje ha estado funcionando, sin apenas variaciones y sin incidencias, desde 2016. Casi ocho años. No está mal.

El problema es que acabo de actualizar las zonas SmartOS de mis servidores a la versión 2023.4.0 y casi todos mis dispositivos IoT han dejado de enviar datos.

La investigación ha sido interesante. La cosa ha ido así:

Leer más…

La solución propuesta en Por qué es conveniente usar NSEC3 en vez de NSEC en un dominio DNSSEC define NSEC3PARAM ya sea en el fichero de zona o utilizando rndc signing -nsec3param.

Este enfoque tiene un problema serio: ocasionalmente el signed o el journal de BIND se corrompen y hay que borrarlos. No parece grave porque BIND vuelve a regenerar esos ficheros pero... la configuración NSEC3PARAM se pierde. Y si BIND pierde la configuración NSEC3PARAM deja de servir NSEC3 y la zona pasa a ser NSEC... y no te enteras.

Tras ocurrirme un par de veces decidí ver qué estaba haciendo mal.

Leer más…

No me gusta Meetup por muchos motivos, pero es un hecho que es la plataforma mayoritaria para organizar reuniones, al menos en las comunidades tecnológicas en las que estoy involucrado. Es curioso, precisamente las comunidades que tendrían capacidad técnica para no tener que depender de Meetup...

En fin, la humanidad es así.

Así que no me queda otra que tener automatismos que consumen datos extraídos de Meetup, como los calendarios de los encuentros. Hay grupos que requieren ser miembro para acceder a sus detalles, pero la mayoría están más que encantados de que sus reuniones sean públicas y se les dé difusión.

Todo fue bien hasta la primavera de 2023, cuando Meetup pasó a requerir acceso autenticado para poder acceder a todos los calendarios.

Les escribí varios correos electrónicos que no tuvieron ningún tipo de respuesta (¿se trataba de un error?), consulté el asunto en varios foros técnicos y todo el mundo estaba igual de perdido. La única alternativa que se proponía era hacer scraping a lo bruto de la web, lo cual es bastante fácil, ciertamente, pero me parecía una solución poco elegante y bastante frágil. La última opción.

En mi caso, preferir no utilizar un acceso autenticado no es una cuestión de privacidad sino de sencillez de programación. Puestos a programar y mantener un scraper, podía echarle un ojo a la autenticación en Meetup, que es bastante más complicada que simplemente enviar una cabecera HTTP.

Leer más…

This post transcribes some emails I sent to several mailing lists:

The initial email was sent to the Kafka User mailing list:

Reply-To: users@kafka.apache.org
Message-ID: <92aa6286-d875-04ed-6205-9e4a8fe3a1a1@jcea.es>
Date: Thu, 9 Nov 2023 03:37:39 +0100
To: users@kafka.apache.org
From: Jesus Cea <jcea@jcea.es>
Subject: How to get a X509 broker certificate with "openssl s_client"?

I am trying to remotely access to the brokers certificates (for audit
purposes, expiration alarms, etc) using this command:

"""
openssl s_client -showcerts -connect localhost:9092
"""

The connection is correctly established, but something is wrong. The TLS
session is has some errors at the beginning, but it success at the end:

"""
[jcea@Kafka ~]$ openssl s_client -showcerts -connect localhost:9092
CONNECTED(00000004)
1:error:1408F119:SSL routines:ssl3_get_record:decryption failed or bad
record mac:ssl/record/ssl3_record.c:676:
---
no peer certificate available
---
No client certificate CA names sent
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 1696 bytes and written 300 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
"""

I tried too writing a tiny TLS client in Python, same result, raising
this exception: "ssl.SSLError: [SSL:
DECRYPTION_FAILED_OR_BAD_RECORD_MAC] decryption failed or bad record mac
(_ssl.c:992)".

I guess there is some kind of preamble before TLS negotiation.

Is that documented somewhere?. How can I check remotely the brokers'
certificates?

Thanks.

Leer más…

Cuando un cliente se conecta a un servidor SSH, normalmente le propondrá todas las identidades SSH presentes en el servicio SSH Agent. Esto no está necesariamente mal, pero tiene algunos problemas:

• El servidor SSH puede tener un número de reintentos limitado y nosotros podemos tener muchas identidades SSH que ofrecer.
• A veces queremos tener nuestras personalidades online separadas y es preferible ofrecer al servidor SSH una identidad concreta controlada en vez de informarle de todas nuestras identidades disponibles para que elija la que le sirva. Un servidor malicioso podría vincular personalidades SSH e identificarnos como la misma persona física en diferentes entornos que preferimos mantener separados.

Los pasos a seguir con OpenSSH son sencillos:

1. Creamos una nueva identidad SSH para un servicio concreto. Para eso se usa el comando ssh-keygen.

2. Configuramos en ~/.ssh/config un perfil para ese servicio con estos parámetros:

   # "IdentitiesOnly yes" indica que solo debemos ofrecer
   # esa personalidad, aunque el SSH-Agent tenga más.
   IdentitiesOnly yes
   IdentityFile PATH_A_LA_IDENTIDAD_SSH
   

Cuando nos conectemos al servidor usando ese perfil, el cliente SSH solo ofrecerá esa identidad.

Podemos verificar que todo está funcionando bien conectando a ese servicio con ssh -v y viendo qué identidades estamos ofreciendo al servidor.

En una máquina con sistema operativo basado en Illumos, como un SmartOS, podemos ver los detalles de un dispositivo NVMe con el comando nvmeadm. Por ejemplo:

[root@tmz1 ~]# nvmeadm list
nvme0: model: Samsung SSD 980 PRO 1TB, serial: S5GXNF0W922518D, FW rev: 5B2QGXA7, NVMe v1.3
  nvme0/1 (c2t002538B931C60571d0): Size = 931.51 GB, Capacity = 931.51 GB, Used = 7.83 GB
nvme1: model: Samsung SSD 980 PRO 1TB, serial: S5GXNF0W920592A, FW rev: 5B2QGXA7, NVMe v1.3
  nvme1/1 (c3t002538B931C5FDEBd0): Size = 931.51 GB, Capacity = 931.51 GB, Used = 7.83 GB

[root@tmz1 ~]# nvmeadm list-logpages nvme0
DEVICE  NAME              SCOPE         FIELDS    DESC
nvme0   error             controller    rae       Error information
nvme0   health            controller,   rae       SMART / Health information
                          namespace
nvme0   firmware          nvm           --        Firmware Slot Information
nvme0   cmdeff            controller    --        commands supported and effects

[root@tmz1 ~]# nvmeadm -v get-logpage nvme0 health
nvme0: SMART/Health Information
  Critical Warnings
    Available Space:                        OK
    Temperature:                            OK
    Device Reliability:                     OK
    Media:                                  OK
    Volatile Memory Backup:                 OK
  Temperature:                              35C
  Available Spare Capacity:                 100%
  Available Spare Threshold:                10%
  Device Life Used:                         0%
  Data Read:                                0GB
  Data Written:                             7GB
  Read Commands:                            27859
  Write Commands:                           42000
  Controller Busy:                          0min
  Power Cycles:                             10
  Power On:                                 11581h
  Unsafe Shutdowns:                         4
  Uncorrectable Media Errors:               0
  Errors Logged:                            0
  Warning Composite Temperature Time:       0min
  Critical Composite Temperature Time:      0min
  Temperature Sensor 1:                     35C
  Temperature Sensor 2:                     47C
  Thermal Management Temp 1 Transition Count: 0
  Thermal Management Temp 2 Transition Count: 0
  Time for Thermal Management Temp 1:       0sec
  Time for Thermal Management Temp 2:       0sec

Se pueden hacer muchas cosas, como un borrado seguro del NVMe, actualizar el firmware. Puedes ver las opciones disponibles revisando el manual con man nvmeadm.