Kaj se zgodi, ko zamenjate overitveno agencijo VPN

Zamenjava overitvene agencije VPN ni zamenjava datoteke. V trenutku, ko nova CA podpiše svoj prvi certifikat, se mora vsak validator, ki še vedno zaupa samo stari, odločiti, in gostitelji, ki nikoli ne prejmejo novega sidra, še naprej zavračajo dobre partnerje. Videl sem, da to odpove v obe smeri: prehod je spoznal novo CA, odjemalci pa ne, zato so nove povezave propadle, medtem ko so že vzpostavljeni tuneli ostali in so izpad naredili podoben usmerjevalni težavi. Tukaj je, kaj se spremeni, v vrstnem redu, v katerem se pojavijo napake.

Ena zamenjava, dve ločeni spremembi

Overitvena agencija je ime, javni ključ in zasebni ključ, ki podpisuje. Validatorji nikoli ne zaupajo »CA« v abstraktnem smislu. Zaupajo enemu določenemu certifikatu, ki že leži v shrambi zaupanja, in izdajatelja sprejmejo le, če veriga podpisov doseže to shranjeno kopijo. Zamenjava CA torej spremeni dve stvari, ki odpovedujeta neodvisno: katera sidra so sprejeta in katere identitete partnerjev so bile izdane pod njimi.

Večina uvedb VPN preverja v obe smeri. Odjemalec overi certifikat prehoda, prehod pa certifikat odjemalca. Zamenjava, ki osveži le odjemalčev paket, pusti strežnik, da zavrača vsakega odjemalca, ki še vedno predstavi identiteto stare CA, in obratno je enako pogosto. Najprej popišite točke uveljavljanja: shrambe zaupanja odjemalcev, datoteko ca prehoda, vsak proxy, ki zaključi TLS pred njim, in sondo, ki preverja končno točko od zunaj.

Kaj validator preveri, po vrsti

Preverjanje poti se vzpenja od certifikata partnerja skozi morebitne vmesne do zaupanja vrednega sidra. Na vsakem koraku preveri podpis, preveri, da je vsak certifikat v svojem oknu veljavnosti, in potrdi, da osnovne omejitve in uporaba ključa izdajatelju dovoljujejo podpisovanje. Šele nato aplikacija pogleda končni certifikat: alternativna imena subjekta morajo pokriti klicano ime, razširjena uporaba ključa pa mora dovoljevati overjanje strežnika ali odjemalca.

Če želite ta sprehod ponoviti brez povezave, usmerite -CAfile na točno tisti paket, ki ga boste uvedli, ne na sistemsko shrambo. Sicer preizkušate gostitelja, ne spremembe:

openssl verify -CAfile new-ca.crt gateway.crt
openssl verify -CAfile new-ca.crt -untrusted intermediate.crt client.crt
openssl x509 -in gateway.crt -noout -subject -issuer -dates
openssl s_client -connect gw.example.net:443 -CAfile new-ca.crt

Ta ukaz deluje le proti preprostemu poslušalcu TLS, kot je skrbniška stran HTTPS prehoda; krmilni kanal OpenVPN je pred TLS, zato s_client ne more pregledati rokovanja tunela.

Pravila gradnje poti za temi napakami so v RFC 5280 razdelek 6. Pojasnjujejo odpovedi, ki so sicer videti samovoljne: potekel vmesni certifikat, ki se ga ni nihče spomnil, certifikat, katerega uporaba ključa prepoveduje podpisovanje, ali omejitev imena, ki izključuje preizkušanega gostitelja.

Zakaj stari tunel deluje naprej

TLS in OpenVPN ohranjata vzpostavljeno sejo živo po koncu rokovanja. Nič ne preverja znova certifikata partnerja pri vsakem paketu, zato odjemalec, povezan pred spremembo, še naprej prepušča promet, dokler se znova ne pogaja, ne poveže ali tunel ne pade. Prav ta vrzel povzroči, da je zamenjava CA lahko uro videti v redu in nato odpove v najslabšem trenutku: prenosnik se zbudi iz spanja, preslikava NAT poteče, prehod se znova zažene.

Nadaljevanje seje iluzijo še raztegne. Vstopnica seje TLS odjemalcu omogoči vrnitev brez ponovnega pošiljanja certifikatov, nadaljevanje pa preskoči preverjanje poti, ker ga je prvo rokovanje že opravilo. Pošten preizkus je zato polno rokovanje v novem procesu. Znova zaženite odjemalca, namesto da znova povežete tunel, in v preizkusnem profilu razmislite o izklopu vstopnic, da pot nadaljevanja ne more skriti zlomljene verige.

Plast statičnega ključa imejte ločeno od tega. tls-auth doda HMAC krmilnemu kanalu, tls-crypt ga šifrira in overi, nobeno pa ne nosi gradiva certifikata, zato je vrtenje katerega koli ločena sprememba z lastnim načinom odpovedi. Uvedbe, ki oboje zmešajo, končajo z odjemalcem, katerega statični ključ je v redu, certifikat zastarel in sporočilo o napaki ne omenja nobenega od obeh.

Past ponovne uporabe imena subjekta

Mamljivo je znova uporabiti razločevalno ime predhodnika, da se nič nižje ne bi moralo spremeniti. To drži vrstico izdajatelja stabilno v vmesniku in uniči edini signal, ki ga potrebujete. Dveh certifikatov z enakimi subjekti in različnimi ključi ni mogoče ločiti po imenu, zato paket z obema sidrima da validatorju dva kandidata in nobenega pravila za izbiro.

Gradnja poti lahko nato izbere napačnega, poroča »certifikata lokalnega izdajatelja ni mogoče pridobiti«, ko je pravo sidro prisotno, ali uspe na enem gostitelju in odpove na drugem z istim paketom, ker je bil vrstni red kandidatov drugačen. Če je treba ime znova uporabiti, imejte obe sidri med prehodom v ločenih datotekah in ju naložite izrecno, združite pa ju šele, ko vsak partner predstavi novega izdajatelja. Sicer dajte nadomestku ločeno splošno ime — pripona generacije ali datuma zadošča — da bodo dnevniki in besedila napak povedali, pod katero oblastjo je bil izdan partner, ki odpoveduje.

Vrtenje, ki ne podre omrežja

Za načrtovano zamenjavo sprejmite obe sidri za omejeno obdobje, namesto da bi preklopili v enem koraku. Izdajte novo CA in njene vmesne certifikate, postavite novo sidro v paket vsakega validatorja ob staro in šele nato začnite iz nje izdajati certifikate partnerjev. Partnerji s starimi identitetami se preverjajo proti staremu sidru; novi delujejo proti novemu.

Če je izvedeno v tem vrstnem redu, je vsak korak povrnljiv. Odpoved, ki se ji izogibate, je hkratni preklop, ko odjemalec, ki je zgrešil posodobitev paketa, naleti na prehod, ki je staro sidro že umaknil, rokovanje umre in noben dnevnik ne pove, katera stran je zastarela.

Umaknite v nasprotno smer. Znova izdajte vsako identiteto, ki mora preživeti, potrdite, da vsaka predstavi novo verigo, nato odstranite staro sidro iz paketov. Umaknite zasebni ključ stare CA iz uporabe, kajti izdajatelj, ki še lahko podpiše, pomeni, da vrtenje ni končano. Shranite certifikate in evidence izdajanja za revizijo. Izgubljeni izdajatelj se obnovi v isto zaupanje; razkritje zahteva nove identitete in nobene vrnitve k staremu sidru.

Preverite izid, ne seznama datotek

Datoteka zaupanja v pričakovani mapi dokaže malo. Aplikacija lahko bere drugo pot, drugo obliko ali kopijo v paketu, ki jo nadgradnja zamenja. Preverite vedenje na obeh koncih, ne obstoja datoteke.

Potrdite, da nova povezava z novo identiteto uspe, nato potrdite, da je identiteta, ki jo je izdala umaknjena CA, zavrnjena. Prav ta drugi preizkus ljudje preskočijo in je edini, ki pokaže, da stara oblast ne daje več dostopa. Kjer se uvedba opira na CRL ali OCSP, preverite, da se distribucijske točke v novih certifikatih razrešijo in da partnerji, ki sprašujejo, dosežejo odzivnika.

Končajte z odjemalcem, ki se ni nikoli povezal: izbrišite stanje njegovega profila, povežite in preberite izpogajano verigo. Partner, ki nadaljuje predpomnjeno sejo, bo veselo poročal, da je selitev uspela, čeprav ni preveril ničesar.