TLS VPN mot IPsec: de fem fält som är värda att granska

Att rangordna TLS VPN:er mot IPsec VPN:er efter protokollfamilj besvarar en fråga ingen ställde, och det brukar hänvisa till en konstruktion som båda familjerna slutade använda för år sedan. Det en granskare faktiskt kan bedöma är det förhandlade skyddet, peer-identiteten, klientmodellen och den exponerade tjänsten. De fyra sakerna syns i en driftsättning, och ingen av dem följer av produktetiketten. Fråga efter fem fält och samtalet blir konkret.

Fem fält, och etiketten är inte ett av dem

Det första fältet är den stödda programvarureleasen, eftersom en protokollbeskrivning utan version är en broschyr. Det andra är den förhandlade protokollversionen, som avgör vilka konstruktioner som ens är tillgängliga. Det tredje är skyddssuiten, det fjärde är autentiseringsmetoden för både peer och användare, och det femte är den åtkomstomfattning produkten ger efter antagning.

En SSL VPN-etikett täcker minst tre olika produkter: en fullständig nätverksklient, en applikationsproxy och en äldre webbläsarbaserad portal. De exponerar olika tjänster och misslyckas olika, så etiketten kan inte ersätta omfattningsfältet.

Vad autentiserad kryptering faktiskt ändrar

TLS 1.3 kräver autentiserad kryptering, vilket tar bort den äldre MAC-then-encrypt-konstruktionen ur protokollet i stället för att göra den valfri. IPsec ESP har haft suiter för autentiserad kryptering lika länge, med AES-GCM definierat i en egen RFC. I båda familjerna kommer garantin från den förhandlade suiten och inte från familjenamnet, och därför börjar fältlistan med en version. En granskare som inte kan namnge suiten har inget att bedöma.

Det är därför den historiska jämförelsen är missvisande. En driftsättning låst till en gammal TLS-version med en CBC-suite och en som kör TLS 1.3 med en AEAD-suite är inte samma säkerhetsläge, även om båda är TLS VPN:er. Samma uppdelning finns på IPsec-sidan mellan en modern ESP-suite och en äldre kombination.

Läs de förhandlade värdena i stället för den konfiguration du avsåg. Kommandona nedan visar vad en levande ändpunkt och en levande tunnel faktiskt kom överens om.

openssl s_client -connect vpn.lab.example:443 -tls1_3 -brief
ip xfrm state
swanctl --list-sas

Om ändpunkten inte vill förhandla TLS 1.3 är det en iakttagelse och inte en preferens. Om tunneln listar en suite du inte förväntade dig är den konfiguration som spelar roll den som parterna valde, inte den i mallen.

Peer-identitet är en separat fråga

Kryptering utan en verifierad peer skyddar trafiken från observatörer och lämnar den till den som svarade på anslutningen. Peer-autentisering frågar vilken identitet som förväntas, vilket förtroendematerial som validerar den och hur klienten beter sig när svaret inte stämmer. En certifikatkedja, en fäst nyckel och en i förväg delad hemlighet är tre olika svar med tre olika driftskostnader.

Ställ sedan samma frågor om användaren eller enheten. En gateway som autentiserar maskinen och släpper in vilken användare som helst, eller tvärtom, har ett specifikt läge som bör skrivas ned i stället för antas. Resursbehörigheter som tillämpas efter antagning hör till samma fält, eftersom autentisering inte är auktorisering.

Att bevara värdnamns- och certifikatkontroller är viktigare än hur bekant inloggningsfönstret är. En klient som konfigurerats att ignorera verifiering har tagit bort det enda steget som skiljer din gateway från en övertygande imitation.

Gränsen som produkten exponerar

En klientlös portal proxar utvalda applikationsoperationer genom gatewayen, så användaren når ett gränssnitt i stället för ett nätverk. En fulltunnelklient bär vad dess rutter och filterpolicy väljer ut, vilket är en mycket större yta. Att jämföra de två efter protokollstyrka missar skillnaden i vad en angripare kan nå genom dem. Den ena exponerar ett applikationsgränssnitt, den andra ett routat nätverk, och de två kräver olika granskningar.

Fråga vilken tjänst som exponeras, vilka operationer som är auktoriserade och vad gatewayen själv lyssnar på. Ett administrationsgränssnitt som nås från samma adress som användarportalen är en driftsättningsiakttagelse, och inget protokollval kompenserar för det.

Omfattning per applikation minskar ytan ytterligare, och det ändrar också felbeteendet när tunneln faller. En design som förutsätter fulltunnelräckvidd går sönder på sätt som en per-app-design inte gör, och supportbelastningen följer.

Bestäm felutfallet och livscykeln

Vad som händer när autentisering eller skydd inte är tillgängligt är ett policybeslut som hör hemma i granskningen. Ett blockerat utfall och en oannonserad direkt återgång har olika konsekvenser, och skillnaden är osynlig i en funktionslista. Ange det avsedda beteendet bredvid resursen det skyddar.

Ta med gatewayens patch- och supportlivscykel, dess aktiverade externa funktioner och uppdateringsvägen för klienter. Ett korrekt protokollval gör inte en dåligt driftsatt tjänst säker, och de flesta incidenter ligger i den luckan snarare än i suiten.

Skriv de fem fälten, felpolicyn och livscykelägaren på en sida. Den sidan är en granskning; en jämförelse av protokollfamiljer är en åsikt.