Mi történik, amikor lecseréli a VPN-hitelesítésszolgáltatót

A VPN-hitelesítésszolgáltató lecserélése nem fájlcsere. Abban a pillanatban, amikor az új CA aláírja az első tanúsítványát, minden érvényesítőnek, amely még mindig csak a régeben bízik, döntenie kell, és azok a gazdagépek, amelyek soha nem kapják meg az új horgonyt, továbbra is elutasítják a jó partnereket. Láttam mindkét irányban elromlani: az átjáró megtanulta az új CA-t, az ügyfelek nem, ezért az új kapcsolatok meghiúsultak, miközben a már felállított alagutak talpon maradtak, és a kimaradást útválasztási problémának láttatták. Íme, mi változik, abban a sorrendben, ahogy a hibák megjelennek.

Egy csere, két külön változás

A hitelesítésszolgáltató egy név, egy nyilvános kulcs és az aláíró privát kulcs. Az érvényesítők soha nem „a CA-ban” bíznak elvontan. Egy konkrét tanúsítványban bíznak, amely már ott van egy bizalmi tárban, és egy kibocsátót csak akkor fogadnak el, ha az aláírások lánca eljut ahhoz a tárolt példányhoz. Ezért a CA lecserélése két dolgot változtat meg, amelyek egymástól függetlenül hibásodnak meg: mely horgonyokat fogadják el, és mely partneridentitásokat adták ki alattuk.

A legtöbb VPN-telepítés mindkét irányban érvényesít. Az ügyfél hitelesíti az átjáró tanúsítványát, az átjáró pedig az ügyféléét. Az a csere, amely csak az ügyfélcsomagot frissíti, a kiszolgálót minden olyan ügyfél elutasítására készteti, amely még a régi CA identitását mutatja, és ennek fordítottja is ugyanilyen gyakori. Először számba kell venni a kényszerítési pontokat: az ügyfelek bizalmi tárai, az átjáró ca fájlja, az előtte TLS-t lezáró bármely proxy és a végpontot kívülről vizsgáló szonda.

Mit ellenőriz az érvényesítő, sorrendben

Az útvonal-érvényesítés a partner tanúsítványától indul, a köztes tanúsítványokon át, míg el nem ér egy megbízható horgonyt. Minden lépésnél ellenőrzi az aláírást, megnézi, hogy minden tanúsítvány az érvényességi ablakán belül van, és igazolja, hogy az alapvető megkötések és a kulcshasználat engedik a kibocsátónak az aláírást. Csak ezután néz az alkalmazás a levéltanúsítványra: a tárgy alternatív neveinek le kell fedniük a tárcsázott nevet, a kiterjesztett kulcshasználatnak pedig engednie kell a kiszolgáló vagy ügyfél hitelesítését.

Ha ezt a bejárást offline szeretné megismételni, a -CAfile-t pontosan arra a csomagra irányítsa, amelyet telepíteni fog, ne a rendszer tárára. Különben a gazdagépet teszteli, nem a változást:

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

Ez a parancs csak egyszerű TLS-figyelő ellen működik, mint az átjáró HTTPS-adminisztrációs oldala; az OpenVPN vezérlőcsatornája megelőzi a TLS-t, ezért az s_client nem tudja megvizsgálni az alagút kézfogását.

A hibák mögötti útvonalépítési szabályok a RFC 5280 6-os szakaszában vannak. Megmagyarázzák azokat a hibákat, amelyek egyébként önkényesnek tűnnek: egy lejárt köztes tanúsítvány, amelyre senki nem emlékezett, egy tanúsítvány, amelynek kulcshasználata tiltja az aláírást, vagy egy névkorlátozás, amely kizárja a tesztelt gazdagépet.

Miért működik tovább a régi alagút

A TLS és az OpenVPN is életben tartja a létrehozott munkamenetet a kézfogás befejezése után. Semmi nem érvényesíti újra a partner tanúsítványát csomagonként, ezért a változás előtt csatlakozott ügyfél továbbra is viszi a forgalmat, míg újra nem tárgyal, újra nem csatlakozik, vagy az alagút el nem esik. Ez a rés teszi lehetővé, hogy egy CA-csere egy órán át jól nézzen ki, majd a legrosszabb pillanatban bukjon el: a laptop felébred az alvásból, lejár egy NAT-hozzárendelés, újraindul az átjáró.

A munkamenet-folytatás tovább nyújtja az illúziót. A TLS-munkamenetjegy lehetővé teszi az ügyfél visszatérését tanúsítványok újraküldése nélkül, a folytatás pedig kihagyja az útvonal-érvényesítést, mert az első kézfogás már megtette. A becsületes teszt tehát egy teljes kézfogás friss folyamatban. Indítsa újra az ügyfelet, ahelyett hogy újracsatlakoztatná az alagutat, és tesztprofilban fontolja meg a jegyek letiltását, hogy a folytatási útvonal ne rejthessen el egy törött láncot.

Tartsa külön ettől a statikus kulcs rétegét. A tls-auth HMAC-ot ad a vezérlőcsatornához, a tls-crypt titkosítja és hitelesíti, és egyik sem hordoz tanúsítvány-anyagot, ezért bármelyikük cseréje külön változás a saját hibaüzemmódjával. Azok a telepítések, amelyek összemossák a kettőt, olyan ügyféllel végzik, amelynek statikus kulcsa rendben van, a tanúsítványa elavult, és a hibaüzenete egyiket sem említi.

A tárgynév újrafelhasználásának csapdája

Csábító az előd megkülönböztető nevét újra felhasználni, hogy lentebb semminek ne kelljen változnia. Ez stabilan tartja a kibocsátó sorát a felületen, és elpusztítja az egyetlen jelet, amelyre szüksége van. Két azonos tárggyal és különböző kulccsal rendelkező tanúsítvány nem különböztethető meg név alapján, ezért a mindkét horgonyt tartalmazó csomag két jelöltet ad az érvényesítőnek, és semmilyen szabályt a választásra.

Az útvonalépítés aztán a rosszat választhatja, „nem szerezhető be a helyi kibocsátó tanúsítványa” üzenetet adhatja, miközben a helyes horgony jelen van, vagy sikeres lehet az egyik gazdagépen és meghiúsulhat egy másikon ugyanazzal a csomaggal, mert a jelöltek sorrendje eltért. Ha a nevet újra kell használni, a váltás alatt tartsa a két horgonyt külön fájlokban, és töltse be őket kifejezetten, és csak akkor vonja össze őket, amikor minden partner az új kibocsátót mutatja. Ellenkező esetben adjon a cserének megkülönböztető közös nevet — egy generációs vagy dátumutótag elég —, hogy a naplók és a hibaüzenetek megmondják, mely hatóság alatt adták ki a meghiúsuló partnert.

Olyan csere, amely nem viszi le a hálózatot

Tervezett csere esetén korlátozott ideig fogadja el mindkét horgonyt, ahelyett hogy egy lépésben váltana. Adja ki az új CA-t és a köztes tanúsítványait, tegye az új horgonyt minden érvényesítő csomagjába a régi mellé, és csak ezután kezdjen partner-tanúsítványokat kiadni belőle. A régi identitású partnerek a régi horgony ellen érvényesülnek; az újak az új ellen működnek.

Ebben a sorrendben minden lépés visszafordítható. Az a hiba, amelyet elkerül, az egyidejű váltás, amikor egy csomagfrissítést kihagyó ügyfél olyan átjáróval találkozik, amely már visszavonta a régi horgonyt, a kézfogás meghal, és egyik napló sem mondja meg, melyik oldal elavult.

Ellenkező irányban vonjon ki. Adjon ki újra minden identitást, amelynek túl kell élnie, igazolja, hogy mindegyik az új láncot mutatja, majd távolítsa el a régi horgonyt a csomagokból. Vonja ki a régi CA privát kulcsát a szolgálatból, mert egy még aláírni képes kibocsátó azt jelenti, hogy a csere nem fejeződött be. Őrizze meg a tanúsítványokat és a kibocsátási nyilvántartásokat az audit számára. Az elveszett kibocsátó ugyanahhoz a bizalomhoz áll helyre; egy kitettség új identitásokat igényel, és nem lehet visszatérni a régi horgonyhoz.

Az eredményt ellenőrizze, ne a fájllistát

Egy bizalmi fájl a várt könyvtárban keveset bizonyít. Az alkalmazás más útvonalat, más formátumot vagy egy frissítés által lecserélt csomagban lévő példányt olvashat. Mindkét végén ellenőrizze a viselkedést, ne azt, hogy létezik-e egy fájl.

Igazolja, hogy egy új identitású friss kapcsolat sikerül, majd igazolja, hogy a visszavont CA által kiadott identitást elutasítják. Ez a második teszt az, amelyet az emberek kihagynak, és az egyetlen, amely megmutatja, hogy a régi hatóság már nem ad hozzáférést. Ahol a telepítés CRL-re vagy OCSP-re támaszkodik, ellenőrizze, hogy az új tanúsítványok elosztási pontjai feloldhatók, és hogy a kérdező partnerek elérik a válaszadót.

Fejezze be egy olyan ügyféllel, amely soha nem csatlakozott: törölje a profilja állapotát, csatlakozzon, és olvassa el a kialkudott láncot. Egy gyorsítótárazott munkamenetet folytató partner vidáman jelenti, hogy a migráció sikerült, miközben semmit nem érvényesített.