0x vai 0s? PSK-muodon lukeminen tiedostosta ipsec.secrets

Yksi asiakas todennetaan jaetulla avaimella ja toinen hylkää sen, vaikka liittämäsi merkit näyttävät molemmilla puolilla samoilta. Ne ovat luultavasti samat merkit; ero on siinä, mitä purkusääntöä tiedosto niihin soveltaa. Lainausmerkeissä oleva merkkijono otetaan kirjaimellisesti, 0x alkava token luetaan heksadesimaalina ja 0s alkava token luetaan Base64-muodossa. Vain yksi noista kolmesta kirjoitusasusta tarkoittaa sitä, mitä tarkoitit, joten korjaus on yleensä muunnos eikä parempi salasana.

Oire osoittaa koodaukseen, ei salauksiin

Kun kaksi päätä pitävät eri tavuja, neuvottelu onnistuu silti ja todiste epäonnistuu sen jälkeen. Loki ilmoittaa silloin eheys- tai HMAC-virheestä algoritmien eroavuuden sijaan, koska ehdotus valittiin eikä todennusvaihe vastannut. Se rivi ei koskaan mainitse salaisuuden muotoa.

Vaihe on vihje. Valitun ehdotuksen jälkeen tuleva virhe tarkoittaa, että molemmat osapuolet sopivat kaikesta paitsi avainmateriaalista, kun taas «ei ehdotusta valittu» kuuluu käytäntöön tai salausvalikoimiin. Eheystarkistus, joka epäonnistuu salasanan näyttäessä oikealta, on koodauseron näkyvä kasvot.

Yksi salaisuus, kolme tapaa joilla tiedosto voi lukea sen

Neljän tavun arvolle key1 heksadesimaali ja Base64 ovat samojen tavujen kaksi uudelleenkoodausta, ja vain johtavat merkit kertovat jäsentimelle, kumpaa se pitää. swanctl-tunnukset noudattavat samaa käytäntöä, joten kahden rajapinnan välillä siirretty arvo säilyttää merkityksensä vain, jos sen etuliite kulkee mukana.

10.20.0.5 %any : PSK "key1"
10.20.0.5 %any : PSK 0x6b657931
10.20.0.5 %any : PSK 0sa2V5MQ==

Kaksi yksityiskohtaa tuossa lohkossa vievät eniten aikaa. Heksadesimaalinumerot hyväksyvät kummatkin kirjoitusasut, joten 0x6b657931 ja 0x6B657931 ovat sama arvo, mutta pariton määrä merkkejä luetaan hiljaa väärin sen sijaan että se hylättäisiin, mikä siirtää jokaista tavua leikkauksen jälkeen. Base64-täyte kuuluu arvoon, joten merkkijono, joka liitetään ilman lopun = merkkejä, purkautuu eri tavuiksi sen sijaan että se epäonnistuisi äänekkäästi.

Profiili, joka on purkanut arvon kerran, on jo muuntanut sen, joten uudelleen purkaminen tuottaa eri tavut ja todennusvirheen, joka näyttää väärältä salasanalta. Lainausmerkit ovat turvallinen suunta kaikelle monitulkintaiselle, koska sisältö on kirjaimellinen myös silloin, kun se alkaa koodausmerkillä.

Mistä Base64-teksti tulee

Profiilien vienti ja toimittajien portaalit antavat avaimen usein jo koodattuna, yleensä tietokentässä, jota ei koskaan ollut tarkoitettu käsin kirjoitettavaksi. Joko pura kyseinen arvo ja tallenna purettu teksti lainausmerkkeihin, tai jätä se koodatuksi merkki edessä. Molemmista puolet tekeminen on se, mikä rikkoo sen. Kumpikin polku toimii vain, jos koko arvo selviää kopioinnista.

Kumpikin suunta on yksi komento, ja ne kannattaa pitää tiketissä täsmällisenä toimenpiteenä, joka tuotti tallennetun arvon. Suorita ne tässä järjestyksessä:

printf '%s' 'a2V5MQ==' | base64 -d
printf '%s' 'key1' | base64

Koodatun tekstin liittäminen kuin se olisi tavallista on kallis virhe. Tiedosto tiivistää merkit täsmälleen niin kuin ne on kirjoitettu, johdettu avain tulee noin kolmanneksen pidemmäksi kuin se, jonka vastapuoli laski, ja jokainen yritys epäonnistuu samalla tavalla ilman varoitusta, koska jäsennin noudatti sääntöä, joka sille annettiin.

Vahvista, mitä tavuja kukin vastapuoli todella käyttää

Lue ensin daemonin näkemys yhteydestä ja sitten todennuksen tulos, sen sijaan että arvaisit syyn virhemerkkijonosta. Tallennetun pituuden vertaaminen on nopea järkevyystarkistus, koska koodattu teksti on pidempi kuin tavut, joita se edustaa. Vahvista sitten, mikä identiteettirivi täsmäsi, koska väärän vastapuolen alle tallennettu oikea salaisuus epäonnistuu täsmälleen kuten väärä. Rivien järjestys ratkaisee sen: ensimmäinen osuma voittaa, joten leveä %any rivi lähellä yläosaa korvaa hiljaa juuri muokkaamasi rivin.

Lataa uudelleen sen sijaan että käynnistäisit uudelleen, kun tiedosto on oikein. ipsec rereadsecrets päivittää IKE-daemonin kopion, ja swanctl-asennus lataa tunnukset omalla komennollaan. Uudelleenkäynnistys pudottaa jokaisen muodostetun liitoksen ja tuhoaa vertailun, jota yritit tehdä.

Mikään näistä tarkistuksista ei vaadi salaisuuden paljastamista. Pituus, identiteetin valitsin ja rivin sijainti selittävät useimmat tällaiset virheet ennen kuin kukaan tarvitsee heksadumppia.

Muuta tiedostoa tulosta piilottamatta

Rajoita tiedosto daemonin tilille ja pidä elävät salaisuudet poissa tiketeistä, chatista ja kuvakaappauksista, koska liitetty avain on vuoto eikä diagnoosi. Se myös elää pidempään kuin sen tuottanut tapaus.

Testaa asiakkaasta, jonka kokoonpanoa hallitset, vahvista että todennus onnistuu ja vahvista sitten, että tunneli kuljettaa liikennettä. Uudelleenlataus, joka korjaa kättelyn mutta jättää reitityksen rikki, on eri ongelma, ja se tulee näkyviin heti kun salaisuus lakkaa liikkumasta.