AnyConnectin laiton TLS-versio Linuxissa: rajaa korjauksen laajuus ensin

Tämä virhe tulee ennen salasanakehotetta, ja se on hyödyllinen osa: mitään ei ole vielä todennettu, joten tunnukset eivät ole ongelma. Linuxissa sama AnyConnect-valintaikkuna voi tulla vanhasta protokollaversiosta, 1024-bittisestä avaimenvaihtoryhmästä tai salauspaketista, jonka järjestelmän salauskäytäntö hylkää. Olen poistanut sen kolmella eri tavalla kolmella koneella, ja näitä korjauksia erottaa vaikutusalue, ei nokkeluus. Kukin on perusteltu oikeassa paikassa ja huono oletus kaikkialla muualla.

Lue viesti ennen kuin kosket käytäntöön

Säilytä valintaikkunan tarkka merkkijono. Versiovalitus viittaa protokollakerrokseen, sertifikaattivalitus luottamukseen tai nimeämiseen ja epäonnistunut kirjautuminen tunnuksiin. Yhdyskäytävä, joka tarjoaa TLS 1.0:n 1024-bittisellä DHE-ryhmällä, AES-256-CBC:llä ja SHA-1-allekirjoituksella, voi omata täysin kelvollisen sertifikaatin ja silti nykyaikainen käytäntö hylkää sen ennen kuin tunnuksiasi edes lähetetään.

Testaa päätepiste järjestelmän OpenSSL:llä käyttäen todellista isäntänimeä ja porttia, jota asiakasohjelma käyttää.

Kun openssl s_client -connect vpn.example.com:443 -servername vpn.example.com epäonnistuu mutta -tls1 -cipher DEFAULT@SECLEVEL=0 onnistuu, raja on versio ja avaimen koko yhdessä. Jos ensimmäinen komento ilmoittaa pienestä DH-avaimesta protokollahälytyksen sijaan, versio on kunnossa ja vain ryhmä vaatii huomiota. Älä koskaan laita yksityistä avainta tai salasanaa testiin.

Vaihtoehto 1: löysennä koko isäntää salauskäytännöllä

Fedorassa ja RHEL 8 ja 9:ssä update-crypto-policies --set LEGACY laskee OpenSSL:n järjestelmäkäytäntöä ja update-crypto-policies --show vahvistaa, mikä on aktiivinen. Se yleensä palauttaa tunnelin, mutta käytäntö luetaan prosessin käynnistyessä, joten käynnistä asiakasohjelma ja kaikki sen luomat apuprosessit uudelleen ennen uutta testiä. Se sallii myös vanhemmat protokollat ja heikommat ryhmät jokaiselle koneen TLS-asiakkaalle, viereisen ikkunan selaimesta ytimen päivittävään paketinhallintaan.

Tämä laajuus on koko tarkoitus ja koko ongelma. LEGACY koskee koko isäntää, on pysyvä ja helposti unohtuva, joten sen pitäisi olla diagnoosivaihe tai dokumentoitu poikkeus hallitussa kokoonpanossa, ei koskaan työaseman lepotila. Olen nähnyt yhden, joka pysyi LEGACY:ssä kaksi vuotta, koska yksi sisäinen portaali tarvitsi sitä, eikä kukaan osannut sanoa, milloin se alkoi.

Debianissa ja Ubuntussa ei ole yhtä kytkintä tähän. Vastine on /etc/ssl/openssl.cnf:n muutos, joka asettaa järjestelmän oletusarvojen osiossa matalamman MinProtocol:n ja CipherString = DEFAULT@SECLEVEL=0:n. Sama vaikutusalue, eri tiedosto, hieman helpompi kadottaa näkyvistä julkaisupäivityksen aikana.

Vaihtoehto 2: yksi asetustiedosto yhdelle asiakkaalle

Prosessikohtainen OpenSSL-asetus pitää muutoksen yhden prosessipuun sisällä, mutta vain jos tiedosto on kytketty niin kuin kirjasto odottaa. Osion ssl_conf nimeäminen ei riitä: OpenSSL lukee ylätason avaimen openssl_conf, seuraa sitä alustusosioon ja saavuttaa vasta sitten SSL:n oletusarvot.

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

Osoita OPENSSL_CONF tuohon tiedostoon ja käynnistä VPN-asiakasohjelma kääreen kautta, joka vie sen ympäristöön. Kaikki muu isännässä säilyttää oletuskäytännön, ja juuri se ominaisuus ratkaisee, kun vaatimustenmukaisuuskysymys tulee. Vahvista, että tiedosto todella vaikuttaa, ennen kuin syytät yhdyskäytävää: OPENSSL_CONF=/path/to/file openssl ciphers -s -tls1:n pitäisi luetella TLS 1.0 -salaukset, ja tyhjä tulos tarkoittaa, että ketju on katkennut ja asiakasohjelma on hiljaa säilyttänyt järjestelmän oletusarvot.

Tiedosto on versiokohtainen. OpenSSL 1.1.1 ja 3.x hyväksyvät samat osioiden nimet, mutta direktiivien käsittely palveluntarjoajien ympärillä muuttui versiossa 3.x, joten tarkista asiakasohjelman omasta lokista ja testikättelystä sen sijaan, että olettaisit tiedoston tulleen luetuksi. Kirjoitusvirhe osion nimessä epäonnistuu avoimesti, ja asiakasohjelma käyttää hiljaa järjestelmän oletusarvoja.

Raja on kattavuus. Kaikki GnuTLS:ään tai NSS:ään linkitetty jättää OPENSSL_CONF:n huomiotta, samoin jokainen apuprosessi, jonka asiakasohjelma käynnistää perimättä ympäristöä. Tarkista ldd:lla, mihin TLS-kirjastoon binääri todella linkittyy, ennen kuin rakennat kääreen, sillä vastaus ratkaisee, onko tätä vaihtoehtoa lainkaan olemassa.

Vaihtoehto 3: kertakäyttöinen VM tai kontti

Urakoitsijalle, joka kahden viikon ajan hakkaa yhtä vanhaa yhdyskäytävää, löysennetyllä käytännöllä varustettu oma VM on siistimpi raja kuin työasema. Vanha pinta ja jokapäiväinen selainprofiili lakkaavat jakamasta ydin käytäntöä, ja hävittäminen on poisto, ei auditoinnin havainto.

Se on yhä verkossa oleva kone, joten rajaa sen pääsy ja pidä se poissa yleisselailusta. Ylläpitokustannus on yksi lisäkuva paikattavaksi, mikä on todellista mutta rajattua ja näkyvää, toisin kuin kannettavaan unohdettu LEGACY-lippu.

Mitä vertailu jättää sinulle

Valitse kolmen kysymyksen perusteella: kuka tarvitsee vanhaa protokollaa, kuinka kauan ja kuka huomaa, jos poikkeus elää syynsä pidempään. Yksi sovellus, yksi henkilö, muutama päivä osoittavat prosessikohtaiseen asetukseen. Koko laivasto yhden laitteen takana osoittaa itse yhdyskäytävään. Kaikki, mikä vaatii pysyvän LEGACY-isäntäkäytännön, on hankintapäätös teknisessä asussa.

Kestävä korjaus kuuluu laitteelle: TLS 1.2 tai uudempi, vähintään 2048-bittinen ryhmä, AEAD-salaus ja nykyaikaisella allekirjoituksella varustettu sertifikaatti. Pyydä tätä muutosta laitteen omistajalta ja vahvista sitten neuvoteltu versio ja salaus asiakasohjelman lokista. Kirjaa poikkeus isännän, yhdyskäytävän, neuvotellun protokollan, hyväksyjän ja vanhenemispäivän kanssa, sillä juuri se muistiinpano estää väliaikaista kiertotietä muuttumasta oletukseksi.