• Karriere
  • Om oss
  • Folk
Norsk
Kontakt oss
  1. Kunnskap
  2. Innsikter
  3. Blogg
Blogg
05.10.2020
min tid å lese

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.
<span id="hs_cos_wrapper_name" class="hs_cos_wrapper hs_cos_wrapper_meta_field hs_cos_wrapper_type_text" style="" data-hs-cos-general-type="meta_field" data-hs-cos-type="text" >Kryptering med Citrix ADC (NetScaler)</span>
Sicra_Portrait_Crop_1200x1500px_0300
Roar BrevikSystemarkitekt
Tidligere Windowskæll som har emigrert til grønnere sikkerhetsmarker

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 (Les mer i "Sikre dine webapplikasjoner med Netscaler IP Reputation" av Zoran Milenkovic), 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.

Les "Er en hengelås til å stole på?" av Lars Petter Hosøy. 

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.

 

Les mer

SOC-as-a-Service: Dilemma
Blogg

SOC-as-a-Service: Dilemma

Lær mer om SOC-tjenesters skjulte kostnader.
85% av CEO-er: Cybersikkerhet nøkkelen til vekst i 2025, men hvor skal man starte?
Blogg

85% av CEO-er: Cybersikkerhet nøkkelen til vekst i 2025, men hvor skal man starte?

Fagblogg
Cybersikkerhet
85 % av CEO-er sier cybersikkerhet er kritisk for vekst. Les hvor du bør starte – og hvordan Sicra kan hjelpe.
Hvorfor moderne SOC er viktig for NSM, GDPR og ny digital sikkerhetslov
Blogg

Hvorfor moderne SOC er viktig for NSM, GDPR og ny digital sikkerhetslov

Fagblogg
Cybersikkerhet
Finn ut hvorfor et moderne SOC er avgjørende for NSM, GDPR og ny sikkerhetslov.
NTLM svakheter og responsmuligheter
Blogg

NTLM svakheter og responsmuligheter

Fagblogg
Cybersecurity
NTLM svakheter kan utnyttes eksternt og krever lite brukerinteraksjon.

Skreddersydd cybersikkerhet for virksomheter og institusjoner – så dere kan vokse, innovere og jobbe uten bekymringer.

Ta kontaktRing oss +47 648 08 488
Hold deg oppdatert
Motta siste nytt fra Sicra

Linker
BærekraftFAQPartnereSertifiseringerKarrierePresse
Kontakt

Tel: +47 648 08 488
E-post: firmapost@sicra.no

Rosenholmveien 25, 1414
Trollåsen. Norge

Følg oss på LinkedIn
Sertifiseringer
iso27001-white
ISO 27001
miljofyrtarnlogo-hvit-rgb
Miljøfyrtårn
Sicra © 2025
Personvern