Kryptering med Citrix ADC (NetScaler)
I anledning sikkerhetsmåneden har vi skrevet en artikkel om kryptering ved bruk av Application Delivery Controller: TLS, sikkerhet og hastighet.
Da Covid-19 traff oss med full tyngde, ble ADC-hjemmekontorløsninger skalert opp fra noen få samtidige brukere til at nær sagt alle ansatte brukte dem hver arbeidsdag. Endepunktsikkerhet ble førstesidestoff og mange IT-ansvarlige fikk brått et møte med IP Reputation og karakterskalaen til Qualys. Nedenfor ser jeg nærmere på noen viktige valg for krypteringen og hva det betyr for sikkerhet og hastighet i kommunikasjonen mellom endepunkt og ADC.
Når et endepunkt ber om noe fra en ADC der vi krever en kryptert forbindelse (eks. HTTPS) starter de med å forhandle fram hva som skal benyttes av protokoller, chiffer og opsjoner. Administrator kan bestemme hva som er lov og ikke lov.
Eksempel på valg som ikke påvirker hastighet
Vanlig er nå å skru på HSTS (HTTP Strict Transport Security) og sette en teller. Telleren bør være et halvt år = 15768000 sekunder. Årsaken er at terskelverdien hos Qualsys SSL Labs, for å godkjenne HSTS i sin test, er 180 dager. HSTS er i dag en avhuking i konfigurasjonen på et vServer-objekt, så har man en oppgradert ADC fins det kanskje en INSERT_HTTP_HEADER Rewrite Action for å oppnå det samme. HSTS forteller endepunktet at den aldri skal (i et halvt år…) benytte HTTP-utgaven av nettsiden eller vise sluttbrukeren HTTPS-utgaver der sertifikatet er feil. Dette forhindrer angrep mot vServer via kompromittert DNS.
Valg som påvirker hastighet noe
Bruk NONSECURE på Deny SSL Renegotiation. Velger du NO er endepunktet utsatt for angrep fra mellommann som kan benytte deler av endepunktets TLS-info for å etablere sin egen TLS-sesjon med vServer. RFC 5746 beskriver situasjonen.
Moderne sertifikat blir gjerne signert av Intermediate CA som igjen får sitt sertifikat signert av Root CA. ADC skal lenke de to førstnevnte. Root CA er ikke nødvendig å lenke inn. Endepunktet skal ha Root CA i sin Trusted Store og vil da i alle tilfeller forkaste informasjonen. Et sertifikat er bare rundt 2000 bytes, men likevel 2000 unyttige bytes over linja.
Valg som har innvirkning på hastighet
Chiffer bestemmer hvilken kryptoalgoritme man skal kommunisere med og disse samles gjerne i en chiffer-suite. Beste praksis er å lage en skreddersøm, for eksempel en samling med TLS v1.2 og TLS v1.3 (versjonene 1.1 og 1.0 regnes nå som mindre sikre og må derfor unngås). En fordel med TLS 1.3 framfor versjon 1.2 er at det er omtrent halvparten så mange steg når kryptoforhandlingen gjøres.
Endepunktet sender en pakke (Client Hello) som forteller hvilke TLS og chiffer den støtter. Citrix ADC ser på konfigurasjonen for vServer og betrakter chiffer-suiten som en meny: Den starter fra toppen og velger det første chiffer endepunktet vet å bruke. Derfor er bindingsrekkefølgen viktig, så om en tar med TLS 1.3 legg disse chiffer på toppen.
Ta gjerne med i betrakningen at versjon 1.3 var gjennom 27 utkast før den ble publisert som standard av IETF august 2018. Dette innebærer at endepunkt kan få problem om en har nettlesere og ADC firmware hvor ulike utkast er i bruk.
To av de 10 TLS 1.2-chiffer som fins på ADC er DHE. DHE krever en nøkkel i hver ende for å oppnå såkalt Perfect Forward Secrecy. Nøklene blir ikke sendt over linja (Diffie-Hellman algoritmen) og blir kastet når TLS-sesjonen er over (Ephemeral). Med PFS kan mellommann ikke lese tidligere kryptert innhold selv om han lagrer en kryptosamtale og senere kompromitterer ADC-en og får tak i privatnøkkelen til denne. Den største ulempen for oss er at endepunktet må generere en krypteringsnøkkel for hver TLS-sesjon, og dette er en CPU-intensiv handling som er med på å tømme batteriet på mobile enheter.
De andre åtte TLS 1.2 chiffer er ECDHE som bruker prinsippet ‘Eliptic Curve’. Dette behøver kortere nøkler og tilbyr likevel PFS. DHE er ennå med fordi den støttes av eldre endepunkt, men for moderne klienter er ECDHE et godt valg. Merk også at kortere nøkkel gjør både kryptering og dekryptering enklere, så nettsidene lastes raskere. Ofte finner vi chiffer-suiter hvor kortere nøkkel er foretrukket framfor lenger, f. eks.
TLS1.2-ECDHE-ECDSA-AES128-GCM-SHA256
foran
TLS1.2-ECDHE-ECDSA-AES256-GCM-SHA384
Noen stusser ved dette. Årsaken er at typen kryptoalgoritme er viktigst og 128-bit krever mindre CPU av endepunktet (og dermed mindre strøm). Forskjell i sikkerhet mellom 128- og 256-bit nøkkel er ikke så stor som når man bytter type chiffer.
Til slutt, går man for ECDHE og har hypervisoren Citrix SDX (eller maskinvare ADC-en MPX), merk da at det fins en innstilling for å ta i bruk ubrukt CPU for å understøtte de innebygde krypteringsbrikkene. Dette konfigureres med Software Crypto Threshold.
Om du har spørsmål om dette eller beslektede tema, er du velkommen til å ta kontakt med oss. Vi har mye praktisk erfaring på området.