Daje li vam TLS omotač privatnu mrežu? Obično ne
Omotač štiti jednu konfigurisanu vezu između svojih krajnjih tačaka. Rutirana VPN prenosi saobraćaj za svaku aplikaciju, što je drugačiji model pristupa.
TLS štiti kanal između dve krajnje tačke i ne govori ništa o tome koje usluge se nalaze unutra. Omotač taj kanal pretvara u jedan konfigurisani prosleđivač, za jednog slušaoca, ka jednoj destinaciji. Proizvod koji se prodaje kao SSL VPN obično dodaje interfejs, tabelu rutiranja i model pristupa oko istog primitiva. Mešanje to dvoje je način na koji se radni tunel zameni za mrežni pristup.
Šta uslužni omotač zapravo povezuje
Omotač sluša na lokalnom portu i prosleđuje ono što stigne na konfigurisanu destinaciju, bilo da je to host i port ili lokalni program. Tu destinaciju bira onaj ko je napisao konfiguracionu datoteku, po jedan slušalac odjednom. Instaliranje paketa ne stvara rute, virtuelni interfejs ni dostupnost za bilo šta što nije izričito navedeno. Čitajte konfiguraciju pre opisa paketa, jer opis pokriva klasu upotrebe, a datoteka pokriva vašu.
Zato korisno pitanje o omotaču nije da li šifruje, nego šta stoji na svakom kraju lanca koji gradi.
application -> local listener -> TLS connection -> remote listener -> configured backend
Taj lanac čitajte iz konfiguracije, a ne iz marketinškog naziva. Svaka strelica je zaseban mrežni skok sa svojom adresom i svojim pravilima pristupa.
Nađite gde se TLS kanal završava
Ako omotač završava TLS, sve što dalje prosleđuje nova je veza sa novim svojstvima. Tok može biti čist tekst na privatnom segmentu ili može nositi drugi zaštićeni protokol u sebi. Pretpostaviti bilo šta od toga bez čitanja konfiguracije pozadinskog sistema jeste način na koji ljudi zaključe da spoljni sloj štiti podatke koje više nikada ne vidi. Prosleđeni skok zaslužuje sopstvenu proveru, na svojoj adresi i portu.
Proverite slušaoca i pozadinski sistem odvojeno, jer uspešno rukovanje na ulaznim vratima ne govori ništa o usluzi iza njih.
ss -ltnp | grep -F 443 openssl s_client -connect svc.example.net:443 -servername svc.example.net </dev/null | openssl x509 -noout -subject -dates
Prva komanda pokazuje koji proces poseduje port i na kojoj adresi sluša. Druga ispisuje sertifikat koji klijent zaista primi, a to je provera identiteta koju broj porta ne može zameniti.
Šta rutirana VPN dodaje, a omotač ne
Rutirana VPN instalira interfejs, preuzima vlasništvo nad odabranim prefiksima i integriše se sa rutiranjem i politikom pristupa hosta. Svaka aplikacija na mašini ima koristi, a da ne zna da tunel postoji. Omotač daje taj doseg jednom konfigurisanom slušaocu i tu se zaustavlja.
Prihvat je opet odvojen. VPN koja autentifikuje klijenta još uvek treba autorizaciju koja kaže kojim resursima klijent sme pristupiti, a omotač koji autentifikuje partnera još uvek treba pozadinski sistem koji sprovodi sopstvene dozvole.
Postoji legitiman spoj: VPN protokol prenesen unutar TLS omotača na namerno podržanom TCP rasporedu. To slaže dva sloja i ne čini omotač i VPN istom vrstom objekta.
Uporedite granicu koja ne uspeva
Zapišite adresu prednjeg kraja, slušaoca, identitet partnera, cilj pozadinskog sistema i operaciju aplikacije pre nego što bilo šta promenite. Zatim upoređujte uporedivo sa uporedivim: uspeh kroz drugačije ime hosta ili port ne dokazuje da su uslovi zaštitnog zida i sertifikata bili identični.
Odbijen zahtev prema pozadinskom sistemu nikada se ne sme popravljati isključivanjem provere identiteta prednjeg kraja. To menja dijagnostikovanu grešku autorizacije za nedijagnostikovanu grešku poverenja.
curl -sv --resolve svc.example.net:443:203.0.113.10 https://svc.example.net/health 2>&1 | head -30
Pričvršćivanje imena za odabranu adresu razdvaja razrešavanje imena od dostupnosti, a to je obično najbrži način da se otkrije šta je od to dvoje pokvareno.
Poređenje koje je važno imenuje zaštićeni par krajnjih tačaka, preneseni teret, aplikacije koje ga koriste i dozvolu koja se sprovodi na odredištu. TLS doprinosi tom opisu, ali ga ne upotpunjuje.