tls-auth-virheestä ilmoitetaan yleensä kättelyongelmana, vaikka se ei koskaan ollut sellainen. HMAC tarkistetaan ohjauspaketista ennen mitään TLS-käsittelyä, joten väärä avain tai suunta tuottaa virheen, joka näyttää varmenneongelmalta ja ratkaistaan kahta kerrosta aiemmin. Kun kuorta käsitellään omana objektinaan, diagnoosista tulee lyhyt: lue kentät, varmista että tarkistus käynnistyy aikaisin ja vertaa sitten kolmea asiaa, joista molempien päiden on sovittava.

Lue kuori siinä järjestyksessä, jossa se rakennetaan

Ohjauspaketti kuljettaa istuntotunnistetta, valinnaista tls-auth-HMACia, uudelleenlähetys- ja kuittaustietoja sekä luotettavaa viestitunnistetta, ja sen jälkeen tulee viestityypin hyötykuorma. Kun viesti on kättelyviesti, hyötykuorma sattuu olemaan TLS-salaustekstiä. Se on koko suhde: TLS-materiaali kulkee viestin sisällä, jota kuori jo suojaa. Katso OpenVPN:n verkkoprotokollaviitettä, joka luettelee ohjauskanavan kentät tässä järjestyksessä.

Luotettavuuskerros sekoitetaan helposti salaukseen. Kuittaukset, uudelleenlähetys ja viestitunniste ovat olemassa, jotta ohjausviestit saapuvat kerran ja oikeassa järjestyksessä epäluotettavan siirron yli. Ne eivät ole todentamista, eikä oikea viestitunniste todista mitään siitä, kuka paketin lähetti.

Pidä tämä ryhmittely käsitteellisenä. Se ei ole tavujärjestyksen kaavio, eikä se riitä tunnisteen laskemiseen, koska HMACiin tulevat kentät riippuvat toteutuksesta, versiosta ja tilasta.

Osoita, että tarkistus käynnistyy ennen kättelyä

Vastaanottaja, jolla on jaettu avain, voi varmistaa HMACin ja hylätä väärennetyn paketin heti, ilman kättelytilan varaamista tai julkisen avaimen työtä. Suojaus kattaa myös kättelyn aloituspaketit, ja juuri siksi väärä avain näkyy epäonnistuneena yhteytenä eikä myöhäisenä todennusvirheenä.

Lisää daemonin sanallisuutta ja seuraa ohjauskanavaa tun-laitteen sijaan:

openvpn --config /etc/openvpn/server.conf --verb 6

Etsit ohjauskanavan HMAC-tarkistuksen virhettä, joka raportoidaan pakettitasolla ennen mitään TLS-hälytystä. Lokiin tullut TLS-hälytys tarkoittaa, että kuori hyväksyttiin ja virhe siirtyi sisäänpäin, mikä on eri tutkinta ja eri korjaus.

Suunnan käsittely on myös täällä. Kun staattista avaintiedostoa käytetään tls-authin kanssa, kaksi päätä ottavat vastakkaiset avainsuunnat, ja protokolla käyttää tätä jakoa, jotta siepattu paketti ei voi heijastua takaisin lähettäjälleen. Suunnan kääntäminen pitää avaimen samana ja silti jokainen paketti epäonnistuu. Vaihda yksi pää kerrallaan ja käynnistä sitten molemmat daemonit uudelleen, jotta pari latautuu yhdessä.

Sovita avain, suunta ja digest molemmissa päissä

Kolmen arvon on sovittava yhteen ja vain yksi niistä on tiedosto. Staattisen avaimen sisällön on oltava sama molemmissa päissä, suunnan on oltava vastakkainen ja HMACiin käytetyn digestin on täsmättävä. Tarkista kokoonpano ennen kuin kosket avainmateriaaliin, sillä yksi väärinpäin oleva suunta selittää useampia virheitä kuin vioittunut tiedosto:

grep -E 'tls-auth|tls-crypt|key-direction|auth ' /etc/openvpn/server.conf

Luo jaettu salaisuus työkalulla, älä editorilla, ja pidä oikeudet tiukkoina:

openvpn --genkey secret /etc/openvpn/ta.key
chmod 600 /etc/openvpn/ta.key

Vanhemmat versiot hyväksyivät hieman erilaisen asetusjärjestyksen avainten luontiin, ja noille versioille kirjoitetut profiilit kiertävät edelleen. Luotu tiedosto on samaa objektityyppiä kummassakin tapauksessa, joten tarkistus on siinä, pitävätkö molemmat päät identtisiä tavuja, ei siinä, mikä kirjoitusasu ne tuotti.

Älä sekoita tls-authia ja tls-cryptiä. Molemmat suojaavat ohjauskanavaa, mutta tls-crypt myös salaa sen ja piilottaa kättelyn tarkkailijoilta, ja se korvaa suuntajaon omalla avainkäsittelyllään. Toista käyttävä profiili ei toimi toiselle määritetyn vastapuolen kanssa, eikä mikään digestin säätö sulje tätä aukkoa.

Toista tunniste vain todellisesta muodosta

Tavulleen tarkka toisto on erillinen tehtävä VPN:n ajamisesta, ja se onnistuu vain todellisilla syötteillä: paketin rakentanut toteutus ja versio, valittu digest, suunta sekä todelliset tavut, mukaan lukien istuntotunniste ja kuittaustaulu. Kenttäluettelon tekstiesitys ei ole niitä tavuja.

Tunnisteen pituus seuraa digestistä, joten oletus kiinteästä pituudesta murtuu heti, kun joku muuttaa sitä. Hashaa paketti niin kuin toteutus tekee, ei niin kuin blogikirjoituksen taulukko esittää, ja vertaa samalta vastapuolelta otettuun tallenteeseen, älä käsin johdettuun odotukseen.

Pidä tämä harjoitus poissa tuotantoprofiileista. Mikään tunnisteen toistamisessa ei kerro, pitäisikö käyttöönoton ottaa suojaus käyttöön.

Peru epäjohdonmukaisuus poistamatta suojausta

Houkuuttava testi on poistaa tls-auth, katsoa yhteyden onnistuvan ja päätellä avaimen olleen väärä. Se vastaus maksaa suojauksen eikä opeta mitään siitä, mikä kolmesta arvosta oli ristiriidassa. Hanki sen sijaan palvelinpuolelta hyväksytty vastaava kokoonpano ja vertaa siihen.

Valmistele muutos peruutettavaksi. Säilytä edellinen palvelinkokoonpano ja avaintiedosto, ota korjattu pari käyttöön, varmista että asiakas saa kättelyn valmiiksi ja poista varmuuskopio vasta sitten. Jos asiakkaat epäonnistuvat muutoksen jälkeen, palauta edelliset tiedostot sen sijaan, että kehittelisit kolmatta versiota katkoksen aikana. Palautuksen pitäisi olla yksi komento, jonka jo tunnet ennen aloittamista.

Muista lopuksi, mitä läpäisty tarkistus tarkoittaa. Se todistaa, että vastapuolella on jaettu avain, ei sitä että sen varmenne tai tili on valtuutettu, ja se ei kerro mitään sovitusta datakanavan salauksesta. Valtuutus ja datan suojaus luodaan myöhemmin, joten puhdas kuoren tarkistus on lähtökohta, ei tuomio.

Aiheeseen liittyvät artikkelit