Samopotpisani VPN certifikat: šta znači i kome vjeruje
Samopotpisani VPN certifikat i dalje šifrira saobraćaj. Ono što se mijenja jeste kome ste rekli da mu vjeruje, koje skladište prima to povjerenje i koje provjere ostaju.
Dva uvjerenja ovdje nanose najviše štete: da samopotpisani VPN certifikat znači da tunel nije šifriran i da instaliranje svega što VPN klijent zatraži djeluje samo na VPN. Nijedno ne preživi susret sa stvarnim postavljanjem. Samopotpisani certifikat opisuje odnos potpisa, a ne sigurnosnu presudu, a domet povjerenja koje dodajete zavisi od toga u koje skladište stigne. Gledao sam kako helpdesk uvozi korijen provajdera u Windows mašinu da ućuti jedno upozorenje, a zatim provede cijelo poslijepodne objašnjavajući zašto se preglednik prestao žaliti na nepovezani portal. Dvije polovine ovog pitanja pripadaju zajedno, pa ih tretirajte kao jedno.
Certifikat nije skladište povjerenja
Datoteka koju server predstavlja nosi javni ključ, ime subjekta, ime izdavaoca, datume važenja i ekstenzije. Samopotpisani znači da su subjekt i izdavalac isti entitet i da se potpis provjerava vlastitim ključem certifikata. Ništa u toj definiciji ne kaže da je veza slaba i ništa ne kaže da će je klijent prihvatiti.
Prihvatanje dolazi s drugog mjesta: CA datoteka na koju usmjerite klijenta, otisak koji ručno uporedite ili korijen koji već stoji u skladištu koje klijent čita. Postavljanje može biti savršeno ispravno dok bi njegov certifikat pao na svakom javnom testu. openssl verify prema sistemskom paketu prijavit će nepoznatog izdavaoca, a to izvješće je tačno, a ne kvar.
OpenVPN opcija ca najjasniji je slučaj povjerenja ograničenog na aplikaciju. Ta datoteka imenuje ankere koje će klijent prihvatiti i može sadržavati jedan privatni CA ili, u malom postavljanju, vlastiti samopotpisani certifikat servera. Verzija 2.6 također prihvata --peer-fingerprint za pinovanje SHA-256 otiska umjesto distribucije CA datoteke. WireGuard stoji još dalje: u njemu uopće nema certifikata, samo statički javni ključ po peeru, pa se pitanje samopotpisivanja na njega ne preslikava.
Gdje instalirate povjerenje određuje ko ga nasljeđuje
Stavite isti certifikat na tri mjesta i dobit ćete tri različita radijusa eksplozije. Paket koji čita samo VPN klijent utječe na taj klijent. Korijen u skladištu operativnog sistema utječe na svaki program koji konsultuje to skladište. Preglednik s vlastitom bazom povjerenja može ignorisati oba, zbog čega upozorenje može preživjeti uvoz koji je izgledao uspješan.
Na Debianu ili Ubuntuu, spuštanje datoteke u /usr/local/share/ca-certificates/ i pokretanje update-ca-certificates mijenja sistemski paket. Na Windowsu certutil -addstore -f Root piše u mašinsko skladište i traži povišeni prompt, dok dodavanje -user cilja skladište trenutnog korisnika; to dvoje nije zamjenjivo. Firefox drži vlastitu NSS bazu, pa se uvoz na nivou OS-a možda nikad neće pojaviti tamo.
Obim je važan zbog onoga što jedno tijelo može učiniti. Izdavački CA može potpisivati imena s kojima nema nikakve veze, pa će sve što vjeruje tom skladištu prihvatiti te potpise. Jedan pinovani list to ne može; on autentificira tačno jedan identitet peera. Ako je cilj da se jedan VPN poveže, CA ograničen na aplikaciju ili pinovani list to postiže, dok je korijen na nivou mašine daleko veći ustupak nego što simptom zahtijeva.
Još uvijek šifrirate bez javnog CA
TLS rukovanje izvodi sesijske ključeve bez obzira na to da li se certifikat peera lančano veže na nešto čemu već vjerujete. Samopotpisani ne znači običan tekst i ne znači da je saobraćaj čitljiv u letu. Znači da klijent nema apriorni razlog vjerovati da ključ pripada serveru koji je tražio.
U tom jazu žive pravi napadi. Klijent konfigurisan da prihvati bilo koji certifikat, bilo kroz isključenu postavku provjere bilo kroz dugme „vjeruj ipak“ pritisnuto jednom i zaboravljeno, šifrirat će rado onome ko odgovori. Presretanje se događa u koraku autentifikacije, prije nego što se podaci aplikacije pomjere. Šifriranje bez provjere identiteta drži pasivnog posmatrača vani i čini malo šta drugo.
Povjerenje u izdavaoca ne preskače provjeru imena
Validacija lanca, podudaranje imena i namjena certifikata odvojene su odluke. Lanac može biti valjan dok je ime pogrešno, a ime se može podudarati dok je certifikat izdan za drugu ulogu. RFC 5280 definiše polja koja nose ta ograničenja, a koliko ih strogo klijent provodi pitanje je za svaku aplikaciju.
OpenVPN čini podjelu vidljivom. verify-x509-name pinuje očekivani subjekt kroz podudaranje name, name-prefix ili subject. remote-cert-tls server zahtijeva da certifikat peera bude upotrebljiv kao serverski certifikat, što odbija certifikat samo za klijenta čak i kada je izdavalac pouzdan. Nijedna postavka nije zamijenjena slanjem CA datoteke.
Pregledajte certifikat prije nego što bilo šta odlučite:
openssl x509 -in server.crt -noout -subject -issuer -dates -ext subjectAltNamepokazuje ko ga je izdao, za koja imena i do kada.openssl verify -CAfile ca.crt server.crtprovjerava da li lanac koji planirate poslati zaista validira list.openssl s_client -connect vpn.example.net:443 -servername vpn.example.net -CAfile ca.crt -verify_return_errorradi za TLS krajnje tačke kao što je web portal; OpenVPN protokol na 1194 nije običan TLS tok, pa se taj test tamo ne primjenjuje.
Certifikat s istekom datuma, bez subjectAltName za ime na koje se povezujete ili bez korištenja serverAuth pada bez obzira na to koliko je sidro pažljivo instalirano.
Pet provjera prije nego što prihvatite jedan
Uporedite otisak preko kanala koji nije veza koju pokušavate popraviti: konzola, instalater koji već imate, potpisana konfiguracijska datoteka. openssl x509 -in server.crt -noout -fingerprint -sha256 na serveru i ista vrijednost u klijentskom zapisu dovoljni su da znate da gledate jedan objekt.
Zatim odlučite šta instalirate: jedan list ili tijelo koje može iskovati još. Tada odredite gdje ide i imenujte aplikacije koje čitaju to skladište. Zapišite put uklanjanja dok ga se još sjećate, jer „vjeruj i kreni dalje“ je način na koji privremeni uvoz postaje trajan.
Na kraju, planirajte promjenu. Pinovani certifikat ili otisak mora se ažurirati kroz isti pouzdani kanal kada se certifikat zarotira, a privatni CA ima vlastiti životni ciklus izdavanja i opoziva. Ako privatni ključ iscuri, ponovno povjerenje u kopiju istog certifikata ništa ne popravlja; identitet se mora zamijeniti.
Ako upozorenje preživi svih pet provjera, korisno pitanje nije koje dugme ga ućutkuje nego koje skladište klijent zapravo čita i odakle je taj korijen došao. Odgovorite na to i uvoz koji ćete upravo napraviti postaje odluka, a ne refleks.