The Transport Layer Security ( TLS ) eller "Sikkerhet for transportlaget" og dens forgjenger Secure Sockets Layer ( SSL ) eller "Layer stikkontakter sikker" er protokoller handel sikkerhet for datanettverk , inkludert Internett . Protokollen SSL ble opprinnelig utviklet av Netscape Communications Corporation for nettleseren. Standardorganet IETF fortsatte å utvikle det og omdøpte det Transport Layer Security (TLS) . Noen ganger snakker vi om SSL / TLS for å betegne likegyldig SSL eller TLS .
Den TLS (eller SSL ) opererer på en måte klient-server . Den oppfyller følgende sikkerhetsmål:
Protokollen er mye brukt, og implementeringen av den blir lettere av det faktum at applikasjonslagsprotokoller, som HTTP , ikke trenger å endres drastisk for å bruke en sikker tilkobling, men bare implementeres på toppen av den. SSL / TLS , som for HTTP ga protokollen HTTPS .
En spesiell IETF-arbeidsgruppe muliggjorde oppretting av TLS og dets UDP- tilkoblede modus-ekvivalent , DTLS . Siden den ble overtatt av IETF , har TLS- protokollen gått gjennom fire versjoner: TLS v1.0 i 1999, TLS v1.1 i 2006, TLS v1.2 i 2008 og TLS v1.3 i 2018.
Etter hvert som Internett vokste, begynte flere og flere kommersielle selskaper å tilby online shopping for enkeltpersoner. Tilbudet økte jevnt, men e-handelsinntektene forble beskjedne til kundene hadde tilstrekkelig tillit til å betale med kredittkort. En av måtene å sikre denne betalingen var å bruke autentiserings- og krypteringsprotokoller som SSL. Den krypterte økten brukes til å forhindre at en tredjepart fanger opp sensitive data som går gjennom nettverket: kortnummer når du betaler med bankkort , passord når brukeren identifiserer seg på et nettsted, etc.
Med et SSL-system er sikkerheten forbedret betydelig og risikoen for kunden redusert sterkt, sammenlignet med dagene da internettbetaling fremdeles var en ny teknologi. Selv om SSL / TLS, som ethvert krypteringssystem, aldri kan være helt idiotsikkert, kan det store antallet banker og e-handelsnettsteder som bruker det for å beskytte kundenes transaksjoner, bli sett på som bevis på dets motstandskraft. Ondsinnede angrep.
Fra og med 2009 brukes TLS av de fleste webservere . Internett-brukeren kan gjenkjenne at en transaksjon er kryptert med flere tegn:
Den første versjonen av SSL som ble utgitt, SSL 2.0, hadde en rekke sikkerhetsfeil, inkludert muligheten for å tvinge bruken av svakere krypteringsalgoritmer, eller mangel på beskyttelse for håndtrykk og kommunikasjon. Mulighet for en angriper til å utføre avkortingsangrep. Protokollene PCT 1.0, deretter SSL 3.0, ble utviklet for å løse hoveddelen av disse problemene, den andre ble raskt den mest populære protokollen for å sikre sentrene på Internett.
TLS er ikke strukturelt forskjellig fra versjon 3 av SSL, men endringer i bruken av hash-funksjoner betyr at de to protokollene ikke er direkte interoperable. Imidlertid har TLS, som SSLv3, en bakoverkompatibilitetsmekanisme med tidligere versjoner, dvs. ved begynnelsen av forhandlingsfasen forhandler klienten og serveren den "beste" versjonen av protokollen som er tilgjengelig for alle. Av sikkerhetsmessige årsaker, beskrevet i RFC 6176 publisert i 2011, er kompatibiliteten til TLS med versjon 2 av SSL oppgitt.
Generasjonen av symmetriske nøkler er litt sikrere i TLS enn i SSLv3 i den grad ingen trinn i algoritmen bare er avhengig av MD5 som det har dukket opp svakheter i kryptanalyse .
Den første profesjonelle versjonen av TLS 1.3 er wolfSSL , utgitt i mai 2017.
Moderne industrielle nettverk som opererer i TCP / IP bruker i økende grad TLS-sikkerhet. Dermed kombinerer protokollene for kontrollkommando av elektriske nettverk som IEC-61850, IEC-60870 og DNP3 TLS for å beskytte mot cyberangrep.
De fleste nettlesere er også TLS-klienter. Nettleserne som støtter den nyeste TLS 1.2-versjonen som standard er:
Store nettleserutviklere har kunngjort at de vil avslutte støtten for TLS 1.1 og tidligere versjoner fra og med våren 2020.
HTTPS Everywhere er en utvidelse for nettleser som gjør det mulig å utvide bruken av SSL / TLS på bestemte nettsteder. Det muliggjør kryptering på sider der det normalt er deaktivert. Dette kan åpenbart bare fungere hvis det aktuelle nettstedet allerede støtter TLS. Utvidelsen har blitt vedlikeholdt i fellesskap av Tor-prosjektet og EFF siden 2010.
I de fleste tilfeller autentiserer brukeren TLS-serveren som han kobler til. Denne godkjenningen oppnås ved bruk av et X.509 digitalt sertifikat utstedt av en sertifiseringsmyndighet (CA). Webapplikasjoner kan bruke klientarbeidsstasjonsgodkjenning ved hjelp av TLS. Det er da mulig å tilby gjensidig autentisering mellom klienten og serveren. Klientsertifikatet kan lagres i programvareformat på klientarbeidsstasjonen eller leveres av en maskinvareenhet ( smartkort , USB-token). Denne løsningen gjør det mulig å tilby sterke autentiseringsmekanismer .
Når en bruker logger på et nettsted som bruker TLSv1.2 (eller lavere), skjer følgende trinn:
Valgfritt: Hvis serveren også krever at klienten godkjenner, sender klienten det sitt eget sertifikat sammen med øktnøkkelen. Serveren fortsetter deretter som beskrevet i punkt 3 for å verifisere at klientens sertifikat er gyldig.
Siden TLSv1.3 må utvekslingen av øktnøkkelen gjøres via Diffie-Hellman med elliptiske kurver ( ECDHE ): RSA kan ikke lenger brukes til dette.
I 2001 oppdaget Serge Vaudenay et hjelpekanalangrep mot SSL. Som et resultat av standardoppdateringen er dette angrepet nå helt foreldet og kan ikke lenger brukes. Dette angrepet utnyttet en dårlig implementering av polstring som ble brukt når inngangene var av variabel størrelse. Den krypteringsmodus CBC ( siffer blokk kjeding ) er å dele dataene inn i flere blokker av samme størrelse og kryptering av sammenhengende måte (det foregående resultat blir brukt i den etterfølgende kryptering). Vaudenay-angrepet brukte responstidene til serverne i tilfelle feil under fyllingen. Med hell, var det mulig å finne ut de siste dataene som ble sendt og hente dem. Angrepet var imidlertid ineffektivt med RC4- kryptering og var bare gyldig under visse forhold. Til tross for alt har den blitt brukt med suksess mot visse "nettadresser" som sendte samme data flere ganger .
I mars 2014 ble det oppdaget et programvaresårbarhet i OpenSSL-biblioteket: Heartbleed , introdusert ved en feiltakelse i en oppdatering til OpenSSL som ble gjort to år tidligere. Denne feilen ble mye publisert, inkludert i generelle medier, da ormen Jeg elsker deg hadde vært spesielt i 2000.
15. oktober 2014 identifiserte et forskerteam hos Google en feil i utformingen av SSLv3 som tillot dekryptering av innhold. Dette angrepet ble kalt POODLE for Padding Oracle On Downgraded Legacy . Den er bare til stede i SSLv3.
2. mars 2016 beskriver forskerne feilen kalt DROWN . Den består i å bruke den gamle versjonen SSL v2 for å dekryptere TLS v1.2-teknologien.
Målet med DANE- protokollen er å korrigere visse svakheter i TLS, spesielt for MIMT- type angrep .
7 - påføringslag | HTTP , SMTP , FTP , SSH , IRC , SNMP , SIP ... |
6 - presentasjonslag | |
5 - øktlag | TLS, SSL, SSH-bruker , NetBIOS |
4 - transportlag | TCP , UDP , SCTP , RTP , DCCP ... |
3 - nettverkslag | IPv4 , IPv6 , ARP , IPX ... |
2 - bindelag | Ethernet , 802.11 WiFi , tokenring , FDDI , ... |
1 - fysisk lag | Kabel, optisk fiber , radiobølger ... |
I TCP / IP- protokollstakken sitter SSL mellom applikasjonslaget (som HTTP , FTP , SMTP , etc.) og TCP- transportlaget .
Den vanligste bruken er imidlertid fortsatt under HTTP. SSL implementeres av sesjonslaget i stabelen, som har to konsekvenser:
Server- og klientautentisering kan gjøres gjennom elektroniske sertifikater eller gjennom forhåndsdelte hemmeligheter (eller forhåndsdelt nøkkel) . Autentisering er valgfritt.
Meldinger som utveksles gjennom TLS kalles poster. Vanligvis er disse meldingene innkapslet i TCP-datagrammer. En variant på UDP eksisterer og kalles DTLS . Det er fire typer poster:
Sikkerhet oppnås på den ene siden ved asymmetrisk kryptering , for eksempel RSA-kryptering , som tillater, etter autentisering av serverens offentlige nøkkel, å lage en hemmelighet som deles mellom klienten og serveren, på den annen side ved en symmetrisk kryptering (mye raskere enn asymmetriske krypter), for eksempel AES , som brukes i datautvekslingsfasen, med symmetriske krypteringsnøkler som beregnes ut fra den delte hemmeligheten. En hash-funksjon , som SHA-1 , brukes også blant annet for å sikre dataintegritet og autentisering (f.eks. Via HMAC ).
Mer presist, applikasjonsdatameldinger krypteres ved hjelp av en krypteringsnøkkel og en symmetrisk blokkrypteringsalgoritme som AES 128 eller per strøm, slik som CHACHA20 . De autentiseres enten via en HMAC- funksjon eller direkte gjennom driftsmodus for symmetrisk blokkryptering.
Krypteringsnøkler og HMAC-nøkler genereres fra en hemmelighet som utveksles mellom de to jevnaldrende ( pre-master secret) , tilfeldige data som utveksles i løpet av håndtrykksfasen og bruk av en nøkkelavledningsfunksjon basert på HMAC. Denne hemmelige utvekslingen kan autentiseres (eller ikke) ved bruk av en digital signaturalgoritme som DSA eller RSA-algoritmen.
Totalt er det fem typer kryptografiske nøkler brukt under en TLS-økt:
De kryptografiske suitene som brukes, har følgende format:
der KE indikerer en hemmelig utvekslingsalgoritme, CIPHER en symmetrisk krypteringsalgoritme, og HASH en hash-funksjon . HMAC-funksjonen er avledet fra hash-funksjonen.
For eksempel indikerer den kryptografiske suiten TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 at peer kan bruke Ephemeral Diffie-Hellman-nøkkelutvekslingsalgoritmen på elliptiske kurver autentisert av ECDSA- signaturalgoritmen , AES 128 symmetrisk krypteringsalgoritme i GCM- modus og SH25.
I versjon 1.2 kan den hemmelige utvekslingsalgoritmen være RSA eller en variant av Diffie-Hellman-algoritmen (autentisert eller ikke, kortvarig eller ikke, på elliptiske kurver eller ikke) mens for versjon 1.3 bare er den kortvarige Diffie-Hellman-algoritmen tillatt og funksjonen for digital signatur er spesifisert i utvidelser av ClientHello-, ServerHello- og HelloRetryRequest-meldingene i Handshake- fasen .