TLS VPN laban sa IPsec: ang limang larangang dapat suriin
Ihambing ang TLS VPN at IPsec VPN ayon sa release, bersyon ng protocol, suite, pagkakakilanlan ng peer at nakalantad na saklaw, kasama ang kinalabasan ng pagkabigo na talagang na-configure mo.
Ang pagraranggo ng mga TLS VPN laban sa mga IPsec VPN ayon sa pamilya ng protocol ay sumasagot sa tanong na walang nagtanong, at karaniwang sumisipi ng konstruksiyon na iniwan ng parehong pamilya maraming taon na ang nakalipas. Ang tunay na masusuri ng isang tagasuri ay ang napagkasunduang proteksiyon, ang pagkakakilanlan ng peer, ang modelo ng kliyente at ang nakalantad na serbisyo. Ang apat na bagay na ito ay nakikita sa isang deployment, at wala sa mga ito ang nagmumula sa label ng produkto. Humingi ng limang larangan at nagiging konkretong usapan.
Limang larangan, at ang label ay hindi isa sa kanila
Ang unang larangan ay ang sinusuportahang release ng software, dahil ang paglalarawan ng protocol na walang bersyon ay isang polyeto. Ang ikalawa ay ang napagkasunduang bersyon ng protocol, na nagtatakda kung aling mga konstruksiyon ang magagamit. Ang ikatlo ay ang suite ng proteksiyon, ang ikaapat ay ang paraan ng pagpapatotoo para sa peer at user, at ang ikalima ay ang saklaw ng pag-access na ibinibigay ng produkto pagkatapos ng pagtanggap.
Ang label na SSL VPN ay sumasakop sa hindi bababa sa tatlong magkaibang produkto: isang buong network client, isang application proxy at isang lumang portal na nakabatay sa browser. Naglalantad sila ng magkaibang serbisyo at nabibigo nang iba, kaya hindi kayang palitan ng label ang larangan ng saklaw.
| Field | What a usable answer looks like |
|---|---|
| Release | A version with a support window, not a family name |
| Protocol version | TLS 1.3 or IKEv2 with the ESP suite named |
| Protection suite | An authenticated-encryption algorithm, not a cipher list |
| Authentication | Peer identity plus user or device identity, separately |
| Access scope | The services reachable after admission |
Ano ang aktwal na binabago ng authenticated encryption
Ang TLS 1.3 ay nangangailangan ng authenticated encryption, na nag-aalis ng mas lumang MAC-then-encrypt na konstruksiyon mula sa protocol sa halip na iwanan itong opsyonal. Ang IPsec ESP ay may mga suite ng authenticated encryption nang ganoon na rin katagal, na may AES-GCM na tinukoy sa sarili nitong RFC. Sa parehong pamilya, ang garantiya ay nagmumula sa napagkasunduang suite at hindi sa pangalan ng pamilya, kaya nagsisimula ang listahan ng larangan sa isang bersyon. Ang tagasuring hindi makapangalan sa suite ay walang masusuri.
Kaya ang makasaysayang paghahambing ay nakaliligaw. Ang deployment na nakapirmi sa lumang bersyon ng TLS na may CBC suite at ang isa na nagpapatakbo ng TLS 1.3 na may AEAD suite ay hindi parehong kalagayan ng seguridad, kahit pareho silang TLS VPN. Ang parehong paghahati ay umiiral sa panig ng IPsec sa pagitan ng modernong ESP suite at lumang kombinasyon.
Basahin ang mga napagkasunduang halaga sa halip na ang konfigurasyong nilayon mo. Ipinapakita ng mga utos sa ibaba kung ano talaga ang napagkasunduan ng buhay na endpoint at buhay na tunnel.
openssl s_client -connect vpn.lab.example:443 -tls1_3 -brief
ip xfrm state
swanctl --list-sas
Kung ayaw ng endpoint na makipagkasundo sa TLS 1.3, ito ay isang natuklasan at hindi kagustuhan. Kung naglilista ang tunnel ng suite na hindi mo inaasahan, ang konfigurasyong mahalaga ay ang pinili ng mga peer, hindi ang nasa template.
Ang pagkakakilanlan ng peer ay hiwalay na tanong
Ang encryption na walang beripikadong peer ay nagpoprotekta sa trapiko mula sa mga tagamasid at ibinibigay ito sa sinumang sumagot sa koneksiyon. Ang pagpapatotoo ng peer ay nagtatanong kung anong pagkakakilanlan ang inaasahan, anong trust material ang nagpapatunay nito, at paano kumikilos ang kliyente kapag hindi tumutugma ang sagot. Ang certificate chain, naka-pin na key at pre-shared secret ay tatlong magkaibang sagot na may tatlong magkaibang gastos sa operasyon.
Pagkatapos, itanong ang parehong mga tanong tungkol sa user o device. Ang gateway na nagpapatotoo sa makina at tumatanggap ng kahit sinong user, o kabaliktaran, ay may partikular na kalagayan na dapat isulat sa halip na ipagpalagay. Ang mga pahintulot sa resource na inilalapat pagkatapos ng pagtanggap ay bahagi ng parehong larangan, dahil ang pagpapatotoo ay hindi awtorisasyon.
Ang pagpapanatili ng mga pagsusuri sa hostname at certificate ay mas mahalaga kaysa sa pagiging pamilyar ng login window. Ang kliyenteng naka-configure na huwag pansinin ang beripikasyon ay nag-alis ng tanging hakbang na nagtatangi sa iyong gateway mula sa kapani-paniwalang pagkakapareho.
Ang hangganang inilalantad ng produkto
Ang portal na walang kliyente ay nagpo-proxy ng piling operasyon ng application sa gateway, kaya nakakarating ang user sa isang interface at hindi sa isang network. Ang full-tunnel na kliyente ay nagdadala ng anumang pinipili ng mga ruta at patakaran sa pag-filter nito, na mas malaking ibabaw. Ang paghahambing sa dalawa ayon sa lakas ng protocol ay nakaliligta ng pagkakaiba sa maaaring marating ng attacker sa pamamagitan ng mga ito. Ang isa ay naglalantad ng interface ng application, ang isa ay ng niruruta na network, at ang dalawa ay nangangailangan ng magkaibang pagsusuri.
Itanong kung aling serbisyo ang nakalantad, aling operasyon ang awtorisado at ano ang pinakikinggan ng gateway mismo. Ang management interface na maabot mula sa parehong address ng user portal ay isang natuklasan sa deployment, at walang pagpipilian ng protocol ang makakabawi para dito.
Ang saklaw kada application ay lalong nagpapaliit sa ibabaw, at binabago rin nito ang pag-uugali sa pagkabigo kapag bumagsak ang tunnel. Ang disenyong ipinapalagay ang abot ng full tunnel ay masisira sa mga paraang hindi alam ng disenyo kada app, at sumusunod ang karga sa suporta.
Magpasya sa kinalabasan ng pagkabigo at sa lifecycle
Ang nangyayari kapag hindi available ang pagpapatotoo o proteksiyon ay desisyon sa patakaran na kabilang sa pagsusuri. Ang naka-block na kinalabasan at hindi inanunsyong direktang pagbalik ay may magkaibang bunga, at ang pagkakaiba ay hindi nakikita sa listahan ng feature. Isaad ang nilalayong pag-uugali sa tabi ng resource na pinoprotektahan nito.
Isama ang patch at support lifecycle ng gateway, ang mga naka-enable na external feature nito at ang update path para sa mga kliyente. Ang tamang pagpili ng protocol ay hindi nagpapaging ligtas sa masamang na-deploy na serbisyo, at karamihan ng insidente ay nasa puwang na iyon at hindi sa suite.
Isulat ang limang larangan, ang patakaran sa pagkabigo at ang may-ari ng lifecycle sa isang pahina. Ang pahinang iyon ay isang pagsusuri; ang paghahambing ng mga pamilya ng protocol ay isang opinyon.