AnyConnect se ongeldige TLS-weergawe op Linux: bepaal eers die omvang van die oplossing

Hierdie fout verskyn voor die wagwoordprompt, en dit is die nuttige deel: nog niks het geauthentiseer nie, dus is aanmeldgegewens nie die probleem nie. Op Linux kan dieselfde AnyConnect-dialoog uit ’n ou protokolweergawe, ’n 1024-bis-sleuteluitruilgroep of ’n syferset wat die stelsel se kriptobeleid weier, kom. Ek het dit op drie masjiene op drie verskillende maniere opgelos, en wat daardie oplossings onderskei, is die omvang van die impak, nie die vernuf nie. Elkeen is op die regte plek verdedigbaar en op elke ander plek ’n slegte verstek.

Lees die boodskap voordat jy aan die beleid raak

Hou die presiese string uit die dialoog. ’n Weergaweklag wys op die protokolvlak, ’n sertifikaatklag wys op vertroue of naamgewing, en ’n mislukte aanmelding wys op aanmeldgegewens. ’n Gateway wat TLS 1.0 met ’n 1024-bis DHE-groep, AES-256-CBC en ’n SHA-1-handtekening bied, kan ’n heeltemal geldige sertifikaat hê en steeds deur ’n moderne beleid verwerp word voordat jou aanmeldgegewens ooit gestuur word.

Toets die eindpunt met die stelsel se OpenSSL, met die werklike gasheernaam en die poort wat die kliënt gebruik.

As openssl s_client -connect vpn.example.com:443 -servername vpn.example.com misluk terwyl -tls1 -cipher DEFAULT@SECLEVEL=0 slaag, wys dit dat die grens weergawe en sleutelgrootte saam is. As die eerste opdrag ’n klein DH-sleutel eerder as ’n protokolwaarskuwing rapporteer, is die weergawe reg en kort net die groep aandag. Moet nooit ’n private sleutel of ’n wagwoord in die toets stop nie.

Opsie 1: verslap die hele gasheer met die kriptobeleid

Op Fedora en RHEL 8 en 9 verlaag update-crypto-policies --set LEGACY OpenSSL se stelselbeleid, en update-crypto-policies --show bevestig wat aktief is. Dit herstel gewoonlik die tonnel, maar die beleid word gelees wanneer ’n proses begin, so herbegin die kliënt en enige hulpproses wat dit geskep het voordat jy weer toets. Dit laat ook ouer protokolle en swakker groepe toe vir elke TLS-kliënt op die masjien, van die blaaier in die volgende venster tot die pakketbestuurder wat die kern opdateer.

Daardie breedte is die hele punt en die hele probleem. LEGACY is gasheervyd, blywend en maklik om te vergeet, so dit moet ’n diagnostiese stap of ’n gedokumenteerde uitsondering op ’n bestuurde bou wees, nooit ’n werkstasie se russtand nie. Ek het een gesien wat twee jaar lank op LEGACY gebly het omdat ’n enkele interne portaal dit nodig gehad het, en niemand kon sê wanneer dit begin het nie.

Debian en Ubuntu het geen enkele skakelaar hiervoor nie. Die ekwivalent is ’n wysiging aan /etc/ssl/openssl.cnf wat ’n laer MinProtocol en CipherString = DEFAULT@SECLEVEL=0 in die stelselverstek-afdeling stel. Dieselfde omvang, ander lêer, effens makliker om tydens ’n vrystellingsopgradering uit die oog te verloor.

Opsie 2: een konfigurasielêer vir een kliënt

’n OpenSSL-konfigurasie per proses hou die verandering binne een prosesboom, maar net as die lêer bedraad is soos die biblioteek verwag. Om ’n ssl_conf-afdeling te noem, is nie genoeg nie: OpenSSL lees die topvlak openssl_conf-sleutel, volg dit na ’n inisafdeling en bereik eers dan die SSL-verstekke.

openssl_conf = openssl_init

[openssl_init]
ssl_conf = ssl_sect

[ssl_sect]
system_default = system_default_sect

[system_default_sect]
MinProtocol = TLSv1.0
CipherString = DEFAULT@SECLEVEL=0

Wys OPENSSL_CONF na daardie lêer en begin die VPN-kliënt deur ’n omhulsel wat dit uitvoer. Alles anders op die gasheer behou die verstekbeleid, en dit is die eienskap wat saak maak wanneer die nakomingsvraag opduik. Bevestig dat die lêer werklik in werking is voordat jy die gateway blameer: OPENSSL_CONF=/path/to/file openssl ciphers -s -tls1 moet TLS 1.0-syfers lys, en ’n leë resultaat beteken die ketting is gebreek en die kliënt het stilweg die stelselverstekke behou.

Die lêer is weergawesensitief. OpenSSL 1.1.1 en 3.x aanvaar dieselfde afdelingsname, maar die hantering van voorskrifte rondom verskaffers het in 3.x verander, so verifieer met die kliënt se eie log en ’n toetshanddruk eerder as om aan te neem die lêer is gelees. ’n Drukfout in die afdelingsnaam faal oop, en die kliënt gebruik stilweg die stelselverstekke.

Die beperking is dekking. Enigiets wat teen GnuTLS of NSS gekoppel is, ignoreer OPENSSL_CONF, en so ook enige hulpproses wat die kliënt skep sonder om die omgewing te erf. Kyk met ldd watter TLS-biblioteek die binêre lêer werklik koppel voordat jy die omhulsel bou, want die antwoord bepaal of hierdie opsie hoegenaamd bestaan.

Opsie 3: ’n weggooibare VM of houer

Vir ’n kontrakteur wat twee weke lank een ou gateway tref, is ’n toegewyde VM met die verslapte beleid ’n skoner grens as die werkstasie. Die ou oppervlak en die daaglikse blaaierprofiel deel nie meer ’n kernbeleid nie, en wegdoening is ’n verwydering eerder as ’n ouditbevinding.

Dit is steeds ’n netwerkmasjien, so beperk sy toegang en hou dit uit algemene blaai. Die onderhoudskoste is nog ’n beeld om te pleister, wat werklik maar beperk en sigbaar is, anders as ’n vergete LEGACY-vlag op ’n skootrekenaar.

Wat die vergelyking jou laat

Kies op drie vrae: wie het die ou protokol nodig, vir hoe lank, en wie sal agterkom as die uitsondering sy rede oorleef. Een toepassing, een persoon, ’n paar dae, wys op die konfigurasie per proses. ’n Hele vloot agter een toestel wys op die gateway self. Enigiets wat ’n permanente LEGACY-gasheerbeleid nodig het, is ’n verkrygingsbesluit in ’n tegniese kostuum.

Die duursame oplossing hoort op die toestel: TLS 1.2 of later, ’n groep van minstens 2048 bis, ’n AEAD-syfer en ’n sertifikaat met ’n moderne handtekening. Vra die eienaar van die toestel vir daardie verandering en bevestig dan die onderhandelde weergawe en syfer in die kliënt se log. Skryf die uitsondering neer met die gasheer, die gateway, die onderhandelde protokol, die goedkeurder en ’n vervaldatum, want die nota is wat verhoed dat ’n tydelike oplossing die verstek word.