Samopodepsaný certifikát VPN: co znamená a čemu důvěřuje

Nejvíc škody tu působí dvě přesvědčení: že samopodepsaný certifikát VPN znamená, že tunel není šifrovaný, a že instalace čehokoli, o co si klient VPN požádal, ovlivní jen VPN. Ani jedno nepřežije střet se skutečným nasazením. Samopodepsaný certifikát popisuje vztah podpisu, ne bezpečnostní verdikt, a dosah důvěry, kterou přidáte, závisí na tom, do kterého úložiště se dostane. Viděl jsem helpdesk importovat kořen poskytovatele do stroje s Windows, aby umlčel jedno varování, a pak strávit odpoledne vysvětlováním, proč si prohlížeč přestal stěžovat na nesouvisející portál. Obě poloviny této otázky patří k sobě, tak s nimi zacházejte jako s jednou.

Certifikát není úložiště důvěry

Soubor, který server předkládá, nese veřejný klíč, jméno subjektu, jméno vydavatele, data platnosti a rozšíření. Samopodepsaný znamená, že subjekt a vydavatel jsou stejná entita a podpis se ověřuje vlastním klíčem certifikátu. Nic v této definici neříká, že je spojení slabé, a nic neříká, že ho klient přijme.

Přijetí přichází odjinud: soubor CA, na který klienta nasměrujete, otisk, který porovnáte ručně, nebo kořen, který už leží v úložišti, jež klient čte. Nasazení může být naprosto v pořádku, i když by jeho certifikát propadl u každého veřejného testu. openssl verify proti systémovému svazku nahlásí neznámého vydavatele, a to hlášení je správné, nikoli závada.

Volba ca v OpenVPN je nejjasnější případ důvěry omezené na aplikaci. Tento soubor pojmenovává kotvy, které klient přijme, a může obsahovat jednu soukromou CA nebo v malém nasazení vlastní samopodepsaný certifikát serveru. Verze 2.6 přijímá také --peer-fingerprint pro připnutí otisku SHA-256 místo distribuce souboru CA. WireGuard stojí ještě dál: nemá vůbec žádné certifikáty, jen statický veřejný klíč pro každého protějška, takže se na něj otázka samopodpisu nepřenáší.

Kde důvěru nainstalujete, rozhoduje, kdo ji zdědí

Umístěte stejný certifikát na tři místa a získáte tři různé poloměry zásahu. Svazek, který čte jen klient VPN, ovlivní tohoto klienta. Kořen v úložišti operačního systému ovlivní každý program, který toto úložiště konzultuje. Prohlížeč s vlastní databází důvěry může ignorovat obojí, a proto varování může přežít import, který vypadal, že funguje.

V Debianu nebo Ubuntu změna souboru v /usr/local/share/ca-certificates/ a spuštění update-ca-certificates mění systémový svazek. Ve Windows certutil -addstore -f Root zapisuje do úložiště stroje a vyžaduje zvýšený příkazový řádek, zatímco přidání -user cílí na úložiště aktuálního uživatele; tato dvě nejsou zaměnitelná. Firefox si drží vlastní databázi NSS, takže import na úrovni OS se tam nemusí nikdy objevit.

Rozsah je důležitý kvůli tomu, co může autorita udělat. Vydávající CA může podepisovat jména, se kterými nemá žádný vztah, takže vše, co této úložišti důvěřuje, tyto podpisy přijme. Jediný připnutý list to nedokáže; autentizuje přesně jednu identitu protějška. Pokud je cílem rozchodit jedno VPN připojení, CA omezená na aplikaci nebo připnutý list toho dosáhne, zatímco kořen pro celý stroj je mnohem větší ústupek, než symptom vyžaduje.

Stále šifrujete bez veřejné CA

TLS handshake odvozuje klíče relace bez ohledu na to, zda se certifikát protějšku řetězí k něčemu, čemu už důvěřujete. Samopodepsaný neznamená otevřený text a neznamená, že je provoz za letu čitelný. Znamená, že klient nemá apriorní důvod věřit, že klíč patří serveru, o který požádal.

V této mezeře žijí skutečné útoky. Klient nastavený přijímat jakýkoli certifikát, ať už vypnutým nastavením ověřování nebo tlačítkem „přesto důvěřovat“ stisknutým jednou a zapomenutým, bude ochotně šifrovat komukoli, kdo odpoví. Zachycení probíhá v kroku autentizace, než se data aplikace pohnou. Šifrování bez kontroly identity udrží pasivního pozorovatele venku a moc dalšího nedělá.

Důvěra ve vydavatele nepřeskočí kontrolu jména

Ověření řetězce, shoda jména a účel certifikátu jsou samostatná rozhodnutí. Řetězec může být platný, zatímco jméno je špatné, a jméno může odpovídat, zatímco certifikát byl vydán pro jinou roli. RFC 5280 definuje pole, která tato omezení nesou, a jak přísně je klient vymáhá, je věcí každé aplikace.

OpenVPN dělá rozdělení viditelným. verify-x509-name připíná očekávaný subjekt pomocí shody name, name-prefix nebo subject. remote-cert-tls server vyžaduje, aby certifikát protějšku byl použitelný jako serverový certifikát, což odmítne certifikát jen pro klienta, i když je vydavatel důvěryhodný. Žádné z těchto nastavení se nenahrazuje dodáním souboru CA.

Prohlédněte si certifikát, než cokoli rozhodnete:

• openssl x509 -in server.crt -noout -subject -issuer -dates -ext subjectAltName ukazuje, kdo ho vydal, pro která jména a do kdy.
• openssl verify -CAfile ca.crt server.crt ověřuje, zda řetězec, který plánujete dodat, skutečně validuje list.
• openssl s_client -connect vpn.example.net:443 -servername vpn.example.net -CAfile ca.crt -verify_return_error funguje pro koncové body TLS, jako je webový portál; protokol OpenVPN na 1194 není obyčejný TLS proud, takže se tam tento test neuplatní.

Certifikát s prošlým datem, bez subjectAltName pro jméno, ke kterému se připojujete, nebo bez použití serverAuth selže bez ohledu na to, jak pečlivě byla kotva nainstalována.

Pět kontrol, než jeden přijmete

Porovnejte otisk kanálem, který není spojením, jež se snažíte opravit: konzole, instalátor, který už máte, podepsaný konfigurační soubor. openssl x509 -in server.crt -noout -fingerprint -sha256 na serveru a stejná hodnota v protokolu klienta stačí, abyste věděli, že se díváte na jeden objekt.

Dále rozhodněte, co instalujete: jeden list, nebo autoritu, která může razit další. Pak rozhodněte, kam půjde, a pojmenujte aplikace, které toto úložiště čtou. Zapište cestu odstranění, dokud si ji ještě pamatujete, protože důvěřuj-a-jdi-dál je způsob, jak se dočasný import stane trvalým.

Nakonec naplánujte změnu. Připnutý certifikát nebo otisk je nutné při rotaci certifikátu aktualizovat stejným důvěryhodným kanálem a soukromá CA má vlastní životní cyklus vydávání a odvolávání. Pokud soukromý klíč unikne, opětovná důvěra ke kopii stejného certifikátu nic nespraví; identita musí být nahrazena.

Pokud varování přežije všech pět kontrol, užitečná otázka není, které tlačítko ho umlčí, ale které úložiště klient skutečně čte a odkud ten kořen přišel. Odpovězte na to a import, který se chystáte provést, se stane rozhodnutím místo reflexu.