OpenVPN-profiilissa on kolme varmennelohkoa: mikä on salainen?

Avaat .ovpn-tiedoston muuttaaksesi yhden rivin ja löydät kolme base64-lohkoa, jotka kaikki näyttävät kirjautumistiedoilta. Yksi on turvallista julkaista, yksi on yhtä arkaluonteinen kuin salasana, ja yksi on julkinen avain, joka ei merkitse mitään, ellei jokin muu ole allekirjoittanut sen parilla. Ihmiset liittävät koko tiedoston tukiketjuun, koska lohkot näyttävät vaihdettavilta, ja niin asiakasavain päätyy julkiseen arkistoon. Sen selvittäminen, mitä kukin lohko tekee, selittää suurimman osan näihin profiileihin liittyvästä hämmennuksestä ja kertoo myös, mitkä viat sinun on korjattava itse.

Yksi tiedosto, kolme lohkoa, eri tehtävät

Tyypillinen profiili upottaa ca-lohkon, cert-lohkon ja key-lohkon BEGIN- ja END-merkintöjen väliin tai viittaa samoihin kolmeen erillisinä tiedostoina. Jotkin profiilit lisäävät neljännen lohkon tls-auth- tai tls-crypt-avaimelle, joka on jaettu salaisuus eikä varmenne. Asiakas lukee kunkin lohkon sen nimeävän direktiivin mukaan, joten nimikkeet merkitsevät enemmän kuin esiintymisjärjestys.

Käsittele koottua profiilia arkaluontoisena, kunnes olet todella katsonut sisään. Julkinen varmenne ja yksityinen avain voivat olla samassa tiedostossa muutaman rivin päässä toisistaan, ja otsikon sisältävä kuvakaappaus voi sisältää molemmat. Näkyvän base64:n peittäminen käsin on myös epäluotettavaa, koska osittainen lohko vuotaa silti varmenteen metatiedot, jotka nimeävät käyttöönottoasi. Kolmen direktiivin kopioiminen ilman niiden arvoja riittää yleensä hyödylliseen kysymykseen.

Lohkojen ympärillä olevat direktiivit päättävät, miten niitä käytetään. Vaihda ca ja asiakas luottaa toiseen tahoon; vaihda cert vaihtamatta keytä ja kättely epäonnistuu yhteensopimattomuuteen, jolla ei ole mitään tekemistä luottamuksen kanssa.

CA-lohko on julkinen, CA-avain ei koskaan

Varmenneviranomainen allekirjoittaa varmenteita, jotka sitovat julkisen avaimen identiteettiin, ja sen oma varmenne on ankkuri, jonka perusteella asiakas päättää, onko ketju luotettava. Tämä varmenne on suunnittelultaan julkinen: sen lähettäminen jokaisen profiilin sisällä on normaalia, ja juuri siksi itseallekirjoitettu käyttöönotto voi toimia ilman kaupallista tahoa.

Se, mitä asiakasprofiilissa ei saa koskaan näkyä, on tahon yksityinen allekirjoitusavain. Asiakas ei tarvitse sitä mihinkään validointiin, ja sen läsnäolo tarkoittaa, että kuka tahansa profiilin haltija voi luoda uusia identiteettejä koko käyttöönotolle.

Tahoon luottaminen on myös kapeampaa kuin miltä kuulostaa. Asiakas, joka hyväksyy minkä tahansa CA:n allekirjoittaman varmenteen, hyväksyy edelleen varmenteen, joka on myönnetty toiselle palvelulle samassa CA:ssa. Vaihtoehdot, jotka kiinnittävät odotetun palvelimen roolin tai nimen, sulkevat tämän aukon, ja TLS-vaihtoehtojen viite luettelee vahvistusdirektiivit, jotka tekevät sen.

Palvelimen ja asiakkaan varmenteet osoittavat vastakkaisiin suuntiin

Palvelimen varmenne on se, mitä asiakas tutkii varmistaakseen, että saavutti oikean päätepisteen. Asiakasvarmenteesi kulkee toisin päin: palvelin käyttää sitä päättääkseen, että tämä laite tai käyttäjä on sen rekisteröimä. Sama muoto, vastakkainen luottamussuunta.

Osoite ei ole identiteetti. Oikeaan IP-osoitteeseen pääseminen ei todista mitään siitä, kuka vastasi, siksi isäntänimen tai varmenteen nimen tarkistus kuuluu edelleen profiiliin. Tilinsalasana ei myöskään hiljaa korvaa vaadittua asiakasvarmennetta, koska molemmat tarkistetaan eri vaiheissa ja käyttöönotto voi vaatia molemmat.

Asiakkaan yksityinen avain on osa, jonka on pysyttävä yksityisenä. Jos se on voinut paljastua, tiedoston poistaminen kannettavaltasi ei muuta palvelimella mitään, sillä se hyväksyy vastaavan varmenteen edelleen, kunnes operaattori peruuttaa sen. Operaattorin pyytäminen korvaamaan tai peruuttamaan tämä identiteetti on ainoa korjaus, joka kulkee mukanasi.

Kaksi kehotetta, jotka näyttävät samalta eivätkä ole

Salattuun muotoon tallennettu avain kysyy salasanaa ennen kuin asiakas voi käyttää sitä. VPN-palvelu voi kysyä erikseen tilinsalasanaa, ja kehotteet voivat ilmestyä sekuntien välein lähes samalla sanamuodolla. Salasana suojaa levylläsi olevaa tiedostoa; tilinsalasana todistaa tilin palvelimelle. Niiden sekoittaminen lähettää ihmiset salasanan palautuksiin, jotka eivät voi mitenkään auttaa.

Lue kehote ennen kuin palautat mitään. Tilinsalasanan palautus ei tee mitään unohdetulle avaimen salasanalle, peruutetulle tai vanhentuneelle varmenteelle, ja salasanan palauttaminen silloin, kun vika on varmenteen vahvistus, muuttaa kahden minuutin korjauksen tukitapaukseksi. Jos valitus mainitsee voimassaolopäivät, tarkista ensin laitteen kello ja sitten nimetyn varmenteen oma ikkuna.

Kun varmenne on todella vanhentunut, korvaavan on tultava siltä, joka sen myönsi. Toiselle kuuluva avain ei ole uusimispolku, eikä toimivan profiilin lainaaminen kollegalta sitä ole.

Mitä puhdas kättely todistaa ja mitä ei

Valmiiseen TLS-kättelyyn pääseminen tarkoittaa, että määritetty identiteettisuhde piti: palvelimen varmenne ketjutettiin CA:hanne ja varmenteesi hyväksyttiin. Se ei kerro mitään operaattorin lokituskäytännöstä eikä siitä, toimivatko sovelluksesi, kun tunneli on pystyssä.

Reitit ja DNS ovat yhteyden myöhempiä vaiheita, joten tavoittamaton intranet-isäntä onnistuneen kirjautumisen jälkeen on yhteyden ongelma eikä varmenteen ongelma. Työstä sitä kerrosta sen sijaan, että vaihtaisit kirjautumistietoja, ja pidä profiilin alkuperä, sen yksityinen materiaali ja sen identiteettitarkistukset yhdessä, kun annat sen jollekin.