Treg applikasjon ?


For de fleste virksomheter er det viktig å levere gode applikasjonsopplevelser til brukere. Når dette feiler eller virker tregt, kan det ofte være vanskelig å fastslå hvor det feiler eller kvantifisere brukerens dårlige opplevelse.

Treg applikasjon ?


For de fleste virksomheter er det viktig å levere gode applikasjonsopplevelser til brukere. Når dette feiler eller virker tregt, kan det ofte være vanskelig å fastslå hvor det feiler eller kvantifisere brukerens dårlige opplevelse.

For å få kontroll på dette bruker man verktøy for å overvåke applikasjonstrafikken, slik at man får objektiv informasjon til å håndtere problematikken. Disse systemene er avhengig av å lese trafikken i klartekst, og ettersom mer og mer av trafikk blir kryptert kan en del av disse systemene bli blindet. Denne artikkelen handler om hvordan Appflow og Netscaler kan bidra til å gi fortsatt god informasjon.

 

Den tradisjonelle tilnærmingen

Mange systemer for overvåking av applikasjoner og nettverkstrafikk er basert på speiling av trafikkstrømmen via en monitorport på en switch.

Når et overvåkingssystem mottar datastrømmen via en monitorport er det avhengig av å sitte på nøkkelparene som benyttes for TLS for å kunne dekryptere trafikken. Dette gjøres normalt ved at server-sertifikatets privatnøkkel er lagt inn i overvåkingssystemet. Slik er det mulig å lagre klartekstinnholdet i trafikken for analyse. I praksis fungerer dette slik at systemet ser den innledende nøkkelutvekslingsfasen der det avtales en ny, symmetrisk nøkkel (samme nøkkel for kryptering og dekryptering) og dekrypterer utvekslingen ved hjelp av serversertifkatet og tilhørende privatnøkkel. Overvåkingssystemet kan deretter dekryptere data ved hjelp av den observerte symmetriske nøkkelen og gjøre sin analysejobb på klartekst data.

 

TLS forward secrecy

Det faktum at server-sertifikatets privatnøkkel benyttes for å forhandle de symmetriske nøklene representerer en risiko fordi privatnøkkelen er statisk over sertifikatets levetid. Dersom en angriper har tilgang til nøkkelen kan data dekrypteres (slik overvåkingssystemet over gjør det). Dette vil også kunne gjøres i ettertid dersom datastrømmen lagres.

For å unngå denne risikoen anbefales “Forward Secrecy” teknikker. F.eks ved å benytte ECDHE (Elliptic Curve Diffie-Hellman Ephermeral) nøkkelutveksling. Med denne metoden genereres nøklene som benyttes i nøkkelutvekslingsfasen dynamisk. Sertifikatets betydning er da kun å signere serverens identitet, ikke å stå for etablering av symmetriske nøkler. Det er verdt å merke seg at for eksempel Chrome nettleseren klassifiserer TLS uten “Forward Secrecy” som “obsolete cryptography” (kan sees om du åpner informasjonssiden bak “hengelås-ikonet”). For en tjeneste-eier er dette neppe en særlig flatterende karakteristikk å motta.

Problemet for et tradisjonelt overvåkingssystem som nevnt over er at det er ute av stand til å dekryptere trafikk fordi det ikke er et av endepunktene der trafikken krypteres og dekrypteres. Dette er ikke produktspesifikke svakheter, men en følge av at krypteringen ikke lenger etableres med et statisk nøkkelpar.

 

Trafikk-data fra endepunkter

For å kunne drive trafikkanalyse er det derfor nødvendig å innhente trafikkdata fra et av endepunktene i kommunikasjonen. Når en Citrix Netscaler benyttes som load balancer og TLS-trafikken termineres i Netscaleren, kan Appflow-modulen eksportere flow-data til et analysesystem. Flow-dataene kan inneholde informasjon som kun er synlig i dekryptere datastrømmer. Et eksempel er URL’er eller enkelte HTTP headere som “host” og “user-agent”. Dette er sammen med timing-informasjon verdifulle data for å analysere en applikasjons ytelse og for å kunne drive feilsøking på den.

Appflow benytter IPFIX, en IETF standard protokoll ofte kalt Netflow versjon 10. Flow-data sendes fra Netscaler til en IPFIX mottager som kjøres på en egen server slik at belastningen på Netscaler blir lavest mulig.

Det finnes mange produkter som kan analysere data fra IPFIX. Dog er det slik at siden IPFIX er en videreutviklet Netflow vil mange av dem fokusere på det nettverksmessige rundt TCP-laget.

Det som imidlertid er mer interessant er analyse applikasjonsytelse og brukeraktivitet i ulike deler av applikasjonen. Her har Citrix et utmerket verktøy i Citrix Insight Center. Dette kan gi en relativt detaljert oversikt over ulike deler av en web-applikasjon på URL nivå med bl.a. parameter som render tid på klient for enkelt URLer og prosesseringstid på applikasjonsserver. I tillegg leverer den informasjon om latency på nettverk, geografisk distribusjon av klienter, nettlesertyper osv.

Insight Center har også egen modul for analyse av HDX/ICA trafikk som gir oversikt over hvilke applikasjoner som benyttes hvor og av hvem, hvilke servere applikasjoner kjører på, ytelse/responstid på server samt latency i nettverk mellom bruker og Netscaler og videre til server.


Citrix Insight Center leveres med Netscaler med litt ulik funksjonalitet avhengig av Netscaler lisensversjon. HDX Insight krever minimum Enterprise edition, mens Web Insights er tilgjengelig også i Standard Edition. For å kunne lagre data utover «live-data» kreves Platinum edition.

(Bilder i denne posten er linket fra citrix.com)