Limitations of IPsec, TLS/SSL, and SSH as VPN-solutions

Limitations of IPsec, TLS/SSL, and SSH as VPN-solutions Tarjei Mandt 04HMISA, Høgskolen i Gjøvik 10. oktober, 2005 Abstract I dag finnes det et flertall ulike VPN-løsninger man kan benytte seg av. Avhengig av hvilken type sikkerhet man ønsker og hvilke type applikasjoner man jobber med, kan VPN i større grad oppfylle kravene til integritet, tilgjengelighet og konfidensialitet som dagens samfunn stiller. I denne artikkelen ser vi på begrensningene som ligger i teknologier som IPsec, TLS/SSL og SSH, og ser på situasjoner hvor disse ikke holder som VPN-løsninger. 1 Introduksjon VPN, eller Virtual Private Network, er et privat kommunikasjonsnettverk som kan benyttes av bedrifter og organisasjoner for å kommunisere over et offentlig nett (f.eks. Internett). Grovt kan man dele VPN inn i 2 typer, sikret (secured) og tiltrodd (trusted). En sikret VPN benytter kryptiske tunnelprotokoller for å oppnå informasjonsikkerhetsmålene. Når et slikt VPN nett er ordentlig satt opp og konfigurert vil man kunne kommunisere sikkert over et eksisterende usikret nett. Til sammenlikning så benytter en såkalt tiltrodd VPN seg ikke av kryptering. I stedet så ligger nettverksikkerheten i leverandørens hender. Et eksempel på en tiltrodd VPN er Multi-protocol Label Switching (MPLS), uten at det skal gåes nærmere inn på slike typer VPNer her. 2 IPsec (IP Security) IPsec (IP Security) er en samling protokoller som opererer på nettverkslaget av OSI modellen (layer 3). Protokollfamilien ble utviklet i forbindelse med 1

etablering av en krypteringsbasert sikkerhetsarkitektur for IPv6. Underveis fant man også ut at denne sikkerhetsarkitekturen også kunne bli brukt for IPv4. Tanken bak IPsec er å sikre pakkeflyt og nøkkelutveksling gjennom bruk av autentisering og kryptering. Det at den opererer på nettverkslaget gjør IPsec ideell for sikring av både TCP- og UDP-pakker. I Authentication Header (AH) protokollen legges det vekt på integritet og autentisering av IP pakken og det som eventuelt skulle følge. Konfidensialitet er her uvesentlig. I en pengetransaksjon for eksempel vil du være sikker på at ingen endrer beløpet underveis men det er likegyldig om noen får kjennskap til mengden som overføres. I Encapsulating Security Payload (ESP) protokollen derimot blir IP pakker kryptert. ESP har også støtte for autentisering, men her blir ikke IP headeren under ESP headeren beskyttet. Både AH og ESP kan benyttes i Transport og Tunnel mode. Forskjellen mellom de to ligger i hvilke protokoller man ønsker sikkerhet på. Transport mode vil i hovedsak beskytte protokoller på de øverste lagene. I tunnel mode vil hele IP pakken bli pakket inn av en ny IP header. På denne måten kan man skjule opprinnelige sender og endelige mottaker og dermed også forhindre trafikkanalyse. En kjent begrensing med IPsec er inkompatibiliteten ved bruk av NAT. Network Address Translation brukes til å mappe lokale IP adresser (f.eks. 192.168.0.x) til et mindre antall offentlige IP adresser, slik at man reduserer behovet for disse. Dette vil også usynliggjøre komponenter som står bak NAT routeren for de som befinner seg utenfor. Da en pakke traverserer gjennom en NAT router vil routeren endre IP adressen i IP header, slik at den sendes til riktig mottaker innad i NAT nettverket eller at den lokale adressen endres til den offentlige adressen. Ved bruk av AH er man klar over at felt som TTL og header checksum endres underveis slik at disse ikke inkluderes i autentiseringsprosedyren. Det som derimot også er tilfellet er at AH inkluderer IP adressen i noe som kalles en integrity check value eller ICV og denne vil sjekkes hos mottaker. Fordi generering av en ICV hash også benytter en hemmelig nøkkel som bare sender og mottaker kjenner, vil ikke NAT routeren være i stand til å generere en ny ICV. Resultatet er at mottaker vil kaste pakken da ICV hashen ikke stemmer. Det samme problemet gjelder også Port Address Translation hvor man ikke bare mapper lokale adresser til en offentlig adresse, men også portnummere i eksempelvis UDP og TCP. Dette problemet gjelder imidlertid ikke i ESP (Encapsulated Security Payload) da hverken autentisering eller kryptering her berører IP headeren som modifiseres av NAT. Et annet problem som vil oppstå i forbindelse med bruk av IPsec og NAT er forbindelsesorientering. I TCP og UDP benyttes portnumre for å holde rede på hvem innad i NAT nettverket som skal motta en pakke, mens i IPsec vil ikke dette kunne løses uten spesielle løsninger for NAT traversering. 2

IPsec egner seg heller ikke i situasjoner der mange Security Associations (SA) er tilknyttet og i bruk samtidig da ytelse blir betraktelig redusert. En security association består av en sikkerhetsparameterindeks, en IP-destinasjonsadresse og en sikkerhetsprotokollidentifikator (AH eller ESP) som til sammen definerer en motpart. Metoder for å håndtere distribusjon og bruk av nøkkelmateriell i et omfattende VPN miljø kan bedre responstiden til IPsec VPNer for tidssensitive ende-til-ende forbindelser, som for eksempel for Voice over IP (VoIP) applikasjoner. Det finnes heller ingen tydelig standard for transportering og oppsett av routing protokoller mellom IPsec gatewayer, og det finnes generelt lite informasjon om dynamic routing ved bruk av IPsec i tunnel mode. IPsec har også mangelfull evne til å samarbeide ( interoperate ), og begge parter (sender og mottaker) er som regel nødt til å benytte komponenter fra samme leverandør. Til slutt må det nevnes at IPsec har et hav av konfigurasjonsmuligheter og noen mener også at det er alt for mange. Noen av disse konfigurasjonsmulighetene kan også resultere i usikre arkitekturer. Kompleksitet er sikkerhetens fiende og dette kommer tydelig frem her. IPsec VPN må dessuten implementeres i kernel, i motsetning til eksempelvis SSL og SSH. Dette er uheldig da en kompromittert komponent med kerneltilkobling kan gi roottilgang. 3 SSL (Secure Sockets Layer) SSL protokollen befinner seg mellom TCP og applikasjon og blir mest brukt til å beskytte HTTP transaksjoner, men er langt fra kun begrenset til dette. SSL (Secure Sockets Layer) og TLS (Transport Layer Security) kan betraktes som det samme da TLS er den nyeste versjonen og arvtakeren til SSL (TLS er utviklet av IETF, SSL av Netscape). SSL tilbyr autentisering og sikker ende-til-ende kommunikasjon over Internett gjennom bruk av kryptering. SSL består av fire protokoller: Handshake protokoll, Change Cipher Spec protokoll, Alert protokoll og Application Data protokoll. I korte trekk benyttes Handshake protokollen til autentisering og nøkkelutveksling. Nøkkelutvekslingen skjer enten gjennom RSA eller Diffie-Hellman. Change Cipher Spec protokollen spesifiserer at en valgt nøkkel vil bli brukt, Alert protokollen gir signal dersom det forekommer feil eller sesjonen stenges, og Application Data protokollen sender og mottar kryptert data. En ulempe ved SSL protokollen er at den kun støtter TCP applikasjoner. UDP vil ikke fungere da data kan forsvinne eller komme i feil rekkefølge. IPsec løser dette problemet ved å legge til en ny TCP header til UDP pakken. 3

En annen ulempe med SSL er rekkefølgen de kryptiske operasjonene blir gjort. I motsetning til IPsec, lager SSL en MAC for klarteksten først for så å kryptere den. Dette gjør at SSL blir nødt til å dekryptere alle mottatte pakker for å sjekke at MAC stemmer, og dette selv om pakken har blitt modifisert underveis, noe som kan bli sett på som sløsing av prosessorressurser. Det er ingen hemmelighet at SSL krever mye ressurser. En studie viser at 70% av prosseseringstiden til en HTTPS transaksjon blir brukt til SSL. Mesteparten av dette skjer under etablering av en session da liten mengde data sendes (feks i banktransaksjoner). Det er først når datamengden overstiger 32K bytes for en session at algoritmene for datakryptering er avgjørende for ytelsen. I et VPN miljø med begrenset båndbredde (f.eks. dial-up) er komprimering av data en viktig faktor. SSL støtter ikke dette. I og med at SSL befinner seg på applikasjonslaget må støtte for SSL også implementeres inn i applikasjonene. Enheter med begrensede ressurser som mobiltelefoner og PDAer kan dermed bruke lang tid på å utføre oppgaver i SSL applikasjoner. Det kan heller ikke sies at skalerbarheten til SSL VPN er spesielt god. Dersom en bedrift har N forskjellige servere, ville det vært nødvendig å ha O(N 2 ) ende-til-ende SSL forbindelser og hver server måtte vedlikeholde innhold i routing tabellen for (N 1) andre servere. 4 SSH (Secure Shell) SSH (Secure Shell) er en applikasjon og protokoll utviklet av finnen Tatu Ylönen for innlogging og kommandokjøring på arbeidsstasjoner over et nettverk. SSH erstatter tidligere brukte protokoller som rlogin, TELNET og rsh og tilbyr sikker kryptert kommunikasjon mellom to parter over et åpent nett. Versjon 1 av SSH ble utgitt som open source i 1995, og ble fulgt opp av SSH-2 året etter. SSH-2 tilbyr bedre sikkerhet og funksjonalitet enn forgjengeren, noe som kommer frem i bruk av Diffie-Hellman nøkkelutveksling og integritetsjekk ved hjelp av MAC. SSH kan benyttes i flere ulike sammenhenger, blant annet FTP, rcp filoverføring, remote admin, og tunneling. Sistnevnte kan ses på som et alternativ til VPN, der en TCP/IP forbindelse for en applikasjon routes gjennom (port forwarding) en SSH applikasjon (klient eller server) som sender denne videre til en mottaker med SSH satt opp. SSH sørger dermed for at forbindelsen mellom sender og mottaker er sikret. Dette kan være et tenkt scenario dersom man for eksempel skal koble opp mot en databaseserver eller e-postserver. Til tross for at tanken av å kjøre eksempelvis PPP over SSH kan være fris- 4

tende, kan det være trivielt å få det til å fungere optimalt i praksis. TCP deler som kjent datastrømmen inn i segmenter. Disse inneholder et sekvenstall som forteller noe om rekkefølgen i datastrømmen og et acknowledgenummer som indikerer hvilken sekvenspakke som ble sist mottatt. Dersom et aknowledgenummer for en sendt pakke ikke blir returnert i tide kan dette være en indikator på at pakken har forsvunnet og den blir sendt på nytt. For å ta båndbredde i betraktning og unngå opphopning, benytter TCP adaptive timeouts slik at dersom et segment får timeout, vil lengden til neste timeout bli økt eksponentielt. Et problem oppstår derimot når vi legger en TCP forbindelse oppå en annen (figur 1). Det man skal merke seg her er at det øverste og nederste laget har forskjellige timere. Når forbindelsen i det øverste laget starter raskt, vil også timerne være raske. Om vi tenker oss at det oppstår pakketap på nettforbindelsen så vil TCP på det nederste laget forsøke å sende disse på nytt og øke timeout verdien. Da forbindelsen er blokkert i dette tidsrommet vil ikke det øverste TCP laget motta en ACK tids nok, slik at denne også vil foreta remtransmisjon. Fordi timeout verdien til det øverste laget er mindre enn det nederste laget, vil det øverste laget foreta remtransmisjoner raskere enn det nederste laget har evne til å behandle. Dette resulterer i en intern meltdown effekt, der det øverste laget stopper opp ganske raskt og hvor nye remtransmisjoner bare gjør problemet verre. I denne situasjonen er remtransmisjon på det øverste laget helt unødvendig, men TCP vet ikke dette og går ut i fra at den har en upålitelig bærer. TCP ble ikke designet for å fungere på toppen av seg selv. En annen ulempe er dersom SSH TCP forbindelsen blir brutt f.eks. pga ustabil oppkobling, vil VPNen også gå ned sammen med alle TCP forbindelsene som går igjennom denne. Dette kan føre til at man blir nødt til å restarte VP- Nen unødig mange ganger. Det kan også oppstå problemer dersom nettverkslasten er høy og keepalive-pakker blir forsinket. Keepalive-pakker sørger for at en forbindelse holdes oppe, og dersom disse ikke kommer frem i tide kan forbindelser tas ned uten at den andre er klar over det. Uten keepalivepakker er det heller ingen måte å sjekke om en forbindelse er brutt, slik at dersom en part prøver å etablere en forbindelse og den andre allerede tror at en forbindelse er etablert, kan det oppstå forvirring. 5 Konklusjon IPsec, SSL/TLS og SSH er alle protokoller som utmerket godt kan egne seg som VPN løsninger, men det er viktig at man ser på svakhetene som er poengtert her og tar disse i betraktning ved et eventuelt valg. IPsec kan 5

være et godt valg dersom man ønsker sikkerhet på nettverkslaget og har tatt NAT-problematikken i betraktning. IPsec har imidlertid litt å gå på når det gjelder distribusjon og håndtering av nøkkelmateriell, spesielt med tanke på tidssensitive applikasjoner som VoIP, noe som kan være noe å ta for seg som et eventuelt framtidig arbeid. SSL/TLS blir populært brukt sammen med HTTP protokollen og det ikke uten grunn. SSL er i midlertidig ressurskrevende og faller litt bak når det gjelder skalerbarhet. Til slutt snakket vi om SSH, og hvordan denne i dag benyttes ikke bare for innlogging og fjernadministrasjon, men også til andre formål som FTP, filoverføring og tunneling. SSH VPN tilbyr sikker ende-til-ende kommunikasjon men også denne metoden byr på utfordringer, spesielt med tanke på TCP-på-TCP problematikken. References [1] S. Friedl. An Illustrated Guide to IPsec. August 2005 http://www.unixwiz.net/techtips/iguide-ipsec.html [2] VPN PPP-SSH Mini-HOWTO http://www.tldp.org/howto/pppssh/introduction.html [3] R. Oppliger. Security at the Internet Layer. Sept 1998 [4] P. Knight, C. Lewis. Layer 2 and 3 Virtual Private Networks: Taxonomy, Technology, and Standardization Efforts. June 2004 [5] A. Alshamsi, T. Saito. A Technical Comparison of IPSec and SSL. 2005 [6] L. Zhao, R. Iyer, S. Makineni, L. Bhuyan. Anatomy and Performance of SSL Processing. 2005 [7] W. Chou. Inside SSL: The Secure Sockets Layer Protocol. IT Pro July/August 2002 [8] O. Titz. Why TCP Over TCP Is A Bad Idea. April 2001 [9] C. Hosner. SSL VPNs and OpenVPS: A lot of lies and a shred of truth. NewsForge, September 2005 6