Un par antiguo fuerza TLS 1.0: acote la excepción, no el host

Aparece un dispositivo antiguo, no logra conectarse, y la reparación que parece más rápida es debilitar todo el host hasta que la conexión funcione. Ese intercambio es invisible en el momento y permanente en la práctica, porque nadie retira un mínimo que por fin funciona. Dos fallos muy distintos crean la presión, y solo uno de ellos tiene que ver con cifrados. Ordene primero el fallo y después coloque la excepción donde no pueda propagarse.

Divida el fallo en dos antes de editar una directiva

Una línea del registro del servidor sobre la ausencia de un cifrado compartido, o sobre una versión de protocolo no admitida, viene del canal de control: los dos extremos no lograron ponerse de acuerdo sobre cómo proteger la propia negociación. En cambio, la línea del cliente que dice que no hay ningún método de verificación del certificado del servidor habilitado viene de otro sitio por completo, porque ese cliente no comprueba en absoluto quién respondió. Cambiar un cifrado de datos no sirve para el segundo caso, y añadir una comprobación de rol no sirve para el primero.

Tome la primera línea de fallo de cada lado en lugar de la última antes de la desconexión, porque la última suele ser una consecuencia. Después establezca qué archivo abrió realmente el cliente: un perfil importado suele existir dos veces con nombres de visualización distintos, y editar la copia que nadie lee produce un no-cambio convincente. Un proceso en ejecución conserva la configuración con la que arrancó, así que un archivo guardado no es un archivo cargado. Los comandos de abajo muestran la negociación del cliente junto a la visión del servidor del mismo intento.

openvpn --config <profile>.ovpn --verb 4 2>&1 | head -n 40
journalctl -u [email protected] --since '-10 min' | grep -iE 'cipher|tls|verify'

Un segundo listener es el lugar honesto para un mínimo más débil

Cuando el dispositivo llega como máximo a TLS 1.0 con un canal de datos anterior a 2.5, el servidor debe ofrecer un mínimo más bajo para el canal de control y un cifrado de datos que el cliente antiguo reconozca. La directiva de reserva existe precisamente para ese par, mientras que la lista de cifrados mantiene a los clientes modernos en conjuntos modernos. Ambas directivas pertenecen al listener y no a un usuario o una conexión, y ninguna opción por cliente las estrecha después. Por eso un solo dispositivo antiguo en el puerto principal es una decisión sobre todos los pares que lo comparten.

Donde la plataforma lo permita, ejecute el listener antiguo como su propia instancia en un puerto separado, permita ese puerto solo desde la dirección del dispositivo y deje el servicio principal en paz. Anote por qué existe el segundo listener, en el archivo que lleva su configuración, porque una limpieza futura lo leerá si no como restos. La separación solo vale la pena si el mínimo más débil termina donde termina el dispositivo.

tls-version-min 1.0
data-ciphers AES-128-GCM:AES-256-GCM:AES-256-CBC
data-ciphers-fallback AES-256-CBC

Qué rompe en realidad un certificado antiguo del proveedor

El error de verificación es una vinculación de rol que falta: sin ella el cliente aceptará cualquier certificado que enlace con una CA de confianza, se haya emitido o no para un servidor. Vincule primero el certificado al rol de servidor y trate la vinculación como un requisito, no como un botón de ajuste. Solo un perfil que sigue fallando después de ese paso tiene un problema real de certificado.

Un certificado antiguo del proveedor cuyo tamaño de clave o algoritmo de firma ya no satisface la política predeterminada de OpenSSL es el caso de un cambio acotado del nivel de seguridad en el canal de control. Bajar el nivel allí no desactiva la verificación, y nunca debe combinarse con una CA vacía, una configuración de verificación desactivada o un nombre de host sin comprobar. Mantenga la línea dentro del único perfil que la necesita; exportar globalmente una configuración de OpenSSL relajada daría la misma relajación a cada programa de la máquina.

remote-cert-tls server
tls-cipher "DEFAULT:@SECLEVEL=0"

Lea los valores negociados, no el cartel

Con verbosidad 4 ambos extremos imprimen la versión de TLS y el cifrado del canal de control que acordaron, y el cifrado de datos de la sesión. Lea esas líneas en lugar del cartel de inicialización, que informa de éxito y no de sus condiciones. Luego vuelva a conectar un cliente moderno al listener principal y confirme que sigue cayendo en un conjunto moderno, porque una excepción que se filtró a la configuración compartida se ve aquí primero. Los valores que copie se convierten en la línea base para la próxima revisión.

Pruebe el dispositivo antiguo por separado: debería conectarse y debería ser la única sesión de los registros que muestra los parámetros más débiles. Si un segundo par también negocia el conjunto antiguo, la excepción es más amplia de lo previsto y la separación del listener no ocurrió de verdad. Anote las dos observaciones y no solo la conclusión.

Toda excepción necesita un propietario y una fecha

Una excepción sin condición de retirada se convierte en silencio en el valor predeterminado, así que ponga el dispositivo, el propietario, el motivo y la fecha en que desaparece junto a la configuración que justifica. Sin esa línea, el mínimo más débil sobrevive al hardware que lo necesitaba.

Sustituir el cliente, o pedir al proveedor un perfil actual, es el resultado al que hay que aspirar; la excepción es un aplazamiento y no un diseño. Cuando el dispositivo se retire, elimine el listener y el perfil en el mismo cambio para que no quede ninguna mitad funcionando. Nada de esto hace seguros los parámetros antiguos, solo evita que el límite de un dispositivo se convierta en la base de todos.