Un par vello forza TLS 1.0: acoute a excepción, non o host

Aparece un dispositivo vello, non logra conectarse, e a reparación que parece máis rápida é debilitar todo o host ata que a conexión funcione. Ese intercambio é invisible no momento e permanente na práctica, porque ninguén retira un mínimo que por fin funciona. Dous fallos moi distintos crean a presión, e só un deles ten que ver con cifrados. Ordene primeiro o fallo e despois coloque a excepción onde non poida propagarse.

Divida o fallo en dous antes de editar unha directiva

Unha liña do rexistro do servidor sobre a ausencia dun cifrado compartido, ou sobre unha versión de protocolo non admitida, vén da canle de control: os dous extremos non lograron poñerse de acordo sobre como protexer a propia negociación. En cambio, a liña do cliente que di que non hai ningún método de verificación do certificado do servidor habilitado vén doutro sitio por completo, porque ese cliente non comproba en absoluto quen respondeu. Cambiar un cifrado de datos non serve para o segundo caso, e engadir unha comprobación de rol non serve para o primeiro.

Tome a primeira liña de fallo de cada lado en lugar da última antes da desconexión, porque a última adoita ser unha consecuencia. Despois estableza que ficheiro abriu realmente o cliente: un perfil importado adoita existir dúas veces con nomes de visualización distintos, e editar a copia que ninguén le produce un non-cambio convincente. Un proceso en execución conserva a configuración coa que arrincou, así que un ficheiro gardado non é un ficheiro cargado. Os comandos de abaixo mostran a negociación do cliente xunto á visión do servidor do mesmo 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 é o lugar honesto para un mínimo máis feble

Cando o dispositivo chega como máximo a TLS 1.0 cunha canle de datos anterior a 2.5, o servidor debe ofrecer un mínimo máis baixo para a canle de control e un cifrado de datos que o cliente vello recoñeza. A directiva de reserva existe precisamente para ese par, mentres que a lista de cifrados mantén os clientes modernos en conxuntos modernos. Ambas as directivas pertencen ao listener e non a un usuario ou unha conexión, e ningunha opción por cliente as estreita despois. Por iso un só dispositivo vello no porto principal é unha decisión sobre todos os pares que o comparten.

Onde a plataforma o permita, execute o listener vello como a súa propia instancia nun porto separado, permita ese porto só desde o enderezo do dispositivo e deixe o servizo principal en paz. Anote por que existe o segundo listener, no ficheiro que leva a súa configuración, porque unha limpeza futura lerá senón como restos. A separación só paga a pena se o mínimo máis feble remata onde remata o dispositivo.

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

Que rompe en realidade un certificado vello do provedor

O erro de verificación é unha vinculación de rol que falta: sen ela o cliente aceptará calquera certificado que encadee cunha CA de confianza, emitísese ou non para un servidor. Vincule primeiro o certificado ao rol de servidor e trate a vinculación como un requisito, non como un botón de axuste. Só un perfil que segue fallando despois dese paso ten un problema real de certificado.

Un certificado vello do provedor cuxo tamaño de chave ou algoritmo de sinatura xa non satisfai a política predeterminada de OpenSSL é o caso dun cambio acoutado do nivel de seguridade na canle de control. Baixar o nivel alí non desactiva a verificación, e nunca debe combinarse cunha CA baleira, unha configuración de verificación desactivada ou un nome de host sen comprobar. Manteña a liña dentro do único perfil que a necesita; exportar globalmente unha configuración de OpenSSL relaxada daría a mesma relaxación a cada programa da máquina.

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

Lea os valores negociados, non o cartel

Con verbosidade 4 ambos os extremos imprimen a versión de TLS e o cifrado da canle de control que acordaron, e o cifrado de datos da sesión. Lea esas liñas en lugar do cartel de inicialización, que informa de éxito e non das súas condicións. Despois volva conectar un cliente moderno ao listener principal e confirme que segue caendo nun conxunto moderno, porque unha excepción que se filtrou á configuración compartida vese aquí primeiro. Os valores que copie convértense na liña base para a próxima revisión.

Probe o dispositivo vello por separado: debería conectarse e debería ser a única sesión dos rexistros que mostra os parámetros máis febles. Se un segundo par tamén negocia o conxunto vello, a excepción é máis ampla do previsto e a separación do listener non ocorreu de verdade. Anote as dúas observacións e non só a conclusión.

Toda excepción necesita un propietario e unha data

Unha excepción sen condición de retirada convértese en silencio no valor predeterminado, así que poña o dispositivo, o propietario, o motivo e a data en que desaparece xunto á configuración que xustifica. Sen esa liña, o mínimo máis feble sobrevive ao hardware que o necesitaba.

Substituír o cliente, ou pedir ao provedor un perfil actual, é o resultado ao que hai que aspirar; a excepción é un aprazamento e non un deseño. Cando o dispositivo se retire, elimine o listener e o perfil no mesmo cambio para que non quede ningunha metade funcionando. Nada disto fai seguros os parámetros vellos, só evita que o límite dun dispositivo se converta na base de todos.