Sikkerhet på transportlaget – TLS

Dagens tekst er hentet fra kapittel 17 i Cryptography and Network Security. Dette kapitlet skal se nærmere på hvordan man beskytter informasjon på transportlaget – først og fremst med TLS, men også SSH. Verdensveven (WWW) er i bunn i og grunn en klient/tjener-applikasjon som kjører over internett og TCP/IP intranet. Følgende karakteristika ved vev-bruk antyder behov for skreddersydde sikkerhetsverktøy: vevtjenere er relativt enkle å konfigurere og administrere, og vevinnhold er stadig enklere å utvikle. Den underliggende programvaren er uvanlig kompleks og kan skjule mange potensielle sikkerhetssvakheter, og en vevtjener kan utnyttes som et brohode for et angrep mot hele virksomhetens IT-infrastruktur. Tilfeldige og uskolerte (når det gjelder sikkerhet) brukere er vanlige i målgruppen for vevbaserte tjenester; slike brukere er sjelden bevisste på sikkerhetsrisikoene som finnes, og har ikke verktøyene eller kunnskapen som trengs for å iverksette effektive mottiltak.

TLS

TLS (definert i RFC 5246) er en av de hyppigst brukte sikkerhetstjenestene. Den er en internettstandard som oppsto som en utvikling av den kommersielle protokollen kjent som Secure Secure Sockets Layer (SSL), og er en generell tjeneste implementert som et sett av protokoller som baserer seg på TCP. Den kan tilbys som en del av den underliggende protokoll-suiten, og følgelig transparent for applikasjoner, og den kan bygges inn i spesifikke pakker. De fleste nettlesere kommer utstyr med TLS, og de fleste vevtjenere har også implementert protokollen.

TLS arkitektur

Det er to viktige TLS-konsepter: TLS-forbindelse og TLS-sesjon.

En TLS-forbindelse er en transportmekanisme som tilbyr en passende type tjeneste. I TLS er slike forbindelser likemann-til-likemann (peer-to-peer) forhold, og forbindelsene er av forbigående natur. Hver forbindelse er assosiert med en sesjon.

En TLS-sesjon er en assosiasjon mellom en klient og en tjener som opprettes av håndtrykks-protokollen (handshake protocol). Den definerer et sett av kryptografiske sikkerhetsparametere som kan deles mellom flere forbindelser, dette gjøres for å unngå kostbare reforhandlinger av sikkerhetsparametere for hver nye forbindelse.

En sesjonstilstand er definert av følgende parametere:

  • Sesjonsidentifikator- en tilfeldig byte-sekvens valg av tjeneren for å identifisere en aktiv eller gjenopptakbar sesjonstilstand.
  • Likemann-sertifikat – et X509.v3 sertifikat til andre enden av sesjonen; dette elementet av tilstanden kan være null
  • Kompresjonsmetode – algoritmen som brukes for å komprimere data før de krypteres
  • Chifferspesifikasjon (Cipher spec) – spesifiserer krypteringsalgoritmen som skal brukes og en hash-algoritme som skal brukes for beregning av MAC; definerer også kryptografiske attributter som f.eks. hash-størrelsen
  • Mester-hemmelighet (Master secret) – 48-byte hemmelighet som er delt mellom klienten og tjeneren
  • Er gjenopptakbar (Is resumable) – et flagg som indikerer hvorvidt sesjonen kan brukes til å initiere nye forbindelser

En forbindelsestilstand er definert av følgende parametere:

  • Tjener og klient tilfeldig (Server and client random) – Byte-sekvenser som velges av tjener og klient for hver forbindelse (noncer)
  • Tjener skrive MAC-hemmelighet – den hemmelige nøkkelen brukt i MAC-operasjoner på data sendt av tjeneren
  • Klient skrive MAC-hemmelighet – den hemmelige nøkkelen brukt i MAC-operasjoner på data sendt av klienten
  • Tjener skrive-nøkkel – den symmetriske (hemmelige) krypteringsnøkkelen for data som sendes av tjeneren og dekrypteres av klienten
  • Klient skrive-nøkkel – den symmetriske (hemmelige) krypteringsnøkkelen for data som sendes av klienten og dekrypteres av tjeneren
    • Initialiseringsvektorer – når et blokkchiffer i CBC-modus brukes vedlikeholdes en initialiseringsvektor for hver nøkkel; dette feltet initialiseres først av håndtrykksprotokollen (TLS Handshake Protocol). Den siste chiffertekst-blokka i hver opptegnelse (Record) spares for å brukes som IV til neste opptegnelse
    • Sekvensnummer – hver part vedlikeholder separate sekvensnummer for sendte og mottatte meldinger for hver forbindelse. Når en av partene sender eller mottar en Endre_Chifferspesifikasjon-melding, blir det tilsvarende sekvensnummeret satt til null. Sekvensnummer kan ikke overstige 264 – 1.

TLS opptegnelseprotokollen (Record Protocol) tilbyr to tjenester for TLS-forbindelser, konfidensialitet og meldingsintegritet. Håndtrykksprotokollen definerer en delt hemmelig nøkkel som brukes for konvensjonell kryptering av TLS nyttelast, og dessuten en annen delt hemmelig nøkkel som brukes for å danne en meldingsautentiseringskode (MAC).

Kryptografiske beregninger

Den delte mester-hemmeligheten er en 48-byte verdi som genereres for denne sesjonen vha. en sikker nøkkelutveksling. Dette skjer i to stadier; først utveksles en forhåndshemmelighet (pre_master_secret) enten vha. RSA (i dette tilfellet velger klienten nøkkelen) eller Diffie-Hellman, og deretter beregnes selve mester-hemmeligheten (master_secret)  av begge parter hver for seg.

PRF(secret, label, seed) =  P_<hash> (secret, label ||  seed)

Merkelappen er her tekststrengen “key expansion”, hemmeligheten er pre_master_secret og frøet de to tilfeldige verdiene (noncene) fra håndtrykksprotokollen.

Vi definerer A(0) som [“key expansion” ||frøet], og A(i) som HMAC(pre_master_secret,A(i-1)). Funksjonen P_<hash> vil da produsere følgende:

P_<hash>(pre_master_secret,A(0))=     HMAC(pre_master_secret,A(1)||A(0)) ||
HMAC(pre_master_secret,A(2)||A(0)) ||
HMAC(pre_master_secret,A(3)||A(0)) ||
…

Den aktuelle hash-funksjonen er valgbar, men det er rimelig å anbefale SHA – og nå gjerne SHA3.

 

Generering av kryptografiske parametere

Mester-hemmeligheten brukes til å generere de nødvendige kryptografiske parameterne som trengs i de forskjellige chiffer-spesifikasjonene:

  • En klient skrive MAC-nøkkel
  • En tjener skrive MAC-nøkkel
  • En klient skrive-nøkkel
  • En tjener skrive-nøkkel
  • En klient skrive-IV
  • En tjener skrive-IV

Disse genereres fra mester-hemmeligheten i den rekkefølgen, ved å hashe mester-hemmeligheten gjentatte ganger med både MD5 og SHA, kombinert med en serie konstante strenger (“A”, “BB”, “CCC”, osv.) til man har fått en resulterende streng som er lang nok for alle de nødvendige parametrene.

Hjerteslagsprotokollen

Dette er et periodisk signal generert av maskinvare eller programvare for å indikere normal operasjon, eller for å synkronisere andre deler av systemet. Det brukes typisk for å overvåke tilgjengeligheten av en protokoll-entitet, og ble i tilfellet TLS først definert i 2012 (RFC 6250) for å støtte Datagram Transport Layer Security (DTLS). Denne kjører på samme måten som de andre TLS-protokollene oppå opptegnelsesprotokollen (TLS Record Protocol).

Hjerteslagsprotokollen består av to meldingstyper, heartbeat_request og heartbeat_response, som begge kan inneholde en nyttelast. Bruken av protokollen avklares i løpet av den første fasen av håndtrykksprotokollen. Hjerteslaget har to formål; det lar avsenderen forsikre mottakeren at den fortsatt er i live, samt det genererer aktivitet på forbindelsen i ledige stunder, som unngår at en brannmur som ikke tillater lediggang lukker forbindelsen. Kravet om utveksling av nyttelast kom som følge av bruk av hjerteslagsprotokollen i DTLS.

SSL/TLS-angrep

Angrepene kan grupperes i fire generelle kategorier: Angrep på håndtrykksprotokollen, angrep på opptegnelse- og applikasjonsdataprotokollene, angrep på PKI, og andre angrep. Den konstante bølgingen fram og tilbake mellom trusler og mottiltak bestemmer utviklingen av internett-baserte protokoller.

TLSv1.3

Hovedformålet med TLSv1.3 var å forbedre sikkerheten til TLS. Signifikante endringer fra versjon 1.2 omfatter fjerning av en rekke opsjoner og funksjoner, fjerning av støtte for RSA, og raskere gjennomføring av håndtrykksprotokollen.

De fjernede tingene omfatter:

  • Kompresjon
  • Chiffer som ikke tillater autentisert kryptering
  • Statisk RSA og DH nøkkelutveksling
  • 32-bit tidsstempel som del av den tilfeldige parameteren i client_hello
  • Reforhandling
  • Change Cipher Spec protokollen
  • RC4
  • Bruk av MD5 og SHA-224 hasher med signaturer

TLSv1.3 bruker Diffie-Hellman eller Elliptic Curve Diffie-Hellman for nøkkelutveksling, og tillater ikek RSA. TLSv1.3 gjør det mulig med et “1 rundtur” håndtrykk ved å endre rekkefølgen på meldinger sendt når man etablerer en sikker forbindelse.

HTTPS

Når man kombinerer HTTP og SSL (eller TLS i våre dager) for å implementere sikker kommunikasjon mellom en nettleser og en vevtjener kaller man det like gjerne HTTPS, og støttefor detet er bygd inn i alle moderne nettlesere. Brukeren av nettleseren vil se URL adresser som begynner med https:// i stedet for http://. Hvis HTTPS er spesifisert vil port 443 bli brukt, som vil pårope SSL/TLS. Det er ingen fundamental endring i å bruke HTTP over enten SSL eller TLS, og begge implementasjonene refereres til som HTTPS, som er dokumentert i RFC 2818, HTTP Over TLS.

Når HTTPS brukes vil følgende elementer av kommunikasjonen være kryptert:

  • URLen til dokumentet (siden) som er bedt om
  • Innholdet til dokumentet
  • Innholdet til nettleser-skjema (browser forms)
  • Småkaker (Cookies) sent fra nettleser til tjener og omvendt
  • Innhold i HTTP-hode (header)

Opprettelse av forbindelse

For HTTPS, vil agenten som agerer som HTTP-klient også agere som TLS-klient. Klienten vil intiere en forbindelse til tjeneren på den passende porten, og sender deretter meldingen TLS ClientHello for å begynne TLS-håndtrykket. Når TLS-håndtrykket er ferdig, kan klienten så initiere den første http-anmodningen, med alle HTTP-data sendt som TLS applikasjonsdata.

Det er tre bevissthetsnivåer rundt en forbindelse i HTTPS: På HTTP-nivået vil en HTTP-klient be om en forbindelse til en HTTP-tjener ved å sende en forbindelsesanmodning til det neste laget under; dette vil typisk være TCP, men kan også være TLS/SSL. På TLS-laget er en sesjon opprettet mellom en TLS-klient og en TLS-tjener; denne sesjonen kan støtte en eller flere forbindelser til enhver tid. En TLS-anmodning for å etablere en forbindelse begynner med en opprettelse av en TCP-forbindelse mellom TCP-entiteten på klientsiden og TCP-entiteten på tjenersiden.

Lukking av forbindelsen

En HTTP klient eller tjener kan indikere lukking av en forbindelse ved å inkludere linjen Connection: close i en HTTP-opptegnelse. Lukking av en HTTPS-forbindelse krever at TLS lukker forbindelsen med TLS   likemann-entiteten på den andre siden, som vil omfatte lukking av den underliggende TCP-forbindelsen. TLS-implementasjoner må initiere en utveksling av lukke-varsler før forbindelsen kan lukkes. En TLS-implementasjon kan etter å ha sendt et lukkevarsel lukke forbindelsen uten å vente på at likemannen sender sitt lukkevarsel, noe som genererer en “ufullstendig lukking”. En uvarslet TCP-lukking kan være bevis på en eller annen form for angrep, så HTTPS-klienten burde utstede en elelr annen form for sikkerhetsvarsel når dette skjer.

Secure Shell (SSH)

Denne protokollen for sikkre netterkskommunikasjon, opprinnelig laget for å tilby et sikkert skall (deerav navnet), var designet for å være relativt enkel og billig å implementere.  Den første versjonen, SSH1, var fokusert på å være et alternativ til TELNET og andre fjerninnloggingssystemer om ikke tilbydde sikkerhet. SSH tilbyr også en mer generell klient/tjener-kapabilitet, og kan brukes for nettverksfunksjoner som filoverføring og epost.

SSH2 fikser et antall sikkerhetsfeil i den opprinnelige løsningen, og er dokumenetert som en foreslåttstandard i IETF RFC 4250 til 4256. SSH klient- og tjenerapplikasjoner er bredt tilgjengelig for de fleste operativsystemer, og har blitt et førstevalg for fjerninnlogging og X-tunellering. SSH er følgelig i ferd med å bli en av de mest utstrakte applikasjonene for krypteringsteknologi foruten innebygde systemer.

Transportlagsprotokoll

Tjenerautentisering skjer på transportlaget, basert på at tjeneren innehar et offentlig/privat nøkkelpar. En tjener kan ha flere forskjellige vert-nøkler for bruk med flere forskjellige asymmetriske krypteringsalgoritmer , og flere verter kan dele samme vertsnøkkel. Tjenerens vertsnøkkel brukes i nøkkelutvekslingen for å autentisere verten.

RFC 4251 angir to alternative tillitsmodeller:

  • Klienten har en lokal database som assosierer hvert vertsnavn med en korresponderende offentlig vertsnøkkel.
  • Vertsnavn-til-nøkkel assosiasjonen er sertifisert av en tiltrodd sertifiserings-autoritet (CA); klienten kjenner kun rotnøkkelen til CAen, og kan verifisere gyldigheten til alle vertsnøkler sertifisert av aksepterte CAer.

Autentiseringsmetoder

SSH lar deg autentisere deg med offentlig nøkkel, passord, eller vertsbasert:

  • Offentlig nøkkel: Klienten sender en melding til tjeneren som inneholder klientens offentlige nøkkel, hvor meldingen er signert av klientens private nøkkel. Når tjeneren mottar denne meldingen, vil den sjekke om nøkkelen er akseptabel for autentisering, og i så fall vil den sjekke om signaturen er korrekt.
  • Password: Klienten sender en melding som inneholder et passord i klartekst, beskyttet av kryptering med TLS.
  • Vertsbasert: Autentisering utføres på klientens vert snarere enn på klienten selv, og fungerer ved at klienten sender en signatur laget med den private nøkkelen til klientens vert. Dermed verifiserer ikke tjeneren brukerens identitet, men snarere identiteten til klientverten.

Forbindelsesprotokoll

Forbindelsesprotokollen til SSH kjører på toppen av transportlagsprotokollen, og antar at en sikker autentiseringsforbindelse er i bruk. Den sikre autentiseringsforbindelsen, kalt en tunell, brukes av forbindelsesprotokollen til å multiplekse et antall logiske kanaler.

Alle former for kommunikasjon med SSH understøttes ved bruk av separate kanaler. Begge sider kan åpne en kanal, og for hver kanal tilordner hver side etunikt kanalnummer. Kanaler har flytkontroll vha.  en glidende-vindu-mekanisme, og data kan ikke sendes til en kanal før en melding som indikerer at vindusplass er tilgjengelig mottas. Livet til en kanal går gjennom tre stadier: åpning av en kanal, overføring av data, og lukking av kanalen.

SSH forbindelsesprotokoll-spesifikasjonen angir fire kanaltyper:

  • Sesjon: Fjernutførelse av et program. Programmet klan være et skall, en applikasjon slik som filoverføring eller epost, en systemkommando, eller et innebygd subsystem. Når en sesjonskanal er åpnet, vil senere forespørsler brukes til å starte det fjerne programmet.
    • X11: Henviser på “X vindussystemet”, et programvaresystem og nettverksprotokoll som tilbyr et grafisk brukergrensesnitt (GUI) for datamaskiner i et nettverk (bl.a. standard på Linux-maskiner). X gjør det mulig å kjøre applikasjoner på en nettverkstjener, men la skjermbildet komme på en lokal maskin.
  • Videresendt TCP/IP (Forwarded-tcpip) – videresending av en fjern port.
  • Direkte TCP/IP (Direct-tcpip) – videresending av en lokal port

Port Forwarding

Videresending av porter er en av de nyttigste egenskapene til SSH. Det gjør det mulig å konvertere enhver usikker TCP-forbindelse til en sikker SSH-forbindelse (også kalt SSH-tunellering). Innkommende TCP-trafikk leveres til den passende applikasjonen basert på port-nummeret (en port er en identifikator av en bruker av TCP), en applikasjon kan benytte seg av flere portnummer.