TLS štiti kanal između dvije krajnje točke i ne govori ništa o tome koje usluge se nalaze unutra. Omotač taj kanal pretvara u jedan konfigurirani prosljeđivač, za jednog slušatelja, prema jednoj destinaciji. Proizvod koji se prodaje kao SSL VPN obično dodaje sučelje, tablicu usmjeravanja i model pristupa oko istog primitiva. Zamijeniti to dvoje je način na koji se radni tunel pogrešno smatra mrežnim pristupom.

Što uslužni omotač zapravo povezuje

Omotač sluša na lokalnom portu i prosljeđuje ono što stigne na konfiguriranu destinaciju, bilo da je to host i port ili lokalni program. Tu destinaciju bira onaj tko je napisao konfiguracijsku datoteku, jedan slušatelj odjednom. Instaliranje paketa ne stvara rute, virtualno sučelje ni dostupnost za bilo što što nije izričito navedeno. Čitajte konfiguraciju prije opisa paketa, jer opis pokriva klasu upotrebe, a datoteka pokriva vašu.

Zato korisno pitanje o omotaču nije šifrira li, nego što 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 zaseban je mrežni skok sa svojom adresom i svojim pravilima pristupa.

Nađite gdje završava TLS kanal

Ako omotač završava TLS, sve što dalje prosljeđuje nova je veza s novim svojstvima. Tok može biti čisti tekst na privatnom segmentu ili može nositi drugi zaštićeni protokol u sebi. Pretpostaviti bilo što od toga bez čitanja konfiguracije pozadinskog sustava jest način na koji ljudi zaključe da vanjski sloj štiti podatke koje više nikada ne vidi. Proslijeđeni skok zaslužuje vlastitu provjeru, na svojoj adresi i portu.

Provjerite slušatelj i pozadinski sustav odvojeno, jer uspješ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 naredba pokazuje koji proces posjeduje port i na kojoj adresi sluša. Druga ispisuje certifikat koji klijent doista primi, a to je provjera identiteta koju broj porta ne može zamijeniti.

Što rutirana VPN dodaje, a omotač ne

Rutirana VPN instalira sučelje, preuzima vlasništvo nad odabranim prefiksima i integrira se s usmjeravanjem i politikom pristupa hosta. Svaka aplikacija na stroju ima koristi, a da ne zna da tunel postoji. Omotač daje taj doseg jednom konfiguriranom slušatelju i tu se zaustavlja.

Prihvat je opet odvojen. VPN koja autentificira klijenta još uvijek treba autorizaciju koja kaže kojim resursima klijent smije pristupiti, a omotač koji autentificira partnera još uvijek treba pozadinski sustav koji provodi vlastita dopuštenja.

Postoji legitiman spoj: VPN protokol prenesen unutar TLS omotača na namjerno podržanom TCP rasporedu. To slaže dva sloja i ne čini omotač i VPN istom vrstom objekta.

Usporedite granicu koja ne uspijeva

Zapišite adresu prednjeg kraja, slušatelj, identitet partnera, cilj pozadinskog sustava i operaciju aplikacije prije nego što bilo što promijenite. Zatim uspoređujte usporedivo s usporedivim: uspjeh kroz drugačije ime hosta ili port ne dokazuje da su uvjeti vatrozida i certifikata bili identični.

Odbijen zahtjev prema pozadinskom sustavu nikada se ne smije popravljati isključivanjem provjere identiteta prednjeg kraja. To mijenja dijagnosticiranu pogrešku autorizacije za nedijagnosticiranu pogrešku povjerenja.

curl -sv --resolve svc.example.net:443:203.0.113.10 https://svc.example.net/health 2>&1 | head -30

Pričvršćivanje imena na odabranu adresu odvaja razrješavanje imena od dostupnosti, a to je obično najbrži način da se otkrije što je od toga dvoje pokvareno.

Usporedba koja je važna imenuje zaštićeni par krajnjih točaka, preneseni teret, aplikacije koje ga koriste i dopuštenje koje se provodi na odredištu. TLS doprinosi tom opisu, ali ga ne upotpunjuje.

Povezani članci