Samopodpisano potrdilo VPN: kaj pomeni in čemu zaupa

Tu največ škode naredita dve prepričanji: da samopodpisano potrdilo VPN pomeni, da tunel ni šifriran, in da nameščanje česarkoli, kar je zahteval odjemalec VPN, vpliva samo na VPN. Nobeno ne preživi stika z resnično uvedbo. Samopodpisano potrdilo opisuje razmerje podpisa, ne varnostne razsodbe, obseg zaupanja, ki ga dodate, pa je odvisen od tega, v katero shrambo pristane. Videl sem helpdesk, ki je uvozil koren ponudnika v računalnik z Windows, da bi utišal eno opozorilo, nato pa preživel popoldne z razlaganjem, zakaj se brskalnik neha pritoževati zaradi nepovezanega portala. Obe polovici tega vprašanja sodita skupaj, zato ju obravnavajte kot eno.

Potrdilo ni shramba zaupanja

Datoteka, ki jo predstavi strežnik, nosi javni ključ, ime subjekta, ime izdajatelja, datume veljavnosti in razširitve. Samopodpisano pomeni, da sta subjekt in izdajatelj ista entiteta in se podpis preveri z lastnim ključem potrdila. Nič v tej definiciji ne pravi, da je povezava šibka, in nič ne pravi, da jo bo odjemalec sprejel.

Sprejem pride od drugod: datoteka CA, na katero usmerite odjemalca, odtis, ki ga primerjate ročno, ali koren, ki že leži v shrambi, ki jo odjemalec bere. Uvedba je lahko popolnoma zdrava, medtem ko bi njeno potrdilo padlo na vsakem javnem preizkusu. openssl verify proti sistemskemu svežnju bo poročal o neznanem izdajatelju, in to poročilo je pravilno, ne napaka.

Možnost ca OpenVPN je najjasnejši primer zaupanja, omejenega na aplikacijo. Ta datoteka poimenuje sidra, ki jih bo odjemalec sprejel, in lahko vsebuje en zasebni CA ali v majhni uvedbi lastno samopodpisano potrdilo strežnika. Različica 2.6 sprejme tudi --peer-fingerprint za pripenjanje odtisa SHA-256 namesto razdeljevanja datoteke CA. WireGuard stoji še dlje: nima nobenih potrdil, le statični javni ključ za vsakega partnerja, zato se vprašanje samopodpisa nanj ne nanaša.

Kje namestite zaupanje, odloča, kdo ga podeduje

Isto potrdilo postavite na tri mesta in dobite tri različne polmere učinka. Sveženj, ki ga bere samo odjemalec VPN, vpliva na tega odjemalca. Koren v shrambi operacijskega sistema vpliva na vsak program, ki to shrambo posvetuje. Brskalnik z lastno bazo zaupanja lahko oboje prezre, zato lahko opozorilo preživi uvoz, ki se je zdel uspešen.

V Debianu ali Ubuntuju namestitev datoteke v /usr/local/share/ca-certificates/ in zagon update-ca-certificates spremenita sistemski sveženj. V Windowsu certutil -addstore -f Root piše v shrambo stroja in zahteva povišan ukazni poziv, medtem ko dodajanje -user cilja shrambo trenutnega uporabnika; ta dva nista zamenljiva. Firefox hrani lastno bazo NSS, zato se uvoz na ravni OS morda nikoli ne pokaže tam.

Obseg je pomemben zaradi tega, kar lahko naredi organ. Izdajatelj CA lahko podpiše imena, s katerimi nima nobene povezave, zato bo vse, kar zaupa tej shrambi, te podpise sprejelo. En sam pripet list tega ne zmore; overi natanko eno identiteto partnerja. Če je cilj povezati en VPN, CA, omejena na aplikacijo, ali pripet list to doseže, medtem ko je koren na ravni stroja veliko večji popustek, kot ga zahteva simptom.

Še vedno šifrirate brez javnega CA

Rokovanje TLS izpelje sejne ključe ne glede na to, ali se potrdilo partnerja veriži v nekaj, čemur že zaupate. Samopodpisano ne pomeni golo besedilo in ne pomeni, da je promet med letom berljiv. Pomeni, da odjemalec nima vnaprejšnjega razloga verjeti, da ključ pripada strežniku, ki ga je zahteval.

V tej vrzeli živijo resnični napadi. Odjemalec, nastavljen za sprejemanje kateregakoli potrdila, bodisi prek onemogočene nastavitve preverjanja bodisi prek gumba »vseeno zaupaj«, ki je bil enkrat pritisnjen in pozabljen, bo veselo šifriral vsakomur, ki odgovori. Prestreza se v koraku overjanja, preden se podatki aplikacije premaknejo. Šifriranje brez preverjanja identitete zadrži pasivnega opazovalca zunaj in naredi malo drugega.

Zaupanje izdajatelju ne preskoči preverjanja imena

Preverjanje verige, ujemanje imena in namen potrdila so ločene odločitve. Veriga je lahko veljavna, medtem ko je ime napačno, in ime se lahko ujema, medtem ko je bilo potrdilo izdano za drugo vlogo. RFC 5280 opredeljuje polja, ki nosijo te omejitve, in kako strogo jih odjemalec uveljavlja, je stvar vsake aplikacije.

OpenVPN naredi ločitev vidno. verify-x509-name pripne pričakovani subjekt z ujemanjem name, name-prefix ali subject. remote-cert-tls server zahteva, da je potrdilo partnerja uporabno kot strežniško potrdilo, kar zavrne potrdilo samo za odjemalca, tudi ko je izdajatelj zaupanja vreden. Nobena od nastavitev se ne nadomesti s pošiljanjem datoteke CA.

Preglejte potrdilo, preden kar koli odločite:

• openssl x509 -in server.crt -noout -subject -issuer -dates -ext subjectAltName pokaže, kdo ga je izdal, za katera imena in do kdaj.
• openssl verify -CAfile ca.crt server.crt preveri, ali veriga, ki jo nameravate poslati, res potrdi list.
• openssl s_client -connect vpn.example.net:443 -servername vpn.example.net -CAfile ca.crt -verify_return_error deluje za končne točke TLS, kot je spletni portal; protokol OpenVPN na vratih 1194 ni običajen tok TLS, zato ta preizkus tam ne velja.

Potrdilo s poteklim datumom, brez subjectAltName za ime, na katero se povezujete, ali brez uporabe serverAuth spodleti ne glede na to, kako skrbno je bilo sidro nameščeno.

Pet preveritev, preden eno sprejmete

Primerjajte odtis po kanalu, ki ni povezava, ki jo poskušate popraviti: konzola, nameščevalnik, ki ga že imate, podpisana konfiguracijska datoteka. openssl x509 -in server.crt -noout -fingerprint -sha256 na strežniku in ista vrednost v dnevniku odjemalca zadoščata, da veste, da gledate en objekt.

Nato se odločite, kaj nameščate: en list ali organ, ki lahko skuje več. Potem se odločite, kam gre, in poimenujte aplikacije, ki berejo to shrambo. Zapišite pot odstranitve, dokler se je še spomnite, ker zaupaj-in-pojdi-naprej je način, kako začasen uvoz postane trajen.

Na koncu načrtujte spremembo. Pripeto potrdilo ali odtis je treba ob rotaciji potrdila posodobiti po istem zaupanja vrednem kanalu, zasebni CA pa ima svoj življenjski cikel izdajanja in preklica. Če zasebni ključ pušča, ponovno zaupanje kopiji istega potrdila ne popravi ničesar; identiteto je treba zamenjati.

Če opozorilo preživi vseh pet preveritev, uporabno vprašanje ni, kateri gumb ga utiša, ampak katero shrambo odjemalec dejansko bere in od kod je prišel ta koren. Odgovorite na to in uvoz, ki ga nameravate narediti, postane odločitev namesto refleksa.