Itseallekirjoitettu VPN-varmenne: mitä se tarkoittaa ja mihin se luottaa

Täällä eniten vahinkoa tekevät kaksi uskomusta: että itseallekirjoitettu VPN-varmenne tarkoittaa, ettei tunnelia ole salattu, ja että VPN-asiakkaan pyytämien asioiden asentaminen vaikuttaa vain VPN:ään. Kumpikaan ei kestä kosketusta todelliseen käyttöönottoon. Itseallekirjoitettu varmenne kuvaa allekirjoitussuhteen, ei turvallisuustuomiota, ja lisäämäsi luottamuksen ulottuvuus riippuu siitä, mihin varastoon se päätyy. Olen nähnyt tukipalvelun tuovan palveluntarjoajan juuren Windows-koneelle yhden varoituksen vaientamiseksi ja viettävän sitten koko iltapäivän selittäen, miksi selain lakkasi valittamasta asiattomasta portaalista. Tämän kysymyksen kaksi puoliskoa kuuluvat yhteen, joten käsittele niitä yhtenä.

Varmenne ei ole luottamusvarasto

Palvelimen esittämä tiedosto sisältää julkisen avaimen, subjektin nimen, myöntäjän nimen, voimassaolopäivät ja laajennukset. Itseallekirjoitettu tarkoittaa, että subjekti ja myöntäjä ovat sama taho ja allekirjoitus vahvistetaan varmenteen omalla avaimella. Mikään siinä määritelmässä ei sano, että yhteys on heikko, eikä mikään sano, että asiakas hyväksyy sen.

Hyväksyntä tulee muualta: CA-tiedostosta, johon osoitat asiakkaan, sormenjäljestä, jonka vertaat käsin, tai juuresta, joka on jo varastossa, jota asiakas lukee. Käyttöönotto voi olla täysin terve, vaikka sen varmenne epäonnistuisi jokaisessa julkisessa testissä. openssl verify järjestelmän nippua vastaan raportoi tuntemattomasta myöntäjästä, ja se raportti on oikea eikä vika.

OpenVPN:n ca-valinta on selvin tapaus sovellukseen rajatusta luottamuksesta. Se tiedosto nimeää ankkurit, jotka asiakas hyväksyy, ja se voi sisältää yhden yksityisen CA:n tai pienessä käyttöönotossa palvelimen oman itseallekirjoitetun varmenteen. Versio 2.6 hyväksyy myös --peer-fingerprint:n SHA-256-sormenjäljen kiinnittämiseen CA-tiedoston jakamisen sijaan. WireGuard on vielä kauempana: siinä ei ole lainkaan varmenteita, vain staattinen julkinen avain paria kohden, joten itseallekirjoituskysymys ei sovellu siihen.

Missä asennat luottamuksen, päättää kuka perii sen

Laita sama varmenne kolmeen paikkaan ja saat kolme erilaista räjähdyssädettä. Nippu, jota vain VPN-asiakas lukee, vaikuttaa siihen asiakkaaseen. Juuri käyttöjärjestelmän varastossa vaikuttaa jokaiseen ohjelmaan, joka kysyy sitä varastoa. Selain, jolla on oma luottamustietokantansa, voi jättää molemmat huomiotta, ja siksi varoitus voi selvitä tuonnista, joka näytti toimivan.

Debianissa tai Ubuntussa tiedoston pudottaminen hakemistoon /usr/local/share/ca-certificates/ ja komennon update-ca-certificates ajaminen muuttaa järjestelmänlaajuista nippua. Windowsissa certutil -addstore -f Root kirjoittaa konevarastoon ja vaatii korotetun komentokehotteen, kun taas -user:n lisääminen kohdistaa nykyisen käyttäjän varastoon; nämä kaksi eivät ole vaihdettavissa. Firefox pitää omaa NSS-tietokantaansa, joten käyttöjärjestelmätason tuonti ei välttämättä näy siellä koskaan.

Laajuus on tärkeä siksi, mitä viranomainen voi tehdä. Myöntävä CA voi allekirjoittaa nimiä, joihin sillä ei ole mitään suhdetta, joten kaikki, joka luottaa siihen varastoon, hyväksyy ne allekirjoitukset. Yksi kiinnitetty lehti ei voi tehdä sitä; se todentaa täsmälleen yhden vastapuolen identiteetin. Jos tavoite on saada yksi VPN yhdistymään, sovellukseen rajattu CA tai kiinnitetty lehti saavuttaa sen, kun taas koneenlaajuinen juuri on paljon suurempi myönnytys kuin oire vaatii.

Salaat silti ilman julkista CA:ta

TLS-kättely johtaa istuntoavaimet riippumatta siitä, ketjuuntuuko vastapuolen varmenne johonkin, johon jo luotat. Itseallekirjoitettu ei tarkoita selkokieltä eikä sitä, että liikenne olisi lennossa luettavissa. Se tarkoittaa, että asiakkaalla ei ole etukäteen syytä uskoa, että avain kuuluu palvelimelle, jota se pyysi.

Siinä aukossa oikeat hyökkäykset elävät. Asiakas, joka on määritetty hyväksymään mikä tahansa varmenne, joko poistetun vahvistusasetuksen tai kerran painetun ja unohdetun luota-silti-painikkeen kautta, salaa iloisesti kenelle tahansa, joka vastaa. Sieppaus tapahtuu todennusvaiheessa, ennen kuin sovelluksen tiedot liikkuvat. Salaus ilman identiteettitarkistusta pitää passiivisen tarkkailijan ulkona ja tekee vähän muuta.

Myöntäjään luottaminen ei ohita nimien tarkistusta

Ketjun vahvistus, nimen täsmäytys ja varmenteen käyttötarkoitus ovat erillisiä päätöksiä. Ketju voi olla kelvollinen, kun nimi on väärä, ja nimi voi täsmätä, kun varmenne on myönnetty toiseen rooliin. RFC 5280 määrittelee kentät, jotka kantavat näitä rajoituksia, ja se, kuinka tiukasti asiakas niitä valvoo, on jokaisen sovelluksen asia.

OpenVPN tekee jaon näkyväksi. verify-x509-name kiinnittää odotetun subjektin name-, name-prefix- tai subject-täsmäytyksen kautta. remote-cert-tls server vaatii, että vastapuolen varmenne on käytettävissä palvelinvarmenteena, mikä hylkää vain asiakasvarmenteen, vaikka myöntäjä olisi luotettu. Kumpaakaan asetusta ei korvata CA-tiedoston lähettämisellä.

Tarkastele varmennetta ennen kuin päätät mitään:

• openssl x509 -in server.crt -noout -subject -issuer -dates -ext subjectAltName näyttää, kuka sen myönsi, mille nimille ja mihin asti.
• openssl verify -CAfile ca.crt server.crt tarkistaa, validoiko lähettämäsi ketju todella lehden.
• openssl s_client -connect vpn.example.net:443 -servername vpn.example.net -CAfile ca.crt -verify_return_error toimii TLS-päätepisteille, kuten verkkoportaalille; OpenVPN-protokolla portissa 1194 ei ole tavallinen TLS-virta, joten se testi ei päde siellä.

Varmenne, jonka päiväys on vanhentunut, jossa ei ole subjectAltName-kenttää yhdistettävälle nimelle tai josta puuttuu serverAuth-käyttö, epäonnistuu riippumatta siitä, kuinka huolellisesti ankkuri asennettiin.

Viisi tarkistusta ennen kuin hyväksyt yhden

Vertaa sormenjälkeä kanavalla, joka ei ole se yhteys, jota yrität korjata: konsoli, asennusohjelma, joka sinulla jo on, allekirjoitettu asetustiedosto. openssl x509 -in server.crt -noout -fingerprint -sha256 palvelimella ja sama arvo asiakkaan lokissa riittävät siihen, että tiedät katsovasi yhtä objektia.

Päätä seuraavaksi, mitä asennat: yksi lehti vai viranomainen, joka voi lyödä lisää. Päätä sitten, minne se menee, ja nimeä sovellukset, jotka lukevat sitä varastoa. Kirjoita poistopolku muistiin, kun vielä muistat sen, koska luota-ja-jatka on se tapa, jolla väliaikaisesta tuonnista tulee pysyvä.

Suunnittele lopuksi muutos. Kiinnitetty varmenne tai sormenjälki on päivitettävä saman luotetun kanavan kautta, kun varmenne vaihtuu, ja yksityisellä CA:lla on oma myöntämis- ja mitätöintielinkaarensa. Jos yksityinen avain vuotaa, saman varmenteen kopioon uudelleen luottaminen ei korjaa mitään; identiteetti on vaihdettava.

Jos varoitus selviää kaikista viidestä tarkistuksesta, hyödyllinen kysymys ei ole, mikä painike vaientaa sen, vaan mitä varastoa asiakas todella lukee ja mistä se juuri tuli. Vastaa siihen, niin tuonnista, jonka aiot tehdä, tulee päätös eikä refleksi.