Un parell antic força TLS 1.0: acoteu l'excepció, no l'amfitrió

Apareix un dispositiu antic, no es pot connectar, i la reparació que sembla més ràpida és afeblir tot l'amfitrió fins que la connexió funcioni. Aquest intercanvi és invisible en el moment i permanent a la pràctica, perquè ningú no treu un mínim que finalment funciona. Dues falles molt diferents creen la pressió, i només una té a veure amb xifradors. Ordeneu primer la falla i després poseu l'excepció on no es pugui propagar.

Dividiu la falla en dues abans d'editar una directiva

Una línia del registre del servidor sobre l'absència d'un xifrador compartit, o sobre una versió de protocol no suportada, ve del canal de control: els dos extrems no es van poder posar d'acord sobre com protegir la negociació mateixa. En canvi, la línia del client que diu que no hi ha cap mètode de verificació del certificat del servidor habilitat ve d'un altre lloc, perquè aquell client no comprova gens qui ha respost. Canviar un xifrador de dades no fa res per al segon cas, i afegir una comprovació de rol no fa res per al primer.

Agafeu la primera línia de falla de cada costat, no l'última abans de la desconnexió, perquè l'última sol ser una conseqüència. Després establiu quin fitxer ha obert realment el client: un perfil importat sovint existeix dues vegades amb noms de visualització diferents, i editar la còpia que ningú no llegeix produeix un no-canvi convincent. Un procés en execució conserva la configuració amb què va arrencar, així que un fitxer desat no és un fitxer carregat. Les ordres de sota mostren la negociació del client al costat de la visió del servidor del mateix intent.

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

Un segon listener és el lloc honest per a un mínim més feble

Quan el dispositiu arriba com a màxim a TLS 1.0 amb un canal de dades anterior a 2.5, el servidor ha d'oferir un mínim més baix per al canal de control i un xifrador de dades que el client antic reconegui. La directiva de reserva existeix precisament per a aquest parell, mentre que la llista de xifradors manté els clients moderns en conjunts moderns. Totes dues directives pertanyen al listener i no a un usuari o una connexió, i cap opció per client les estreny després. Per això un sol dispositiu antic al port principal és una decisió sobre tots els parells que el comparteixen.

On la plataforma ho permeti, executeu el listener antic com a instància pròpia en un port separat, permeteu aquell port només des de l'adreça del dispositiu i deixeu el servei principal tranquil. Anoteu per què existeix el segon listener, al fitxer que en porta la configuració, perquè una neteja futura sinó el llegirà com a deixalles. La separació només val la pena si el mínim més feble acaba on acaba el dispositiu.

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

Què trenca realment un certificat antic del proveïdor

L'error de verificació és una vinculació de rol que falta: sense ella el client acceptarà qualsevol certificat que encadeni amb una CA de confiança, tant si es va emetre per a un servidor com si no. Vinculeu primer el certificat al rol de servidor i tracteu la vinculació com un requisit, no com un botó d'ajust. Només un perfil que encara falla després d'aquest pas té un problema real de certificat.

Un certificat antic del proveïdor la mida de clau o l'algorisme de signatura del qual ja no satisfà la política per defecte d'OpenSSL és el cas d'un canvi acotat del nivell de seguretat al canal de control. Baixar el nivell allà no desactiva la verificació, i no s'ha de combinar mai amb una CA buida, una configuració de verificació desactivada o un nom d'amfitrió no comprovat. Mantingueu la línia dins de l'únic perfil que la necessita; exportar globalment una configuració OpenSSL relaxada donaria la mateixa relaxació a cada programa de la màquina.

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

Llegiu els valors negociats, no la pancarta

Amb verbositat 4, tots dos extrems imprimeixen la versió de TLS i el xifrador del canal de control que han acordat, i el xifrador de dades de la sessió. Llegiu aquestes línies i no la pancarta d'inicialització, que informa d'èxit i no de les seves condicions. Després torneu a connectar un client modern al listener principal i confirmeu que encara cau en un conjunt modern, perquè una excepció que s'ha filtrat a la configuració compartida es veu aquí primer. Els valors que copieu esdevenen la línia base per a la propera revisió.

Proveu el dispositiu antic tot sol: s'ha de connectar i ha de ser l'única sessió dels registres que mostra els paràmetres més febles. Si un segon parell també negocia el conjunt antic, l'excepció és més àmplia del que es pretenia i la separació del listener no s'ha produït de veritat. Anoteu les dues observacions i no només la conclusió.

Cada excepció necessita un propietari i una data

Una excepció sense condició de retirada es converteix silenciosament en el valor per defecte, així que poseu el dispositiu, el propietari, el motiu i la data en què desapareix al costat de la configuració que justifica. Sense aquesta línia, el mínim més feble sobreviu al maquinari que el necessitava.

Substituir el client, o demanar al proveïdor un perfil actual, és el resultat a què cal aspirar; l'excepció és un ajornament i no un disseny. Quan el dispositiu es retiri, traieu el listener i el perfil en el mateix canvi perquè no en quedi cap meitat funcionant. Res d'això fa segurs els paràmetres antics, només evita que el límit d'un dispositiu esdevingui la base de tothom.