Hvordan fungerer TLS

Hvordan fungerer TLS

Hvordan sette opp transport layer security på en sikker måte? Rolf Rander Næss holdt foredrag på JavaZone og presenterte anbefalninger om hvordan velge cipher suites i TLS. 

Du kan se hele foredraget her, men en oppsummering følger under.

Hva er TLS?

TLS, Transport Layer Security, er en nettverksprotokoll som gir integritet og konfidensialitet til kommunikasjon over TCP/IP, på en måte som gjør at andre protokoller kan legges inn i TLS uten at disse andre protokollene trenger å endres eller å være klar over at de sendes gjennom TLS.
Ved oppsett av en TLS-forbindelse blir klient og tjener enige om noen parametre for hvordan protokollen settes opp. Den viktigste av disse er en "cipher suite" som definerer hvilke algoritmer som skal brukes for:
  • Nøkkelutveksling, hvordan blir partene enige om en sesjonsnøkkel som skal brukes til kryptering
  • Autentisering, hvordan kan klienten vite at den snakker med rett server (eller motsatt, dersom serveren krever klientsertifikat)
  • Kryptering, for å sikre konfidensialitet i overførte data
  • Meldingsintegritet, for å sikre integritet i overførte data

Nøkkelutveksling

Nøkkelutveksling kan i hovedsak gjøres på to måter:
  • RSA: klienten velger en tilfeldig sesjonsnøkkel, krypterer denne med serverens offentlige RSA-nøkkel og sender over denne
  • Diffie-Hellman (DH): Ved hjelp av noen offentlige parametre og litt diskret matematikk blir partene enige om en nøkkel uten at denne nøkkelen sendes over nettverket
RSA er ikke anbefalt, fordi hvis en angriper lagrer den krypterte kommunikasjonen og senere får tak i den private RSA-nøkkelen, kan han gå tilbake og dekryptere tidligere kommunikasjon.

DH krever at de offentlige parametrene i protokollen ligger i serversertifikatet. Det er få leverandører av både programvare og sertifikat som støtter dette. I tillegg kan det være en sikkerhetsrisiko at disse er statiske. Derfor har vi varianten DH Ephemeral, hvor disse parametrene er flyktige, altså at de velges på nytt for hver forbindelse.

DHE gir såkalt "perfect forward secrecy".

I tillegg finnes en variant av DH basert på elliptiske kurver, ECDH og ECDHE. Elliptiske Kurver gir samme sikkerhet med kortere nøkler og eksekvering er ofte raskere.

Bruk ECDHE eller DHE hvis du har mulighet til det, RSA bare som reserveløsning. 

Autentisering

Det finnes en del mekanismer som kun er relevante i noen sammenhenger, men de man typisk har å velge mellom er:
  • DSA: basert på diskret logaritme
  • RSA: basert på produkt av store primtall
  • ECDSA: som DSA, men med elliptiske kurver
DSA er i praksis, av diverse historiske årsaker, begrenset til 1024 bits, ikke bruk dette.

RSA er trygt, men bruk minst 2048 bits nøkler. På den annen side er det ikke anbefalt å ha så veldig mye lengre nøkler, for det krever mye CPU. Noen er redd for at problemet med faktorisering av store tall kan få store fremskritt i årene som kommer og anbefaler derfor å gå vekk fra RSA.

ECDSA er som DSA, men med elliptiske kurver. Som for DH vil du få samme sikkerhet med kortere nøkler (256 bits ECDSA er typisk ansett som minst like sikkert som 2048 bits RSA). Både med tanke på mulighet til å skalere til større nøkler, og med tanke på mulige matematiske fremskritt når det gjelder faktorisering er derfor ECDSA å foretrekke.

Kryptering

I praksis er det liten grunn til å velge noe annet enn AES. Du kan bruke 128 eller 256 bits nøkler, det har liten konsekvens for verken sikkerhet eller ytelse.

Merk at for TLS 1.0 er det en svakhet i hvordan block ciphers (som AES) er implementert, noe som er utnyttet i BEAST. En kort periode anbefalte man derfor å bruke en stream cipher i stedet for å omgå dette. Dessverre finnes kun en stream cipher tilgjengelig, RC4, og senere har man funnet nye måter å angripe denne på som gjør at den er ikke anset som så veldig sikker lenger. Løsningen er derfor å ikke bruke TLS 1.0.

Integritet

Data som sendes gjennom TLS deles opp i pakker på opp til 16KB, og hver av disse inneholder en hash for integritet. Av alternative algoritmer:
  • MD5: ikke bruk denne
  • SHA-1: bruk helst ikke denne heller, men om du er på TLS 1.0 er dette eneste alternativ
  • SHA-256/384: disse er sikre, men finnes bare i TLS 1.2
I TLS 1.2 har man dessuten fått støtte for AEAD (Authenticated Encryption with Associated Data), hvor integritetssjekk er integrert i krypteringen.

Oppsummert

Det er ingen grunn til å bruke noen annen krypteringsalgoritme enn AES.

Du bør prioritere:
  1. Perfect forward secrecy, altså ECDHE eller DHE
  2. Autentisering med ECDSA foran RSA
  3. Integritet basert på SHA-256/384, evt SHA-1 hvis du må bruke TLS 1.0
  4. Krypteringsnøkler på 256 bits, evt 128. Ikke bruk kortere nøkler enn 128 bits.
Gitt disse prioriteringene sitter vi igjen med følgende liste av anbefalte cipher suites, i prioritert rekkefølge (denne inneholder bare 256-bits varianter, 128-bits-varianter vil naturlig være innimellom disse)
  • TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
  • TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
  • TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
  • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
  • TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
  • TLS_DHE_RSA_WITH_AES_256_CBC_SHA384
  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
  • TLS_DHE_RSA_WITH_AES_256_CBC_SHA
  • TLS_RSA_WITH_AES_256_GCM_SHA384
  • TLS_RSA_WITH_AES_256_CBC_SHA256
  • TLS_RSA_WITH_AES_256_CBC_SHA 

Dessuten

Hvis du ikke trenger det, bør du:
  • Slå av renegotiation
  • Slå av komprimering (ref BREACH og CRIME)
  • Slå av heartbeat
Med mindre du vet at du må støtte produkter som ikke støtter TLS 1.2, bør du ikke støtte noen eldre protokoller enn dette. Det finnes ingen grunn til å støtte SSL 3.0. Du må ikke finne på å bruke SSL 2.0, denne har kjente sikkerhetshull.

comments powered by Disqus