Transportlags sikkerhed - Transport Layer Security

Internet protokol suite
Påføringslag
BGP DHCP (v6) DNS FTP HTTP HTTPS IMAP LDAP MGCP MQTT NNTP NTP POP PTP ONC/RPC RTP RTSP HVIL I FRED nippe til SMTP SNMP SSH Telnet TLS/SSL XMPP mere...
Transportlag
TCP UDP DCCP SCTP RSVP mere...
Internet lag
IP IPv4 IPv6 ICMP (v6) ECN IGMP IPsec mere...
Link lag
ARP NDP OSPF Tunneler L2TP OPP MAC Ethernet Trådløst internet DSL ISDN FDDI mere...
v t e

Transport Layer Security ( TLS ), efterfølgeren til det nu forældede Secure Sockets Layer ( SSL ), er en kryptografisk protokol designet til at levere kommunikationssikkerhed over et computernetværk. Protokollen er meget udbredt i applikationer såsom e-mail , instant messaging , og voice over IP , men dens anvendelse som den Sikkerhed lag i HTTPS fortsat den mest offentligt synlige.

TLS -protokollen sigter primært på at give privatliv og dataintegritet mellem to eller flere kommunikerende computerprogrammer. Det kører i applikationslaget på Internettet og består i sig selv af to lag: TLS -posten og TLS -håndtryksprotokollerne.

TLS er en foreslået standard for Internet Engineering Task Force (IETF), først defineret i 1999, og den nuværende version er TLS 1.3 defineret i august 2018. TLS bygger på de tidligere SSL -specifikationer (1994, 1995, 1996) udviklet af Netscape Communications til tilføjelse HTTPS -protokollen til deres Navigator -webbrowser.

Beskrivelse

Klient-server- applikationer bruger TLS- protokollen til at kommunikere på tværs af et netværk på en måde, der er designet til at forhindre aflytning og manipulation .

Da applikationer kan kommunikere enten med eller uden TLS (eller SSL), er det nødvendigt for klienten at anmode serveren om at oprette en TLS -forbindelse. En af de vigtigste måder at opnå dette på er at bruge et andet portnummer til TLS -forbindelser. For eksempel bruges port 80 typisk til ukrypteret HTTP -trafik, mens port 443 er den almindelige port, der bruges til krypteret HTTPS -trafik. En anden mekanisme er, at klienten sender en protokol-specifik anmodning til serveren om at skifte forbindelsen til TLS; for eksempel ved at lave en STARTTLS -anmodning, når du bruger mail- og nyhedsprotokollerne .

Når klienten og serveren har accepteret at bruge TLS, forhandler de en stateful -forbindelse ved hjælp af en håndtryksprocedure . Protokollerne bruger et håndtryk med en asymmetrisk chiffer til at etablere ikke kun krypteringsindstillinger, men også en sessionsspecifik delt delt nøgle, som yderligere kommunikation krypteres ved hjælp af en symmetrisk chiffer . Under dette håndtryk aftaler klienten og serveren forskellige parametre, der bruges til at etablere forbindelsens sikkerhed:

• Den håndtryk begynder, når en klient forbinder til en TLS-aktiveret server anmoder om en sikker forbindelse og klienten præsenterer en liste over understøttede cipher suites ( ciphers og hashfunktioner ).
• Fra denne liste vælger serveren en chiffer- og hash -funktion, som den også understøtter og underretter klienten om beslutningen.
• Serveren giver normalt derefter identifikation i form af et digitalt certifikat . Certifikatet indeholder servernavnet , den godkendte certifikatmyndighed (CA), der står inde for certifikatets ægthed, og serverens offentlige krypteringsnøgle.
• Klienten bekræfter gyldigheden af ​​certifikatet, inden han fortsætter.
• For at generere de sessionsnøgler, der bruges til den sikre forbindelse, skal klienten enten:
  • krypterer et tilfældigt tal ( PreMasterSecret ) med serverens offentlige nøgle og sender resultatet til serveren (som kun serveren skal kunne dekryptere med sin private nøgle); begge parter bruger derefter det tilfældige tal til at generere en unik sessionsnøgle til efterfølgende kryptering og dekryptering af data under sessionen
  • bruger Diffie – Hellman -nøgleudveksling til sikkert at generere en tilfældig og unik sessionsnøgle til kryptering og dekryptering, der har den ekstra egenskab som fremadrettet hemmeligholdelse: hvis serverens private nøgle afsløres i fremtiden, kan den ikke bruges til at dekryptere den aktuelle session, selvom sessionen opfanges og optages af en tredjepart.

Dette afslutter håndtrykket og starter den sikrede forbindelse, som er krypteret og dekrypteret med sessionsnøglen, indtil forbindelsen lukkes. Hvis et af ovenstående trin mislykkes, mislykkes TLS -håndtrykket, og forbindelsen oprettes ikke.

TLS og SSL passer ikke pænt ind i et enkelt lag af OSI -modellen eller TCP/IP -modellen . TLS kører "oven på en pålidelig transportprotokol (f.eks. TCP)", hvilket vil betyde, at den er over transportlaget . Det tjener kryptering til højere lag, hvilket normalt er præsentationslagets funktion . Imidlertid bruger applikationer generelt TLS som om det var et transportlag, selvom applikationer, der bruger TLS, aktivt skal kontrollere initiering af TLS -håndtryk og håndtering af udvekslede godkendelsescertifikater.

Når det er sikret med TLS, skal forbindelser mellem en klient (f.eks. En webbrowser) og en server (f.eks. Wikipedia.org) have en eller flere af følgende egenskaber:

• Forbindelsen er privat (eller sikker ), fordi en symmetrisk nøgle-algoritme bruges til at kryptere de transmitterede data. Nøglerne til denne symmetriske kryptering genereres entydigt for hver forbindelse og er baseret på en delt hemmelighed, der blev forhandlet i starten af ​​sessionen. Serveren og klienten forhandler detaljerne om, hvilken krypteringsalgoritme og kryptografiske nøgler der skal bruges, før den første byte med data overføres (se nedenfor). Forhandlingen af ​​en delt hemmelighed er både sikker (den forhandlede hemmelighed er ikke tilgængelig for aflyttere og kan ikke fås, selv ikke af en angriber, der placerer sig selv midt i forbindelsen) og pålidelig (ingen angriber kan ændre kommunikationen under forhandlingen uden at være opdaget).
• De kommunikerende parters identitet kan godkendes ved hjælp af public-key kryptografi . Denne godkendelse er påkrævet for serveren og valgfri for klienten.
• Forbindelsen er pålidelig, fordi hver transmitteret meddelelse inkluderer en meddelelsesintegritetskontrol ved hjælp af en meddelelsesautentificeringskode for at forhindre uopdaget tab eller ændring af dataene under transmission.

Ud over ovenstående kan omhyggelig konfiguration af TLS give yderligere fortrolighedsrelaterede ejendomme, såsom fremadrettet hemmeligholdelse , hvilket sikrer, at enhver fremtidig afsløring af krypteringsnøgler ikke kan bruges til at dekryptere enhver tidligere TLS-kommunikation.

TLS understøtter mange forskellige metoder til udveksling af nøgler, kryptering af data og godkendelse af meddelelsesintegritet. Som følge heraf indebærer sikker konfiguration af TLS mange konfigurerbare parametre, og ikke alle valg giver alle de privatlivsrelaterede egenskaber beskrevet i listen ovenfor (se tabellerne nedenfor Nøgleudveksling , § Chiffer-sikkerhed og § Dataintegritet ).

Der er gjort forsøg på at undergrave aspekter af den kommunikationssikkerhed, som TLS søger at levere, og protokollen er blevet revideret flere gange for at imødegå disse sikkerhedstrusler. Udviklere af webbrowsere har gentagne gange revideret deres produkter for at forsvare sig mod potentielle sikkerhedssvagheder, efter at disse blev opdaget (se webbrowsers TLS/SSL -supporthistorik).

Historie og udvikling

SSL- og TLS -protokoller

Protokol	Udgivet	Status
SSL 1.0	Ikke offentliggjort	Ikke offentliggjort
SSL 2.0	1995	Udfaset i 2011 ( RFC  6176 )
SSL 3.0	1996	Udfaset i 2015 (RFC  7568 )
TLS 1.0	1999	Udfaset i 2020 (RFC  8996 )
TLS 1.1	2006	Udfaset i 2020 (RFC  8996 )
TLS 1.2	2008
TLS 1.3	2018

Secure Data Network System

Transport Layer Security Protocol (TLS) blev sammen med flere andre grundlæggende netværkssikkerhedsplatforme udviklet gennem et fælles initiativ, der blev påbegyndt i august 1986, blandt National Security Agency, National Bureau of Standards, Defense Communications Agency og tolv kommunikations- og edb -virksomheder, der startede et særligt projekt kaldet Secure Data Network System (SDNS). Programmet blev beskrevet i september 1987 på den tiende nationale computersikkerhedskonference i et omfattende sæt publicerede papirer. Det innovative forskningsprogram fokuserede på at designe den næste generation af sikre computerkommunikationsnetværk og produktspecifikationer, der skal implementeres til applikationer på offentlige og private internets. Det var beregnet til at supplere de hurtigt nye OSI-internetstandarder, der er på vej frem både i den amerikanske regerings GOSIP-profiler og i den enorme ITU-ISO JTC1 internetindsats internationalt. Oprindeligt kendt som SP4-protokollen, blev den omdøbt til TLS og efterfølgende udgivet i 1995 som international standard ITU-T X.274 | ISO/IEC 10736: 1995.

Sikker netværksprogrammering

Tidlig forskningsindsats mod transportlagssikkerhed omfattede Secure Network Programming (SNP) applikationsprogrammeringsinterface (API), som i 1993 undersøgte tilgangen til at have et sikkert transportlags API, der ligner Berkeley-sockets , for at lette eftermontering af eksisterende netværksapplikationer med sikkerhed foranstaltninger.

SSL 1.0, 2.0 og 3.0

Netscape udviklede de originale SSL -protokoller, og Taher Elgamal , chefforsker ved Netscape Communications fra 1995 til 1998, er blevet beskrevet som "SSL -far ". SSL version 1.0 blev aldrig offentliggjort på grund af alvorlige sikkerhedsfejl i protokollen. Efter udgivelse i februar 1995 blev version 2.0 hurtigt opdaget at indeholde en række sikkerheds- og anvendelsesfejl. Den brugte de samme kryptografiske nøgler til meddelelsesgodkendelse og kryptering. Den havde en svag MAC -konstruktion, der brugte MD5 -hashfunktionen med et hemmeligt præfiks, hvilket gjorde den sårbar over for længdeforlængelsesangreb. Og det gav ingen beskyttelse af hverken det åbende håndtryk eller en eksplicit besked lukning, som begge betød, at man-i-midten-angreb kunne gå uopdaget. Desuden antog SSL 2.0 en enkelt tjeneste og et fast domænecertifikat, der var i modstrid med den meget udbredte funktion ved virtuel hosting på webservere, så de fleste websteder blev effektivt nedsat ved brug af SSL.

Disse fejl nødvendiggjorde det komplette redesign af protokollen til SSL version 3.0. Den blev udgivet i 1996 og blev produceret af Paul Kocher i samarbejde med Netscape -ingeniører Phil Karlton og Alan Freier med en referenceimplementering af Christopher Allen og Tim Dierks fra Consensus Development. Nyere versioner af SSL/TLS er baseret på SSL 3.0. 1996 -udkastet til SSL 3.0 blev udgivet af IETF som et historisk dokument i RFC  6101 .

SSL 2.0 blev udfaset i 2011 af RFC  6176 . I 2014 blev SSL 3.0 sig at være sårbare over for den POODLE angreb, der påvirker alle blok ciphers i SSL; RC4 , den eneste ikke-blokerede chiffer, der understøttes af SSL 3.0, er også muligvis brudt som brugt i SSL 3.0. SSL 3.0 blev udfaset i juni 2015 af RFC  7568 .

TLS 1.0

TLS 1.0 blev først defineret i RFC  2246 i januar 1999 som en opgradering af SSL Version 3.0, og skrevet af Christopher Allen og Tim Dierks fra Consensus Development. Som anført i RFC er "forskellene mellem denne protokol og SSL 3.0 ikke dramatiske, men de er betydelige nok til at udelukke interoperabilitet mellem TLS 1.0 og SSL 3.0". Tim Dierks skrev senere, at disse ændringer og omdøbningen fra "SSL" til "TLS" var en ansigtsbesparende gestus til Microsoft, "så det ikke ville se ud som om IETF bare var en gummistampning af Netscapes protokol".

Det PCI Rådet foreslog, at organisationer migrere fra TLS 1.0 til TLS 1.1 eller højere inden den 30. juni, 2018. I oktober 2018 Apple , Google , Microsoft , og Mozilla annoncerede i fællesskab de ville misbillige TLS 1.0 og 1.1 I marts 2020.

TLS 1.1

TLS 1.1 blev defineret i RFC  4346 i april 2006. Det er en opdatering fra TLS version 1.0. Væsentlige forskelle i denne version omfatter:

• Tilføjet beskyttelse mod cipher-block chaining (CBC) angreb.
  • Den implicitte initialiseringsvektor (IV) blev erstattet med en eksplicit IV.
  • Ændring i håndtering af polstringsfejl .
• Understøttelse af IANA registrering af parametre.

Understøttelse af TLS -versioner 1.0 og 1.1 blev udbredt af websteder omkring 2020, hvilket deaktiverede adgang til Firefox -versioner før 24 og Google Chrome før 29.

TLS 1.2

TLS 1.2 blev defineret i RFC  5246 i august 2008. Det er baseret på den tidligere TLS 1.1 -specifikation. Store forskelle omfatter:

• The MD5 - SHA-1 kombination på pseudotilfældige funktion (PRF) erstattet med SHA-256 , med en mulighed for at bruge cipher suite specificerede PRF'er.
• MD5 – SHA-1-kombinationen i den færdige besked- hash blev erstattet med SHA-256 med mulighed for at bruge cipher suite-specifikke hash-algoritmer. Størrelsen af ​​hash i den færdige meddelelse skal dog stadig være mindst 96 bit .
• Kombinationen MD5 – SHA-1 i det digitalt signerede element blev erstattet med en enkelt hash, der blev forhandlet under håndtryk , hvilket som standard er SHA-1.
• Forøgelse i klientens og serverens evne til at specificere, hvilke hash og signaturalgoritmer de accepterer.
• Udvidelse af understøttelse af godkendte krypteringscifre , der hovedsageligt bruges til Galois/Counter Mode (GCM) og CCM -tilstand med Advanced Encryption Standard (AES) kryptering.
• TLS Extensions definition og AES cipher suites blev tilføjet.

Alle TLS -versioner blev yderligere forfinet i RFC  6176 i marts 2011, hvilket fjernede deres bagudkompatibilitet med SSL, således at TLS -sessioner aldrig forhandler om brug af Secure Sockets Layer (SSL) version 2.0.

TLS 1.3

TLS 1.3 blev defineret i RFC  8446 i august 2018. Det er baseret på den tidligere TLS 1.2 -specifikation. Store forskelle fra TLS 1.2 omfatter:

• Adskillelse af nøgleaftaler og godkendelsesalgoritmer fra chiffer -suiterne
• Fjernelse af støtte til svage og mindre brugte navngivne elliptiske kurver
• Fjernelse af understøttelse af MD5 og SHA-224 kryptografiske hashfunktioner
• Kræver digitale signaturer, selv når en tidligere konfiguration bruges
• Integration af HKDF og det semi-flygtige DH-forslag
• Udskift genoptagelse med PSK og billetter
• Understøtter 1- RTT håndtryk og første support til 0- RTT
• Opretholder perfekt fortrolig hemmelighed ved hjælp af flygtige nøgler under (EF) DH -nøgleaftalen
• Faldende understøttelse af mange usikre eller forældede funktioner, herunder komprimering , genforhandling, ikke- AEAD- cifre, ikke- PFS- nøgleudveksling (blandt dem er statisk RSA og statisk DH- nøgleudveksling), brugerdefinerede DHE- grupper, EC-punktformatforhandling, Change Cipher Spec-protokol, Hej meddelelse UNIX -tid, og længdefeltet AD -input til AEAD -chiffer
• Forbyder SSL- eller RC4 -forhandling for bagudkompatibilitet
• Integrering af brug af session hash
• Udfasning af brug af rekordlagets versionsnummer og indefrysning af nummeret for forbedret bagudkompatibilitet
• Flytning af nogle sikkerhedsrelaterede algoritmedetaljer fra et appendiks til specifikationen og henvisning af ClientKeyShare til et appendiks
• Tilføjelse af ChaCha20 -strømkoder med Poly1305 -meddelelsesgodkendelseskoden
• Tilføjelse af Ed25519 og Ed448 digitale signaturalgoritmer
• Tilføjelse af x25519 og x448 nøgleudvekslingsprotokoller
• Tilføjelse støtte til at sende flere OCSP svar
• Kryptering af alle håndtryksbeskeder efter ServerHello

Network Security Services (NSS), kryptografibiblioteket udviklet af Mozilla og brugt af dets webbrowser Firefox , aktiverede TLS 1.3 som standard i februar 2017. TLS 1.3 -understøttelse blev efterfølgende tilføjet - men på grund af kompatibilitetsproblemer for et lille antal brugere, ikke automatisk aktiveret - til Firefox 52.0 , som blev udgivet i marts 2017. TLS 1.3 blev som standard aktiveret i maj 2018 med udgivelsen af Firefox 60.0 .

Google Chrome indstillede TLS 1.3 som standardversionen i en kort periode i 2017. Den fjernede den derefter som standard på grund af inkompatible mellemkasser som f.eks. Blue Coat web -proxyer .

Under IETF 100 Hackathon, der fandt sted i Singapore i 2017, arbejdede TLS Group på at tilpasse open source-applikationer til at bruge TLS 1.3. TLS -gruppen bestod af personer fra Japan , Storbritannien og Mauritius via cyberstorm.mu -teamet. Dette arbejde blev fortsat i IETF 101 Hackathon i London og IETF 102 Hackathon i Montreal.

wolfSSL muliggjorde brugen af ​​TLS 1.3 fra version 3.11.1, udgivet i maj 2017. Som den første kommercielle TLS 1.3 -implementering understøttede wolfSSL 3.11.1 Draft 18 og understøtter nu Draft 28, den endelige version samt mange ældre versioner . Der blev offentliggjort en række blogs om ydelsesforskellen mellem TLS 1.2 og 1.3.

I September 2018, det populære OpenSSL -projekt udgav version 1.1.1 af sit bibliotek, hvor understøttelse af TLS 1.3 var "overskriften ny funktion".

Enterprise Transport Security

Den Electronic Frontier Foundation rost TLS 1.3 og udtrykt bekymring over varianten protokol Enterprise Transport Security (ETS), der med vilje deaktiverer vigtige sikkerhedsforanstaltninger i TLS 1.3. Oprindeligt kaldet Enterprise TLS (eTLS), er ETS en offentliggjort standard kendt som 'ETSI TS103523-3', "Middlebox Security Protocol, Part3: Enterprise Transport Security". Den er udelukkende beregnet til brug inden for proprietære netværk såsom banksystemer. ETS understøtter ikke fremadrettet hemmeligholdelse for at give tredjepartsorganisationer, der er forbundet til de proprietære netværk, mulighed for at bruge deres private nøgle til at overvåge netværkstrafik til påvisning af malware og gøre det lettere at foretage revisioner. På trods af de påståede fordele advarede EFF om, at tabet af fremadrettet hemmeligholdelse kan gøre det lettere for data at blive afsløret sammen med at sige, at der er bedre måder at analysere trafik på.

Digitale certifikater

Et digitalt certifikat bekræfter ejerskabet af en offentlig nøgle af certifikatets navngivne emne og angiver visse forventede anvendelser af denne nøgle. Dette gør det muligt for andre (afhængige parter) at stole på underskrifter eller påstande fra den private nøgle, der svarer til den certificerede offentlige nøgle. Keystores og tillidsbutikker kan være i forskellige formater, f.eks. .Pem, .crt, .pfx og .jks.

Certifikatmyndigheder

TLS er typisk afhængig af et sæt betroede tredjepartscertifikatmyndigheder for at fastslå ægtheden af ​​certifikater. Tillid er normalt forankret i en liste over certifikater, der distribueres med brugeragent -software, og kan ændres af den afhængige part.

Ifølge Netcraft , der overvåger aktive TLS-certifikater, har den markedsledende certifikatmyndighed (CA) været Symantec siden begyndelsen af ​​deres undersøgelse (eller VeriSign, før forretningsenheden Authentication Services blev købt af Symantec). Fra 2015 tegnede Symantec sig for knap en tredjedel af alle certifikater og 44% af de gyldige certifikater, der blev brugt af de 1 million travleste websteder, som Netcraft regner med. I 2017 solgte Symantec sin TLS/SSL -forretning til DigiCert. I en opdateret rapport blev det vist, at IdenTrust , DigiCert og Sectigo er top 3 certifikatmyndigheder med hensyn til markedsandel siden maj 2019.

Som en konsekvens af at vælge X.509 -certifikater er certifikatmyndigheder og en offentlig nøgleinfrastruktur nødvendige for at verificere forholdet mellem et certifikat og dets ejer samt for at generere, underskrive og administrere gyldigheden af ​​certifikater. Selvom dette kan være mere bekvemt end at verificere identiteterne via et tillidsweb , gjorde masseovervågningsoplysningerne fra 2013 det mere almindeligt kendt, at certifikatmyndighederne er et svagt punkt ud fra et sikkerhedsmæssigt synspunkt, hvilket tillader man-in-the-middle angreb (MITM) hvis certifikatmyndigheden samarbejder (eller er kompromitteret).

Algoritmer

Nøgleudveksling eller nøgleaftale

Inden en klient og server kan begynde at udveksle oplysninger, der er beskyttet af TLS, skal de sikkert udveksle eller blive enige om en krypteringsnøgle og en chiffer, der skal bruges til kryptering af data (se § Chiffer ). Blandt de metoder, der bruges til nøgleudveksling/-aftale, er: offentlige og private nøgler genereret med RSA (betegnet TLS_RSA i TLS-håndtryksprotokollen), Diffie – Hellman (TLS_DH), flygtig Diffie – Hellman (TLS_DHE), elliptisk-kurve Diffie – Hellman ( TLS_ECDH), flygtig elliptisk kurve Diffie – Hellman (TLS_ECDHE), anonym Diffie – Hellman (TLS_DH_anon), foruddelt nøgle (TLS_PSK) og Secure Remote Password (TLS_SRP).

TLS_DH_anon- og TLS_ECDH_anon-nøgleaftalemetoderne godkender ikke serveren eller brugeren og bruges derfor sjældent, fordi de er sårbare over for man-in-the-middle-angreb . Det er kun TLS_DHE og TLS_ECDHE, der giver fortrolig hemmelighed .

Offentlige nøglecertifikater, der bruges under udveksling/aftale, varierer også i størrelsen på de offentlige/private krypteringsnøgler, der blev brugt under udvekslingen, og dermed robustheden af ​​den stillede sikkerhed. I juli 2013 meddelte Google , at det ikke længere ville bruge 1024-bit offentlige nøgler og i stedet ville skifte til 2048-bit nøgler for at øge sikkerheden ved den TLS-kryptering, det giver sine brugere, fordi krypteringsstyrken er direkte relateret til nøglestørrelsen .

Nøgleudveksling/aftale og godkendelse

Algoritme	SSL 2.0	SSL 3.0	TLS 1.0	TLS 1.1	TLS 1.2	TLS 1.3	Status
RSA	Ja	Ja	Ja	Ja	Ja	Ingen	Defineret til TLS 1.2 i RFC'er
DH - RSA	Ingen	Ja	Ja	Ja	Ja	Ingen
DHE - RSA ( fremadrettet hemmeligholdelse )	Ingen	Ja	Ja	Ja	Ja	Ja
ECDH - RSA	Ingen	Ingen	Ja	Ja	Ja	Ingen
ECDHE - RSA (fremadrettet hemmeligholdelse)	Ingen	Ingen	Ja	Ja	Ja	Ja
DH - DSS	Ingen	Ja	Ja	Ja	Ja	Ingen
DHE - DSS (fremadrettet hemmeligholdelse)	Ingen	Ja	Ja	Ja	Ja	Ingen
ECDH - ECDSA	Ingen	Ingen	Ja	Ja	Ja	Ingen
ECDHE - ECDSA (fremadrettet hemmeligholdelse)	Ingen	Ingen	Ja	Ja	Ja	Ja
ECDH - EdDSA	Ingen	Ingen	Ja	Ja	Ja	Ingen
ECDHE - EdDSA (fremadrettet hemmeligholdelse)	Ingen	Ingen	Ja	Ja	Ja	Ja
PSK	Ingen	Ingen	Ja	Ja	Ja
PSK - RSA	Ingen	Ingen	Ja	Ja	Ja
DHE - PSK (fremadrettet hemmeligholdelse)	Ingen	Ingen	Ja	Ja	Ja	Ja
ECDHE - PSK (fremadrettet hemmeligholdelse)	Ingen	Ingen	Ja	Ja	Ja	Ja
SRP	Ingen	Ingen	Ja	Ja	Ja
SRP - DSS	Ingen	Ingen	Ja	Ja	Ja
SRP - RSA	Ingen	Ingen	Ja	Ja	Ja
Kerberos	Ingen	Ingen	Ja	Ja	Ja
DH -ANON (usikker)	Ingen	Ja	Ja	Ja	Ja
ECDH -ANON (usikker)	Ingen	Ingen	Ja	Ja	Ja
GOST R 34,10-94 / 34,10-2001	Ingen	Ingen	Ja	Ja	Ja		Foreslået i RFC -udkast

Chiffer

Chiffer sikkerhed mod offentligt kendte gennemførlige angreb

Chiffer			Protokolversion						Status
Type	Algoritme	Nominel styrke (bits)	SSL 2.0	SSL 3.0	TLS 1.0	TLS 1.1	TLS 1.2	TLS 1.3
Bloker chiffer med driftsmåde	AES GCM	256, 128	Ikke relevant	Ikke relevant	Ikke relevant	Ikke relevant	Sikker	Sikker	Defineret til TLS 1.2 i RFC'er
	AES CCM		Ikke relevant	Ikke relevant	Ikke relevant	Ikke relevant	Sikker	Sikker
	AES CBC		Ikke relevant	Usikker	Afhænger af afbødninger	Afhænger af afbødninger	Afhænger af afbødninger	Ikke relevant
	Camellia GCM	256, 128	Ikke relevant	Ikke relevant	Ikke relevant	Ikke relevant	Sikker	Ikke relevant
	Camellia CBC		Ikke relevant	Usikker	Afhænger af afbødninger	Afhænger af afbødninger	Afhænger af afbødninger	Ikke relevant
	ARIA GCM	256, 128	Ikke relevant	Ikke relevant	Ikke relevant	Ikke relevant	Sikker	Ikke relevant
	ARIA CBC		Ikke relevant	Ikke relevant	Afhænger af afbødninger	Afhænger af afbødninger	Afhænger af afbødninger	Ikke relevant
	FRØ CBC	128	Ikke relevant	Usikker	Afhænger af afbødninger	Afhænger af afbødninger	Afhænger af afbødninger	Ikke relevant
	3DES EDE CBC	112	Usikker	Usikker	Usikker	Usikker	Usikker	Ikke relevant
	GOST 28147-89 CNT	256	Ikke relevant	Ikke relevant	Usikker	Usikker	Usikker	Ikke relevant	Defineret i RFC  4357
	IDEA CBC	128	Usikker	Usikker	Usikker	Usikker	Ikke relevant	Ikke relevant	Fjernet fra TLS 1.2
	DES CBC	056	Usikker	Usikker	Usikker	Usikker	Ikke relevant	Ikke relevant
		040	Usikker	Usikker	Usikker	Ikke relevant	Ikke relevant	Ikke relevant	Forbudt i TLS 1.1 og senere
	RC2 CBC	040	Usikker	Usikker	Usikker	Ikke relevant	Ikke relevant	Ikke relevant
Stream chiffer	ChaCha20 - Poly1305	256	Ikke relevant	Ikke relevant	Ikke relevant	Ikke relevant	Sikker	Sikker	Defineret til TLS 1.2 i RFC'er
	RC4	128	Usikker	Usikker	Usikker	Usikker	Usikker	Ikke relevant	Forbudt i alle versioner af TLS af RFC  7465
		040	Usikker	Usikker	Usikker	Ikke relevant	Ikke relevant	Ikke relevant
Ingen	Nul	-	Usikker	Usikker	Usikker	Usikker	Usikker	Ikke relevant	Defineret til TLS 1.2 i RFC'er

Noter

Dataintegritet

En meddelelsesgodkendelseskode (MAC) bruges til dataintegritet. HMAC bruges til CBC -tilstand af blokchiffer. Godkendt kryptering (AEAD) såsom GCM-tilstand og CCM-tilstand bruger AEAD-integreret MAC og bruger ikke HMAC . HMAC-baseret PRF eller HKDF bruges til TLS-håndtryk.

Dataintegritet

Algoritme	SSL 2.0	SSL 3.0	TLS 1.0	TLS 1.1	TLS 1.2	TLS 1.3	Status
HMAC - MD5	Ja	Ja	Ja	Ja	Ja	Ingen	Defineret til TLS 1.2 i RFC'er
HMAC - SHA1	Ingen	Ja	Ja	Ja	Ja	Ingen
HMAC - SHA256/384	Ingen	Ingen	Ingen	Ingen	Ja	Ingen
AEAD	Ingen	Ingen	Ingen	Ingen	Ja	Ja
GOST 28147-89 IMIT	Ingen	Ingen	Ja	Ja	Ja		Foreslået i RFC -udkast
GOST R 34,11-94	Ingen	Ingen	Ja	Ja	Ja

Ansøgninger og adoption

I applikationsdesign implementeres TLS normalt oven på Transport Layer-protokoller, der krypterer alle protokolrelaterede data fra protokoller som HTTP , FTP , SMTP , NNTP og XMPP .

Historisk set er TLS primært blevet brugt sammen med pålidelige transportprotokoller, f.eks. Transmission Control Protocol (TCP). Det er imidlertid også blevet implementeret med datagram-orienterede transportprotokoller, såsom User Datagram Protocol (UDP) og Datagram Congestion Control Protocol (DCCP), hvis anvendelse er blevet standardiseret uafhængigt ved hjælp af betegnelsen Datagram Transport Layer Security (DTLS) .

Hjemmesider

En primær brug af TLS er at sikre World Wide Web -trafik mellem et websted og en webbrowser, der er kodet med HTTP -protokollen. Denne brug af TLS til sikring af HTTP -trafik udgør HTTPS -protokollen.

Support til webstedsprotokol (sep. 2021)

protokol -version	Hjemmeside support	Sikkerhed
SSL 2.0	0,4%	Usikker
SSL 3.0	3,1%	Usikker
TLS 1.0	44,0%	Udfaset
TLS 1.1	48,1%	Udfaset
TLS 1.2	99,6%	Afhænger af chiffer- og klientbegrænsninger
TLS 1.3	48,9%	Sikker

Noter

Webbrowsere

Fra april 2016 understøtter de nyeste versioner af alle større webbrowsere TLS 1.0, 1.1 og 1.2, og har dem aktiveret som standard. Det er dog ikke alle understøttede Microsoft -operativsystemer, der understøtter den nyeste version af IE. Derudover understøtter mange operativsystemer i øjeblikket flere versioner af IE, men dette er ændret i henhold til Microsofts Internet Explorer Support Lifecycle Policy FAQ "Fra og med den 12. januar 2016 modtager kun den nyeste version af Internet Explorer til et understøttet operativsystem tekniske support og sikkerhedsopdateringer. " Siden fortsætter med at vise den seneste understøttede version af IE på denne dato for hvert operativsystem. Den næste kritiske dato ville være, når et operativsystem når slutningen af ​​levetiden, som er i Microsofts Windows -livscyklus -faktablad .

Lempelser mod kendte angreb er ikke nok endnu:

• Begrænsninger mod POODLE -angreb : nogle browsere forhindrer allerede tilbagefald til SSL 3.0; denne formindskelse skal imidlertid understøttes ikke kun af klienter, men også af servere. Deaktivering af selve SSL 3.0, implementering af "anti-POODLE record splitting" eller benægtelse af CBC-chiffer i SSL 3.0 er påkrævet.
  • Google Chrome: komplet (TLS_FALLBACK_SCSV er implementeret siden version 33, tilbagekald til SSL 3.0 er deaktiveret siden version 39, selve SSL 3.0 er deaktiveret som standard siden version 40. Understøttelse af selve SSL 3.0 blev droppet siden version 44.)
  • Mozilla Firefox: komplet (understøttelse af selve SSL 3.0 er droppet siden version 39. Selve SSL 3.0 er som standard deaktiveret og tilbagekald til SSL 3.0 er deaktiveret siden version 34 , TLS_FALLBACK_SCSV er implementeret siden version 35. I ESR er SSL 3.0 selv deaktiveret af standard og TLS_FALLBACK_SCSV er implementeret siden ESR 31.3.)
  • Internet Explorer: delvis (kun i version 11, SSL 3.0 er som standard deaktiveret siden april 2015. Version 10 og ældre er stadig sårbare over for POODLE.)
  • Opera : komplet (TLS_FALLBACK_SCSV er implementeret siden version 20, "anti-POODLE record splitting", som kun er effektiv med implementering på klientsiden, er implementeret siden version 25, SSL 3.0 selv er deaktiveret som standard siden version 27. Support af SSL 3.0 selv vil blive droppet siden version 31.)
  • Safari: komplet (kun på OS X 10.8 og nyere og iOS 8, CBC -chiffer under tilbagekald til SSL 3.0 nægtes, men det betyder, at det vil bruge RC4, hvilket ikke også anbefales. Support af SSL 3.0 selv falder på OS X 10.11 og nyere og iOS 9.)
• Afbødning mod RC4 -angreb :
  • Google Chrome deaktiverede RC4 undtagen som en tilbagefald siden version 43. RC4 er deaktiveret siden Chrome 48.
  • Firefox deaktiveret RC4 undtagen som en tilbagefald siden version 36. Firefox 44 deaktiveret RC4 som standard.
  • Opera deaktiveret RC4 undtagen som en tilbagefald siden version 30. RC4 er deaktiveret siden Opera 35.
  • Internet Explorer til Windows 7 / Server 2008 R2 og til Windows 8 / Server 2012 har angivet prioriteten for RC4 til lavest og kan også deaktivere RC4 undtagen som en tilbagevenden gennem registreringsindstillinger. Internet Explorer 11 Mobile 11 til Windows Phone 8.1 deaktiverer RC4 undtagen som en tilbagevenden, hvis ingen anden aktiveret algoritme fungerer. Edge og IE 11 deaktiverer RC4 fuldstændigt i august 2016.
• Begrænsning mod FREAK -angreb :
  • Android -browseren, der følger med Android 4.0 og ældre, er stadig sårbar over for FREAK -angrebet.
  • Internet Explorer 11 Mobile er stadig sårbar over for FREAK -angrebet.
  • Google Chrome, Internet Explorer (desktop), Safari (desktop og mobil) og Opera (mobil) har FREAK -begrænsninger på plads.
  • Mozilla Firefox på alle platforme og Google Chrome på Windows blev ikke påvirket af FREAK.

TLS/SSL -supporthistorik for webbrowsere

Browser	Version		Platforme	SSL -protokoller		TLS -protokoller				Certifikat support			Sårbarheder rettet						Protokolvalg efter bruger
				SSL 2.0 (usikker)	SSL 3.0 (usikker)	TLS 1.0 (udfaset)	TLS 1.1 (udfaset)	TLS 1.2	TLS 1.3	EV	SHA-2	ECDSA	DYR	FORBRYDELSE	POODLE (SSLv3)	RC4	TOSSE	Logjam
Google Chrome ( Chrome til Android )	1–9		Windows  (7+) macOS  (10.11+) Linux Android  (5.0+) iOS  (12.2+) Chrome OS	Deaktiveret som standard	Aktiveret som standard	Ja	Ingen	Ingen	Ingen	Ja (kun desktop)	har brug for SHA-2-kompatibelt operativsystem	har brug for ECC -kompatibelt operativsystem	Ikke påvirket	Sårbar (HTTPS)	Sårbar	Sårbar	Sårbar (undtagen Windows)	Sårbar	Ja
	10–20			Ingen	Aktiveret som standard	Ja	Ingen	Ingen	Ingen	Ja (kun desktop)	har brug for SHA-2-kompatibelt operativsystem	har brug for ECC -kompatibelt operativsystem	Ikke påvirket	Sårbar (HTTPS/SPDY)	Sårbar	Sårbar	Sårbar (undtagen Windows)	Sårbar	Ja
	21			Ingen	Aktiveret som standard	Ja	Ingen	Ingen	Ingen	Ja (kun desktop)	har brug for SHA-2-kompatibelt operativsystem	har brug for ECC -kompatibelt operativsystem	Ikke påvirket	Lettet	Sårbar	Sårbar	Sårbar (undtagen Windows)	Sårbar	Ja
	22–29			Ingen	Aktiveret som standard	Ja	Ja	Ingen	Ingen	Ja (kun desktop)	har brug for SHA-2-kompatibelt operativsystem	har brug for ECC -kompatibelt operativsystem	Ikke påvirket	Lettet	Sårbar	Sårbar	Sårbar (undtagen Windows)	Sårbar	Midlertidig
	30–32			Ingen	Aktiveret som standard	Ja	Ja	Ja	Ingen	Ja (kun desktop)	har brug for SHA-2-kompatibelt operativsystem	har brug for ECC -kompatibelt operativsystem	Ikke påvirket	Lettet	Sårbar	Sårbar	Sårbar (undtagen Windows)	Sårbar	Midlertidig
	33–37			Ingen	Aktiveret som standard	Ja	Ja	Ja	Ingen	Ja (kun desktop)	har brug for SHA-2-kompatibelt operativsystem	har brug for ECC -kompatibelt operativsystem	Ikke påvirket	Lettet	Delvist formindsket	Laveste prioritet	Sårbar (undtagen Windows)	Sårbar	Midlertidig
	38, 39			Ingen	Aktiveret som standard	Ja	Ja	Ja	Ingen	Ja (kun desktop)	Ja	har brug for ECC -kompatibelt operativsystem	Ikke påvirket	Lettet	Delvist formindsket	Laveste prioritet	Sårbar (undtagen Windows)	Sårbar	Midlertidig
	40			Ingen	Deaktiveret som standard	Ja	Ja	Ja	Ingen	Ja (kun desktop)	Ja	har brug for ECC -kompatibelt operativsystem	Ikke påvirket	Lettet	Lettet	Laveste prioritet	Sårbar (undtagen Windows)	Sårbar	Ja
	41, 42			Ingen	Deaktiveret som standard	Ja	Ja	Ja	Ingen	Ja (kun desktop)	Ja	har brug for ECC -kompatibelt operativsystem	Ikke påvirket	Lettet	Lettet	Laveste prioritet	Lettet	Sårbar	Ja
	43			Ingen	Deaktiveret som standard	Ja	Ja	Ja	Ingen	Ja (kun desktop)	Ja	har brug for ECC -kompatibelt operativsystem	Ikke påvirket	Lettet	Lettet	Kun som tilbagevenden	Lettet	Sårbar	Ja
	44–47			Ingen	Ingen	Ja	Ja	Ja	Ingen	Ja (kun desktop)	Ja	har brug for ECC -kompatibelt operativsystem	Ikke påvirket	Lettet	Ikke påvirket	Kun som tilbagevenden	Lettet	Lettet	Midlertidig
	48, 49			Ingen	Ingen	Ja	Ja	Ja	Ingen	Ja (kun desktop)	Ja	har brug for ECC -kompatibelt operativsystem	Ikke påvirket	Lettet	Ikke påvirket	Deaktiveret som standard	Lettet	Lettet	Midlertidig
	50–53			Ingen	Ingen	Ja	Ja	Ja	Ingen	Ja (kun desktop)	Ja	Ja	Ikke påvirket	Lettet	Ikke påvirket	Deaktiveret som standard	Lettet	Lettet	Midlertidig
	54–66			Ingen	Ingen	Ja	Ja	Ja	Deaktiveret som standard (udkast til version)	Ja (kun desktop)	Ja	Ja	Ikke påvirket	Lettet	Ikke påvirket	Deaktiveret som standard	Lettet	Lettet	Midlertidig
	67–69			Ingen	Ingen	Ja	Ja	Ja	Ja (kladdeversion)	Ja (kun desktop)	Ja	Ja	Ikke påvirket	Lettet	Ikke påvirket	Deaktiveret som standard	Lettet	Lettet	Midlertidig
	70–83			Ingen	Ingen	Ja	Ja	Ja	Ja	Ja (kun desktop)	Ja	Ja	Ikke påvirket	Lettet	Ikke påvirket	Deaktiveret som standard	Lettet	Lettet	Midlertidig
	84–90			Ingen	Ingen	Advarsel som standard	Advarsel som standard	Ja	Ja	Ja (kun desktop)	Ja	Ja	Ikke påvirket	Lettet	Ikke påvirket	Deaktiveret som standard	Lettet	Lettet	Midlertidig
	91–93	94		Ingen	Ingen	Ingen	Ingen	Ja	Ja	Ja (kun desktop)	Ja	Ja	Ikke påvirket	Lettet	Ikke påvirket	Deaktiveret som standard	Lettet	Lettet	Midlertidig
Browser	Version		Platforme	SSL 2.0 (usikker)	SSL 3.0 (usikker)	TLS 1.0 (udfaset)	TLS 1.1 (udfaset)	TLS 1.2	TLS 1.3	EV certifikat	SHA-2 certifikat	ECDSA certifikat	DYR	FORBRYDELSE	POODLE (SSLv3)	RC4	TOSSE	Logjam	Protokolvalg efter bruger
Microsoft Edge (Chrom-baseret) OS-uafhængig	79–83		Windows  (7+) macOS  (10.12+) Linux  Android  (4.4+) iOS  (11.0+)	Ingen	Ingen	Ja	Ja	Ja	Ja	Ja	Ja	Ja	Lettet	Ikke påvirket	Ikke påvirket	Deaktiveret som standard	Lettet	Lettet	Ja
	84–90			Ingen	Ingen	Advarsel som standard	Advarsel som standard	Ja	Ja	Ja	Ja	Ja	Lettet	Ikke påvirket	Ikke påvirket	Deaktiveret som standard	Lettet	Lettet	Ja
	91-93	94		Ingen	Ingen	Ingen	Ingen	Ja	Ja	Ja	Ja	Ja	Lettet	Ikke påvirket	Ikke påvirket	Deaktiveret som standard	Lettet	Lettet	Ja
Browser	Version		Platforme	SSL 2.0 (usikker)	SSL 3.0 (usikker)	TLS 1.0 (udfaset)	TLS 1.1 (udfaset)	TLS 1.2	TLS 1.3	EV certifikat	SHA-2 certifikat	ECDSA certifikat	DYR	FORBRYDELSE	POODLE (SSLv3)	RC4	TOSSE	Logjam	Protokolvalg efter bruger
Mozilla Firefox ( Firefox til mobil )	1,0, 1,5		Windows  (7+) macOS  (10.12+) Linux Android  (5.0+) iOS (11.4+) Firefox OS Maemo ESR kun til: Windows  (7+) macOS  (10.9+) Linux	Aktiveret som standard	Aktiveret som standard	Ja	Ingen	Ingen	Ingen	Ingen	Ja	Ingen	Ikke påvirket	Ikke påvirket	Sårbar	Sårbar	Ikke påvirket	Sårbar	Ja
	2			Deaktiveret som standard	Aktiveret som standard	Ja	Ingen	Ingen	Ingen	Ingen	Ja	Ja	Ikke påvirket	Ikke påvirket	Sårbar	Sårbar	Ikke påvirket	Sårbar	Ja
	3–7			Deaktiveret som standard	Aktiveret som standard	Ja	Ingen	Ingen	Ingen	Ja	Ja	Ja	Ikke påvirket	Ikke påvirket	Sårbar	Sårbar	Ikke påvirket	Sårbar	Ja
	8-10 ESR 10			Ingen	Aktiveret som standard	Ja	Ingen	Ingen	Ingen	Ja	Ja	Ja	Ikke påvirket	Ikke påvirket	Sårbar	Sårbar	Ikke påvirket	Sårbar	Ja
	11–14			Ingen	Aktiveret som standard	Ja	Ingen	Ingen	Ingen	Ja	Ja	Ja	Ikke påvirket	Sårbar (SPDY)	Sårbar	Sårbar	Ikke påvirket	Sårbar	Ja
	15–22 ESR 17.0–17.0.10			Ingen	Aktiveret som standard	Ja	Ingen	Ingen	Ingen	Ja	Ja	Ja	Ikke påvirket	Lettet	Sårbar	Sårbar	Ikke påvirket	Sårbar	Ja
	ESR 17.0.11			Ingen	Aktiveret som standard	Ja	Ingen	Ingen	Ingen	Ja	Ja	Ja	Ikke påvirket	Lettet	Sårbar	Laveste prioritet	Ikke påvirket	Sårbar	Ja
	23			Ingen	Aktiveret som standard	Ja	Deaktiveret som standard	Ingen	Ingen	Ja	Ja	Ja	Ikke påvirket	Lettet	Sårbar	Sårbar	Ikke påvirket	Sårbar	Ja
	24, 25.0.0 ESR 24.0–24.1.0			Ingen	Aktiveret som standard	Ja	Deaktiveret som standard	Deaktiveret som standard	Ingen	Ja	Ja	Ja	Ikke påvirket	Lettet	Sårbar	Sårbar	Ikke påvirket	Sårbar	Ja
	25.0.1, 26 ESR 24.1.1			Ingen	Aktiveret som standard	Ja	Deaktiveret som standard	Deaktiveret som standard	Ingen	Ja	Ja	Ja	Ikke påvirket	Lettet	Sårbar	Laveste prioritet	Ikke påvirket	Sårbar	Ja
	27–33 ESR 31.0–31.2			Ingen	Aktiveret som standard	Ja	Ja	Ja	Ingen	Ja	Ja	Ja	Ikke påvirket	Lettet	Sårbar	Laveste prioritet	Ikke påvirket	Sårbar	Ja
	34, 35 ESR 31.3–31.7			Ingen	Deaktiveret som standard	Ja	Ja	Ja	Ingen	Ja	Ja	Ja	Ikke påvirket	Lettet	Lettet	Laveste prioritet	Ikke påvirket	Sårbar	Ja
	ESR 31.8			Ingen	Deaktiveret som standard	Ja	Ja	Ja	Ingen	Ja	Ja	Ja	Ikke påvirket	Lettet	Lettet	Laveste prioritet	Ikke påvirket	Lettet	Ja
	36–38 ESR 38,0			Ingen	Deaktiveret som standard	Ja	Ja	Ja	Ingen	Ja	Ja	Ja	Ikke påvirket	Lettet	Lettet	Kun som tilbagevenden	Ikke påvirket	Sårbar	Ja
	ESR 38,1–38,8			Ingen	Deaktiveret som standard	Ja	Ja	Ja	Ingen	Ja	Ja	Ja	Ikke påvirket	Lettet	Lettet	Kun som tilbagevenden	Ikke påvirket	Lettet	Ja
	39–43			Ingen	Ingen	Ja	Ja	Ja	Ingen	Ja	Ja	Ja	Ikke påvirket	Lettet	Ikke påvirket	Kun som tilbagevenden	Ikke påvirket	Lettet	Ja
	44–48 ESR 45			Ingen	Ingen	Ja	Ja	Ja	Ingen	Ja	Ja	Ja	Ikke påvirket	Lettet	Ikke påvirket	Deaktiveret som standard	Ikke påvirket	Lettet	Ja
	49–59 ESR 52			Ingen	Ingen	Ja	Ja	Ja	Deaktiveret som standard (udkast)	Ja	Ja	Ja	Ikke påvirket	Lettet	Ikke påvirket	Deaktiveret som standard	Ikke påvirket	Lettet	Ja
	60–62 ESR 60			Ingen	Ingen	Ja	Ja	Ja	Ja (kladdeversion)	Ja	Ja	Ja	Ikke påvirket	Lettet	Ikke påvirket	Deaktiveret som standard	Ikke påvirket	Lettet	Ja
	63–77 ESR 68			Ingen	Ingen	Ja	Ja	Ja	Ja	Ja	Ja	Ja	Ikke påvirket	Lettet	Ikke påvirket	Deaktiveret som standard	Ikke påvirket	Lettet	Ja
	78–92 ESR 78.0–78.14 ESR 91.0–91.1			Ingen	Ingen	Deaktiveret som standard	Deaktiveret som standard	Ja	Ja	Ja	Ja	Ja	Ikke påvirket	Lettet	Ikke påvirket	Deaktiveret som standard	Ikke påvirket	Lettet	Ja
	ESR 78,15 ESR 91,2	93
Browser	Version		Platforme	SSL 2.0 (usikker)	SSL 3.0 (usikker)	TLS 1.0 (udfaset)	TLS 1.1 (udfaset)	TLS 1.2	TLS 1.3	EV certifikat	SHA-2 certifikat	ECDSA certifikat	DYR	FORBRYDELSE	POODLE (SSLv3)	RC4	TOSSE	Logjam	Protokolvalg efter bruger
Microsoft Internet Explorer (1-10)	1.x		Windows 3.1 , 95 , NT , Mac OS 7 , 8	Ingen SSL/TLS -understøttelse
	2			Ja	Ingen	Ingen	Ingen	Ingen	Ingen	Ingen	Ingen	Ingen	Ingen SSL 3.0 eller TLS support			Sårbar	Sårbar	Sårbar	Ikke relevant
	3			Ja	Ja	Ingen	Ingen	Ingen	Ingen	Ingen	Ingen	Ingen	Sårbar	Ikke påvirket	Sårbar	Sårbar	Sårbar	Sårbar	Ukendt
	4 , 5 , 6		Windows 3.1 , 95 , 98 , NT , 2000 Mac OS 7.1 , 8 , X , Solaris , HP-UX	Aktiveret som standard	Aktiveret som standard	Deaktiveret som standard	Ingen	Ingen	Ingen	Ingen	Ingen	Ingen	Sårbar	Ikke påvirket	Sårbar	Sårbar	Sårbar	Sårbar	Ja
	6		Windows XP	Aktiveret som standard	Aktiveret som standard	Deaktiveret som standard	Ingen	Ingen	Ingen	Ingen	Ja	Ingen	Lettet	Ikke påvirket	Sårbar	Sårbar	Sårbar	Sårbar	Ja
	7 , 8			Deaktiveret som standard	Aktiveret som standard	Ja	Ingen	Ingen	Ingen	Ja	Ja	Ingen	Lettet	Ikke påvirket	Sårbar	Sårbar	Sårbar	Sårbar	Ja
	6		Server 2003	Aktiveret som standard	Aktiveret som standard	Deaktiveret som standard	Ingen	Ingen	Ingen	Ingen	Ja	Ingen	Lettet	Ikke påvirket	Sårbar	Sårbar	Lettet	Lettet	Ja
	7 , 8			Deaktiveret som standard	Aktiveret som standard	Ja	Ingen	Ingen	Ingen	Ja	Ja	Ingen	Lettet	Ikke påvirket	Sårbar	Sårbar	Lettet	Lettet	Ja
	7 , 8 , 9		Windows Vista	Deaktiveret som standard	Aktiveret som standard	Ja	Ingen	Ingen	Ingen	Ja	Ja	Ja	Lettet	Ikke påvirket	Sårbar	Sårbar	Lettet	Lettet	Ja
	7 , 8 , 9		Server 2008	Deaktiveret som standard	Aktiveret som standard	Ja	Deaktiveret som standard (KB4019276)	Deaktiveret som standard (KB4019276)	Ingen	Ja	Ja	Ja	Lettet	Ikke påvirket	Sårbar	Sårbar	Lettet	Lettet	Ja
	8 , 9 , 10		Windows 7 / 8 Server 2008 R2 / 2012	Deaktiveret som standard	Aktiveret som standard	Ja	Deaktiveret som standard	Deaktiveret som standard	Ingen	Ja	Ja	Ja	Lettet	Ikke påvirket	Sårbar	Laveste prioritet	Lettet	Lettet	Ja
Internet Explorer 11	11		Windows 7 Server 2008 R2	Deaktiveret som standard	Deaktiveret som standard	Ja	Ja	Ja	Ingen	Ja	Ja	Ja	Lettet	Ikke påvirket	Lettet	Deaktiveret som standard	Lettet	Lettet	Ja
	11		Windows 8.1	Deaktiveret som standard	Deaktiveret som standard	Ja	Ja	Ja	Ingen	Ja	Ja	Ja	Lettet	Ikke påvirket	Lettet	Deaktiveret som standard	Lettet	Lettet	Ja
			Server 2012 Server 2012 R2
Browser	Version		Platforme	SSL 2.0 (usikker)	SSL 3.0 (usikker)	TLS 1.0 (udfaset)	TLS 1.1 (udfaset)	TLS 1.2	TLS 1.3	EV certifikat	SHA-2 certifikat	ECDSA certifikat	DYR	FORBRYDELSE	POODLE (SSLv3)	RC4	TOSSE	Logjam	Protokolvalg efter bruger
Microsoft Edge (12–18) (EdgeHTML-baseret) kun Internet Explorer 11	11	12–13	Windows 10 1507–1511	Deaktiveret som standard	Deaktiveret som standard	Ja	Ja	Ja	Ingen	Ja	Ja	Ja	Lettet	Ikke påvirket	Lettet	Deaktiveret som standard	Lettet	Lettet	Ja
	11	14–18 (kun klient)	Windows 10 1607–1909 Windows Server (SAC) 1709–1909	Ingen	Deaktiveret som standard	Ja	Ja	Ja	Ingen	Ja	Ja	Ja	Lettet	Ikke påvirket	Lettet	Deaktiveret som standard	Lettet	Lettet	Ja
	11	18 (kun klient)	Windows 10 2004 Windows Server (SAC) 2004	Ingen	Deaktiveret som standard	Ja	Ja	Ja	Ingen	Ja	Ja	Ja	Lettet	Ikke påvirket	Lettet	Deaktiveret som standard	Lettet	Lettet	Ja
Internet Explorer 11	11		Windows 10 20H2 Windows Server (SAC) 20H2	Ingen	Deaktiveret som standard	Ja	Ja	Ja	Ingen	Ja	Ja	Ja	Lettet	Ikke påvirket	Lettet	Deaktiveret som standard	Lettet	Lettet	Ja
	11		Windows 10 21H1	Ingen	Deaktiveret som standard	Ja	Ja	Ja	Ingen	Ja	Ja	Ja	Lettet	Ikke påvirket	Lettet	Deaktiveret som standard	Lettet	Lettet	Ja
	11		Windows 10 21H2	Ingen	Deaktiveret som standard	Ja	Ja	Ja	Ingen	Ja	Ja	Ja	Lettet	Ikke påvirket	Lettet	Deaktiveret som standard	Lettet	Lettet	Ja
	11		Windows 11	Ingen	Deaktiveret som standard	Ja	Ja	Ja	Ja	Ja	Ja	Ja	Lettet	Ikke påvirket	Lettet	Deaktiveret som standard	Lettet	Lettet	Ja
Internet Explorer 11 LTSC -versioner	11		Windows 10 LTSB 2015 (1507)	Deaktiveret som standard	Deaktiveret som standard	Ja	Ja	Ja	Ingen	Ja	Ja	Ja	Lettet	Ikke påvirket	Lettet	Deaktiveret som standard	Lettet	Lettet	Ja
	11		Windows 10 LTSB 2016 (1607)	Ingen	Deaktiveret som standard	Ja	Ja	Ja	Ingen	Ja	Ja	Ja	Lettet	Ikke påvirket	Lettet	Deaktiveret som standard	Lettet	Lettet	Ja
	11		Windows Server 2016 (LTSB / 1607)	Ingen	Deaktiveret som standard	Ja	Ja	Ja	Ingen	Ja	Ja	Ja	Lettet	Ikke påvirket	Lettet	Deaktiveret som standard	Lettet	Lettet	Ja
	11		Windows 10 LTSC 2019 (1809) Windows Server 2019 (LTSC / 1809)	Ingen	Deaktiveret som standard	Ja	Ja	Ja	Ingen	Ja	Ja	Ja	Lettet	Ikke påvirket	Lettet	Deaktiveret som standard	Lettet	Lettet	Ja
	11		Windows 10 LTSC 2022 (21H2)	Ingen	Deaktiveret som standard	Ja	Ja	Ja	Ingen	Ja	Ja	Ja	Lettet	Ikke påvirket	Lettet	Deaktiveret som standard	Lettet	Lettet	Ja
	11		Windows Server 2022 (LTSC / 21H2)	Ingen	Deaktiveret som standard	Ja	Ja	Ja	Ja	Ja	Ja	Ja	Lettet	Ikke påvirket	Lettet	Deaktiveret som standard	Lettet	Lettet	Ja
Browser	Version		Platforme	SSL 2.0 (usikker)	SSL 3.0 (usikker)	TLS 1.0 (udfaset)	TLS 1.1 (udfaset)	TLS 1.2	TLS 1.3	EV certifikat	SHA-2 certifikat	ECDSA certifikat	DYR	FORBRYDELSE	POODLE (SSLv3)	RC4	TOSSE	Logjam	Protokolvalg efter bruger
Microsoft Internet Explorer Mobile	7, 9		Windows Phone 7, 7.5, 7.8	Deaktiveret som standard	Aktiveret som standard	Ja	Ingen	Ingen	Ingen	Ingen	Ja	Ja	Ukendt	Ikke påvirket	Sårbar	Sårbar	Sårbar	Sårbar	Kun med tredjepartsværktøjer
	10		Windows Phone 8	Deaktiveret som standard	Aktiveret som standard	Ja	Deaktiveret som standard	Deaktiveret som standard	Ingen	Ingen	Ja	Ja	Lettet	Ikke påvirket	Sårbar	Sårbar	Sårbar	Sårbar	Kun med tredjepartsværktøjer
	11		Windows Phone 8.1	Deaktiveret som standard	Aktiveret som standard	Ja	Ja	Ja	Ingen	Ingen	Ja	Ja	Lettet	Ikke påvirket	Sårbar	Kun som tilbagevenden	Sårbar	Sårbar	Kun med tredjepartsværktøjer
Microsoft Edge (13–15) (EdgeHTML-baseret)	13		Windows 10 Mobile 1511	Deaktiveret som standard	Deaktiveret som standard	Ja	Ja	Ja	Ingen	Ja	Ja	Ja	Lettet	Ikke påvirket	Lettet	Deaktiveret som standard	Lettet	Lettet	Ingen
	14, 15		Windows 10 Mobile 1607–1709	Ingen	Deaktiveret som standard	Ja	Ja	Ja	Ingen	Ja	Ja	Ja	Lettet	Ikke påvirket	Lettet	Deaktiveret som standard	Lettet	Lettet	Ingen
Browser	Version		Platforme	SSL 2.0 (usikker)	SSL 3.0 (usikker)	TLS 1.0 (udfaset)	TLS 1.1 (udfaset)	TLS 1.2	TLS 1.3	EV certifikat	SHA-2 certifikat	ECDSA certifikat	DYR	FORBRYDELSE	POODLE (SSLv3)	RC4	TOSSE	Logjam	Protokolvalg efter bruger
Apple Safari	1		Mac OS X 10.2 , 10.3	Ingen	Ja	Ja	Ingen	Ingen	Ingen	Ingen	Ingen	Ingen	Sårbar	Ikke påvirket	Sårbar	Sårbar	Sårbar	Sårbar	Ingen
	2–5		Mac OS X 10.4 , 10.5 , Win XP	Ingen	Ja	Ja	Ingen	Ingen	Ingen	siden v3.2	Ingen	Ingen	Sårbar	Ikke påvirket	Sårbar	Sårbar	Sårbar	Sårbar	Ingen
	3–5		Vista , Win 7	Ingen	Ja	Ja	Ingen	Ingen	Ingen	siden v3.2	Ingen	Ja	Sårbar	Ikke påvirket	Sårbar	Sårbar	Sårbar	Sårbar	Ingen
	4–6		Mac OS X 10.6 , 10.7	Ingen	Ja	Ja	Ingen	Ingen	Ingen	Ja	Ja	Ja	Sårbar	Ikke påvirket	Sårbar	Sårbar	Sårbar	Sårbar	Ingen
	6		OS X 10.8	Ingen	Ja	Ja	Ingen	Ingen	Ingen	Ja	Ja	Ja	Lettet	Ikke påvirket	Lettet	Sårbar	Lettet	Sårbar	Ingen
	7, 9		OS X 10.9	Ingen	Ja	Ja	Ja	Ja	Ingen	Ja	Ja	Ja	Lettet	Ikke påvirket	Lettet	Sårbar	Lettet	Sårbar	Ingen
	8–10		OS X 10.10	Ingen	Ja	Ja	Ja	Ja	Ingen	Ja	Ja	Ja	Lettet	Ikke påvirket	Lettet	Laveste prioritet	Lettet	Lettet	Ingen
	9–11		OS X 10.11	Ingen	Ingen	Ja	Ja	Ja	Ingen	Ja	Ja	Ja	Lettet	Ikke påvirket	Ikke påvirket	Laveste prioritet	Lettet	Lettet	Ingen
	10–13		macOS 10.12 , 10.13	Ingen	Ingen	Ja	Ja	Ja	Ingen	Ja	Ja	Ja	Lettet	Ikke påvirket	Ikke påvirket	Deaktiveret som standard	Lettet	Lettet	Ingen
	12, 13	14	macOS 10.14	Ingen	Ingen	Ja	Ja	Ja	Ja (siden macOS 10.14.4)	Ja	Ja	Ja	Lettet	Ikke påvirket	Ikke påvirket	Deaktiveret som standard	Lettet	Lettet	Ingen
	13, 14	15	macOS 10.15	Ingen	Ingen	Ja	Ja	Ja	Ja	Ja	Ja	Ja	Lettet	Ikke påvirket	Ikke påvirket	Deaktiveret som standard	Lettet	Lettet	Ingen
	14	15	macOS 11	Ingen	Ingen	Ja	Ja	Ja	Ja	Ja	Ja	Ja	Lettet	Ikke påvirket	Ikke påvirket	Deaktiveret som standard	Lettet	Lettet	Ingen
	15		macOS 12	Ingen	Ingen	Ja	Ja	Ja	Ja	Ja	Ja	Ja	Lettet	Ikke påvirket	Ikke påvirket	Deaktiveret som standard	Lettet	Lettet	Ingen
Browser	Version		Platforme	SSL 2.0 (usikker)	SSL 3.0 (usikker)	TLS 1.0 (udfaset)	TLS 1.1 (udfaset)	TLS 1.2	TLS 1.3	EV certifikat	SHA-2 certifikat	ECDSA certifikat	DYR	FORBRYDELSE	POODLE (SSLv3)	RC4	TOSSE	Logjam	Protokolvalg efter bruger
Apple Safari (mobil)	3		iPhone OS 1 , 2	Ingen	Ja	Ja	Ingen	Ingen	Ingen	Ingen	Ingen	Ingen	Sårbar	Ikke påvirket	Sårbar	Sårbar	Sårbar	Sårbar	Ingen
	4, 5		iPhone OS 3 , iOS 4	Ingen	Ja	Ja	Ingen	Ingen	Ingen	Ja	Ja	siden iOS 4	Sårbar	Ikke påvirket	Sårbar	Sårbar	Sårbar	Sårbar	Ingen
	5, 6		iOS 5 , 6	Ingen	Ja	Ja	Ja	Ja	Ingen	Ja	Ja	Ja	Sårbar	Ikke påvirket	Sårbar	Sårbar	Sårbar	Sårbar	Ingen
	7		iOS 7	Ingen	Ja	Ja	Ja	Ja	Ingen	Ja	Ja	Ja	Lettet	Ikke påvirket	Sårbar	Sårbar	Sårbar	Sårbar	Ingen
	8		iOS 8	Ingen	Ja	Ja	Ja	Ja	Ingen	Ja	Ja	Ja	Lettet	Ikke påvirket	Lettet	Laveste prioritet	Lettet	Lettet	Ingen
	9		iOS 9	Ingen	Ingen	Ja	Ja	Ja	Ingen	Ja	Ja	Ja	Lettet	Ikke påvirket	Ikke påvirket	Laveste prioritet	Lettet	Lettet	Ingen
	10, 11		iOS 10 , 11	Ingen	Ingen	Ja	Ja	Ja	Ingen	Ja	Ja	Ja	Lettet	Ikke påvirket	Ikke påvirket	Deaktiveret som standard	Lettet	Lettet	Ingen
	12		iOS 12	Ingen	Ingen	Ja	Ja	Ja	Ja (siden iOS 12.2)	Ja	Ja	Ja	Lettet	Ikke påvirket	Ikke påvirket	Deaktiveret som standard	Lettet	Lettet	Ingen
	13, 14		iOS 13 , 14	Ingen	Ingen	Ja	Ja	Ja	Ja	Ja	Ja	Ja	Lettet	Ikke påvirket	Ikke påvirket	Deaktiveret som standard	Lettet	Lettet	Ingen
			iPadOS 13, 14
	15		iOS 15	Ingen	Ingen	Ja	Ja	Ja	Ja	Ja	Ja	Ja	Lettet	Ikke påvirket	Ikke påvirket	Deaktiveret som standard	Lettet	Lettet	Ingen
			iPadOS 15
Browser	Version		Platforme	SSL 2.0 (usikker)	SSL 3.0 (usikker)	TLS 1.0 (udfaset)	TLS 1.1 (udfaset)	TLS 1.2	TLS 1.3	EV	SHA-2	ECDSA	DYR	FORBRYDELSE	POODLE (SSLv3)	RC4	TOSSE	Logjam	Protokolvalg efter bruger
Google Android OS	Android 1.0–4.0.4			Ingen	Aktiveret som standard	Ja	Ingen	Ingen	Ingen	Ukendt	Ja	siden 3.0	Ukendt	Ukendt	Sårbar	Sårbar	Sårbar	Sårbar	Ingen
	Android 4.1–4.4.4			Ingen	Aktiveret som standard	Ja	Deaktiveret som standard	Deaktiveret som standard	Ingen	Ukendt	Ja	Ja	Ukendt	Ukendt	Sårbar	Sårbar	Sårbar	Sårbar	Ingen
	Android 5.0–5.0.2			Ingen	Aktiveret som standard	Ja	Ja	Ja	Ingen	Ukendt	Ja	Ja	Ukendt	Ukendt	Sårbar	Sårbar	Sårbar	Sårbar	Ingen
	Android 5.1–5.1.1			Ingen	Deaktiveret som standard	Ja	Ja	Ja	Ingen	Ukendt	Ja	Ja	Ukendt	Ukendt	Ikke påvirket	Kun som tilbagevenden	Lettet	Lettet	Ingen
	Android 6.0 - 7.1.2			Ingen	Deaktiveret som standard	Ja	Ja	Ja	Ingen	Ukendt	Ja	Ja	Ukendt	Ukendt	Ikke påvirket	Deaktiveret som standard	Lettet	Lettet	Ingen
	Android 8.0			Ingen	Ingen	Ja	Ja	Ja	Ingen	Ukendt	Ja	Ja	Ukendt	Ukendt	Ikke påvirket	Deaktiveret som standard	Lettet	Lettet	Ingen
	Android 8.1 - 9			Ingen	Ingen	Ja	Ja	Ja	Ingen	Ukendt	Ja	Ja	Ukendt	Ukendt	Ikke påvirket	Deaktiveret som standard	Lettet	Lettet	Ingen
	Android 10			Ingen	Ingen	Ja	Ja	Ja	Ja	Ukendt	Ja	Ja	Ukendt	Ukendt	Ikke påvirket	Deaktiveret som standard	Lettet	Lettet	Ingen
	Android 11			Ingen	Ingen	Ja	Ja	Ja	Ja	Ukendt	Ja	Ja	Ukendt	Ukendt	Ikke påvirket	Deaktiveret som standard	Lettet	Lettet	Ingen
	Android 12			Ingen	Ingen	Ukendt	Ukendt	Ja	Ja	Ukendt	Ja	Ja	Ukendt	Ukendt	Ikke påvirket	Deaktiveret som standard	Lettet	Lettet	Ingen
Browser	Version		Platforme	SSL 2.0 (usikker)	SSL 3.0 (usikker)	TLS 1.0 (udfaset)	TLS 1.1 (udfaset)	TLS 1.2	TLS 1.3	EV certifikat	SHA-2 certifikat	ECDSA certifikat	DYR	FORBRYDELSE	POODLE (SSLv3)	RC4	TOSSE	Logjam	Protokolvalg efter bruger

Farve eller note		Betydning
Browserversion	Platform
Browserversion	Operativ system	Fremtidig udgivelse; under udvikling
Browserversion	Operativ system	Aktuel seneste udgivelse
Browserversion	Operativ system	Tidligere udgivelse; stadig understøttet
Browserversion	Operativ system	Tidligere udgivelse; langsigtet støtte stadig aktiv, men slutter om mindre end 12 måneder
Browserversion	Operativ system	Tidligere udgivelse; understøttes ikke længere
n/a	Operativ system	Blandet / uspecificeret
	Operativsystem (version+)	Minimum påkrævet operativsystemversion (for understøttede versioner af browseren)
	Operativ system	Understøttes ikke længere for dette operativsystem

Noter

Biblioteker

De fleste SSL- og TLS -programmeringsbiblioteker er gratis og open source -software .

• BoringSSL , en gaffel med OpenSSL til Chrome/Chromium og Android samt andre Google -applikationer.
• Botan , et BSD-licenseret kryptografisk bibliotek skrevet i C ++.
• BSAFE Micro Edition Suite: en multi-platform implementering af TLS skrevet i C ved hjælp af et FIPS-valideret kryptografisk modul
• BSAFE SSL-J: et TLS-bibliotek, der leverer både en proprietær API og JSSE API, ved hjælp af FIPS-valideret kryptografisk modul
• cryptlib : et bærbart open source -kryptografibibliotek (inkluderer TLS/SSL -implementering)
• Delphi -programmører kan bruge et bibliotek kaldet Indy, der bruger OpenSSL eller alternativt ICS, der understøtter TLS 1.3 nu.
• GnuTLS : en gratis implementering (LGPL -licenseret )
• Java Secure Socket Extension : en Java -implementering inkluderet i Java Runtime Environment understøttet TLS 1.1 og 1.2, der starter med Java 7. (TLS 1.1/1.2 blev oprindeligt deaktiveret som standard for klient på Java 7, men blev aktiveret i januar 2017.) Java 11 understøtter TLS 1.3.
• LibreSSL : en gaffel med OpenSSL af OpenBSD -projektet.
• MatrixSSL : en dobbelt licenseret implementering
• mbed TLS (tidligere PolarSSL): En lille SSL -bibliotekimplementering til integrerede enheder, der er designet til brugervenlighed
• Netværkssikkerhedstjenester : FIPS 140 valideret open source -bibliotek
• OpenSSL : en gratis implementering (BSD -licens med nogle udvidelser)
• SChannel : en implementering af SSL og TLS Microsoft Windows som en del af pakken.
• Sikker transport : en implementering af SSL og TLS, der bruges i OS X og iOS som en del af deres pakker.
• wolfSSL (tidligere CyaSSL): Indlejret SSL/TLS -bibliotek med stort fokus på hastighed og størrelse.

Biblioteksunderstøttelse af TLS/SSL

Implementering	SSL 2.0 (usikker)	SSL 3.0 (usikker)	TLS 1.0	TLS 1.1	TLS 1.2	TLS 1.3
Botan	Ingen	Ingen	Ja	Ja	Ja
BSAFE Micro Edition Suite	Ingen	Deaktiveret som standard	Ja	Ja	Ja	Under udvikling
BSAFE SSL-J	Ingen	Deaktiveret som standard	Ja	Ja	Ja	Ja
cryptlib	Ingen	Deaktiveret som standard på kompileringstidspunktet	Ja	Ja	Ja
GnuTLS	Ingen	Deaktiveret som standard	Ja	Ja	Ja	Ja
Java Secure Socket -udvidelse	Ingen	Deaktiveret som standard	Ja	Ja	Ja	Ja
LibreSSL	Ingen	Ingen	Ja	Ja	Ja	Fra version 3.2.2
MatrixSSL	Ingen	Deaktiveret som standard på kompileringstidspunktet	Ja	Ja	Ja	ja (udkast til version)
mbed TLS (tidligere PolarSSL)	Ingen	Deaktiveret som standard	Ja	Ja	Ja
Netværkssikkerhedstjenester	Ingen	Deaktiveret som standard	Ja	Ja	Ja	Ja
OpenSSL	Ingen	Aktiveret som standard	Ja	Ja	Ja	Ja
SCanal XP / 2003	Deaktiveret som standard af MSIE 7	Aktiveret som standard	Aktiveret som standard af MSIE 7	Ingen	Ingen	Ingen
SCanal Vista	Deaktiveret som standard	Aktiveret som standard	Ja	Ingen	Ingen	Ingen
SCanal 2008	Deaktiveret som standard	Aktiveret som standard	Ja	Deaktiveret som standard (KB4019276)	Deaktiveret som standard (KB4019276)	Ingen
SCanal 7/2008 R2	Deaktiveret som standard	Deaktiveret som standard i MSIE 11	Ja	Aktiveret som standard af MSIE 11	Aktiveret som standard af MSIE 11	Ingen
SCanal 8/2012	Deaktiveret som standard	Aktiveret som standard	Ja	Deaktiveret som standard	Deaktiveret som standard	Ingen
SCanal 8.1 / 2012 R2, 10 v1507 og v1511	Deaktiveret som standard	Deaktiveret som standard i MSIE 11	Ja	Ja	Ja	Ingen
SCanal 10 v1607 / 2016	Ingen	Deaktiveret som standard	Ja	Ja	Ja	Ingen
SCanal 10 v1903	Ingen	Deaktiveret som standard	Ja	Ja	Ja	Ingen
SCanal 10 v21H1	Ingen	Deaktiveret som standard	Ja	Ja	Ja	Ingen
Secure Transport OS X 10.2–10.8 / iOS 1-4	Ja	Ja	Ja	Ingen	Ingen
Secure Transport OS X 10.9–10.10 / iOS 5–8	Ingen	Ja	Ja	Ja	Ja
Secure Transport OS X 10.11 / iOS 9	Ingen	Ingen	Ja	Ja	Ja
Seed7 TLS/SSL -bibliotek	Ingen	Ja	Ja	Ja	Ja
wolfSSL (tidligere CyaSSL)	Ingen	Deaktiveret som standard	Ja	Ja	Ja	Ja
Implementering	SSL 2.0 (usikker)	SSL 3.0 (usikker)	TLS 1.0	TLS 1.1	TLS 1.2	TLS 1.3

Et papir fremlagt på ACM -konferencen 2012 om computer- og kommunikationssikkerhed viste, at få applikationer brugte nogle af disse SSL -biblioteker korrekt, hvilket førte til sårbarheder. Ifølge forfatterne

"hovedårsagen til de fleste af disse sårbarheder er det forfærdelige design af API'erne til de underliggende SSL-biblioteker. I stedet for at udtrykke sikkerhedsegenskaber på højt niveau for netværkstunneler som fortrolighed og godkendelse, afslører disse API'er detaljer på lavt niveau i SSL-protokollen til applikationsudviklere. Som en konsekvens bruger udviklere ofte SSL -API'er forkert, forkertolker og misforstår deres mangfoldige parametre, muligheder, bivirkninger og returneringsværdier. "

Andre anvendelser

Den Simple Mail Transfer Protocol (SMTP) kan også være beskyttet af TLS. Disse applikationer bruger offentlige nøglecertifikater til at verificere identiteten af ​​slutpunkter.

TLS kan også bruges til at tunnelere en hel netværksstabel til at oprette en VPN , hvilket er tilfældet med OpenVPN og OpenConnect . Mange leverandører har nu giftet sig med TLS's krypterings- og godkendelsesfunktioner med autorisation. Der er også sket en betydelig udvikling siden slutningen af ​​1990'erne med at skabe klientteknologi uden for webbrowsere for at muliggøre support til klient/server-applikationer. Sammenlignet med traditionelle IPsec VPN-teknologier har TLS nogle iboende fordele i firewall og NAT- traversal, der gør det lettere at administrere for store fjernadgangspopulationer.

TLS er også en standardmetode til beskyttelse af Session -initieringsprotokol (SIP) applikationssignalering. TLS kan bruges til at levere godkendelse og kryptering af SIP-signalering forbundet med VoIP og andre SIP-baserede applikationer.

Sikkerhed

Angreb mod TLS/SSL

Væsentlige angreb mod TLS/SSL er angivet nedenfor.

I februar 2015 udsendte IETF en informativ RFC, der opsummerede de forskellige kendte angreb mod TLS/SSL.

Genforhandlingsangreb

Der blev opdaget en sårbarhed ved genforhandlingsproceduren i august 2009, der kan føre til klartekstindsprøjtningsangreb mod SSL 3.0 og alle nuværende versioner af TLS. For eksempel tillader det en angriber, der kan kapre en https -forbindelse, at splejse deres egne anmodninger ind i begyndelsen af ​​den samtale, som klienten har med webserveren. Angriberen kan faktisk ikke dekryptere klient-server-kommunikationen, så den adskiller sig fra et typisk mand-i-midten-angreb. En kortsigtet løsning er, at webservere stopper med at tillade genforhandling, hvilket typisk ikke kræver andre ændringer, medmindre klientcertifikatgodkendelse bruges. For at løse sårbarheden blev der foreslået en genforhandlingsindikationsudvidelse til TLS. Det vil kræve, at klienten og serveren inkluderer og verificerer oplysninger om tidligere håndtryk i alle genforhandlingshåndtryk. Denne udvidelse er blevet en foreslået standard og har fået nummeret RFC  5746 . RFC er blevet implementeret af flere biblioteker.

Nedgrader angreb: FREAK angreb og Logjam angreb

Et protokol -nedgraderingsangreb (også kaldet et version rollback -angreb) lurer en webserver til at forhandle forbindelser med tidligere versioner af TLS (f.eks. SSLv2), der for længst er blevet opgivet som usikre.

Tidligere ændringer af de originale protokoller, f.eks. Falsk start (vedtaget og aktiveret af Google Chrome) eller Snap Start , indførte angiveligt begrænsede nedgraderingsangreb for TLS -protokoller eller tillod ændringer af chifferpakken, der blev sendt af klienten til serveren. Ved at gøre det kan en angriber have succes med at påvirke valget af chifferpakker i et forsøg på at nedgradere chifferpakken, der forhandles om at bruge enten en svagere symmetrisk krypteringsalgoritme eller en svagere nøgleudveksling. Et papir fremlagt på en ACM -konference om computer- og kommunikationssikkerhed i 2012 viste, at udvidelsen False Start var i fare: under visse omstændigheder kunne det gøre det muligt for en angriber at gendanne krypteringsnøglerne offline og få adgang til de krypterede data.

Krypteringsnedgraderingsangreb kan tvinge servere og klienter til at forhandle om en forbindelse ved hjælp af kryptografisk svage nøgler. I 2014 blev der opdaget et man-in-the-middle- angreb kaldet FREAK, der påvirker OpenSSL- stakken, standard Android -webbrowseren og nogle Safari- browsere. Angrebet involverede at narre servere til at forhandle om en TLS -forbindelse ved hjælp af kryptografisk svage 512 bit krypteringsnøgler.

Logjam er en sikkerhedsudnyttelse, der blev opdaget i maj 2015, og som udnytter muligheden for at bruge ældre 512-bit Diffie-Hellman- grupper fra "eksportkvalitet" , der går tilbage til 1990'erne. Det tvinger modtagelige servere til at nedgradere til kryptografisk svage 512-bit Diffie-Hellman-grupper. En angriber kan derefter udlede nøglerne, som klienten og serveren bestemmer ved hjælp af Diffie - Hellman -nøgleudvekslingen .

Cross-protocol angreb: DROWN

Den drukner angreb er en udnytte, der angriber servere understøtter moderne SSL / TLS-protokollen suiter ved at udnytte deres støtte til den forældede, usikker, at SSLv2 protokol udnytte et angreb på forbindelser ved hjælp af up-to-date protokoller, der ellers ville være sikker. DROWN udnytter en sårbarhed i de anvendte protokoller og konfigurationen af ​​serveren frem for en specifik implementeringsfejl. Fuldstændige detaljer om DROWN blev annonceret i marts 2016 sammen med en patch til udnyttelsen. På det tidspunkt var mere end 81.000 af de 1 million mest populære websteder blandt de TLS -beskyttede websteder, der var sårbare over for DROWN -angrebet.

BEAST angreb

Den 23. september 2011 demonstrerede forskere Thai Duong og Juliano Rizzo et bevis på konceptet kaldet BEAST ( Browser Exploit Against SSL/TLS ) ved hjælp af en Java-applet til at overtræde de samme oprindelsespolitiske begrænsninger for en længe kendt cipher block chaining (CBC) sårbarhed i TLS 1.0: en angriber, der observerer 2 på hinanden følgende chiffertekstblokke C0, C1 kan teste, om klartekstblokken P1 er lig med x ved at vælge den næste klartekstblok P2 = x C0 C1; i henhold til CBC -drift, C2 = E (C1 P2) = E (C1 x C0 C1) = E (C0 x), hvilket vil være lig med C1, hvis x = P1. Praktiske bedrifter var ikke tidligere blevet demonstreret for denne sårbarhed , som oprindeligt blev opdaget af Phillip Rogaway i 2002. Angrebetes sårbarhed var blevet rettet med TLS 1.1 i 2006, men TLS 1.1 havde ikke oplevet bred accept før denne angrebsdemonstration. ${\ displaystyle \ oplus}$${\ displaystyle \ oplus}$${\ displaystyle \ oplus}$${\ displaystyle \ oplus}$${\ displaystyle \ oplus}$${\ displaystyle \ oplus}$${\ displaystyle \ oplus}$

RC4 som en strømciffer er immun mod BEAST -angreb. Derfor blev RC4 i vid udstrækning brugt som en måde at afbøde BEAST -angreb på serversiden. I 2013 fandt forskerne imidlertid flere svagheder i RC4. Derefter blev aktivering af RC4 på serversiden ikke længere anbefalet.

Chrome og Firefox selv er ikke sårbare over for BEAST-angreb, men Mozilla opdaterede deres NSS- biblioteker for at afbøde BEAST-lignende angreb . NSS bruges af Mozilla Firefox og Google Chrome til at implementere SSL. Nogle webservere, der har en brudt implementering af SSL -specifikationen, kan stoppe med at fungere som følge heraf.

Microsoft udgav Security Bulletin MS12-006 den 10. januar 2012, som fikset BEAST-sårbarheden ved at ændre den måde, hvorpå Windows Secure Channel ( SChannel ) -komponenten sender krypterede netværkspakker fra serverenden. Brugere af Internet Explorer (før version 11), der kører på ældre versioner af Windows ( Windows 7 , Windows 8 og Windows Server 2008 R2 ) kan begrænse brugen af ​​TLS til 1.1 eller højere.

Apple rettede BEAST-sårbarheden ved at implementere 1/n-1-split og tænde det som standard i OS X Mavericks , udgivet den 22. oktober 2013.

Kriminalitet og overfald

Forfatterne til BEAST -angrebet er også skaberne af det senere CRIME -angreb, som kan give en angriber mulighed for at gendanne indholdet af webcookies, når datakomprimering bruges sammen med TLS. Når det bruges til at gendanne indholdet af hemmelige godkendelsescookies , giver det en angriber mulighed for at udføre sessionskapring på en godkendt websession.

Mens CRIME-angrebet blev præsenteret som et generelt angreb, der effektivt kunne fungere mod et stort antal protokoller, herunder men ikke begrænset til TLS, og applikationslagsprotokoller som SPDY eller HTTP , blev kun udnyttelser mod TLS og SPDY demonstreret og stort set afbødet i browsere og servere. CRIME -udnyttelsen mod HTTP -komprimering er slet ikke blevet reduceret, selvom forfatterne af CRIME har advaret om, at denne sårbarhed kan være endnu mere udbredt end SPDY- og TLS -komprimering tilsammen. I 2013 blev en ny forekomst af CRIME -angrebet mod HTTP -komprimering, kaldet BREACH , annonceret. Baseret på CRIME -angrebet kan et BREACH -angreb udtrække login -tokens, e -mail -adresser eller andre følsomme oplysninger fra TLS -krypteret webtrafik på så lidt som 30 sekunder (afhængigt af antallet af bytes, der skal udtrækkes), forudsat at angriberen narrer offeret til at besøge et ondsindet weblink eller kan injicere indhold på gyldige sider, som brugeren besøger (f.eks. et trådløst netværk under angriberens kontrol). Alle versioner af TLS og SSL er i fare for BREACH uanset hvilken krypteringsalgoritme eller kryptering der bruges. I modsætning til tidligere tilfælde af CRIME, som med succes kan forsvares ved at slukke TLS -komprimering eller SPDY -headerkomprimering, udnytter BREACH HTTP -komprimering, som ikke realistisk kan slukkes, da stort set alle webservere er afhængige af det for at forbedre datatransmissionshastigheder for brugerne. Dette er en kendt begrænsning af TLS, da den er modtagelig for valgt klartekstangreb mod de applikationslagsdata, den skulle beskytte.

Timing angreb på polstring

Tidligere TLS -versioner var sårbare over for det polstrede orakelangreb, der blev opdaget i 2002. En ny variant, kaldet Lucky Thirteen -angrebet , blev udgivet i 2013.

Nogle eksperter anbefalede også at undgå Triple-DES CBC. Da de sidste understøttede chiffer udviklet til at understøtte ethvert program, der bruger Windows XPs SSL/TLS-bibliotek som Internet Explorer på Windows XP, er RC4 og Triple-DES, og da RC4 nu er forældet (se diskussion af RC4-angreb ), gør det det svært at understøtte enhver version af SSL til ethvert program, der bruger dette bibliotek på XP.

En rettelse blev frigivet som Encrypt-then-MAC-udvidelsen til TLS-specifikationen, udgivet som RFC  7366 . Lucky Thirteen -angrebet kan reduceres i TLS 1.2 ved kun at bruge AES_GCM -chiffer; AES_CBC er fortsat sårbar.

PUDEL angreb

Den 14. oktober 2014 offentliggjorde Google -forskere en sårbarhed i designet af SSL 3.0, hvilket gør CBC -funktionsmåde med SSL 3.0 sårbar over for et polstringsangreb ( CVE - 2014-3566 ). De navngav dette angreb POODLE ( Padding Oracle On Downgraded Legacy Encryption ). I gennemsnit behøver angribere kun at foretage 256 SSL 3.0 -anmodninger for at afsløre en byte krypterede meddelelser.

Selvom denne sårbarhed kun findes i SSL 3.0, og de fleste klienter og servere understøtter TLS 1.0 og nyere, nedgraderer alle større browsere frivilligt til SSL 3.0, hvis håndtryk med nyere versioner af TLS mislykkes, medmindre de giver en bruger eller administrator mulighed for at deaktivere SSL 3.0 og brugeren eller administratoren gør det. Derfor kan manden i midten først foretage et version-tilbagefaldsangreb og derefter udnytte denne sårbarhed.

Den 8. december 2014 blev en variant af POODLE annonceret, der påvirker TLS -implementeringer, der ikke korrekt håndhæver padding -byte -krav.

RC4 angreb

På trods af eksistensen af ​​angreb på RC4, der ødelagde dens sikkerhed, blev chiffer -suiter i SSL og TLS, der var baseret på RC4, stadig betragtet som sikre før 2013 baseret på den måde, de blev brugt i SSL og TLS. I 2011 blev RC4 -pakken faktisk anbefalet som en løsning til BEAST -angrebet . Nye former for angreb, der blev afsløret i marts 2013, viste endegyldigt, at det var muligt at bryde RC4 i TLS, hvilket tyder på, at det ikke var en god løsning for BEAST. Et angrebsscenario blev foreslået af AlFardan, Bernstein, Paterson, Poettering og Schuldt, der brugte nyopdagede statistiske forspændinger i RC4 -nøgletabellen til at gendanne dele af klarteksten med et stort antal TLS -krypteringer. Et angreb på RC4 i TLS og SSL, der kræver 13 × 2 ²⁰ krypteringer for at bryde RC4, blev afsløret den 8. juli 2013 og blev senere beskrevet som "gennemførligt" i den ledsagende præsentation på et USENIX Security Symposium i august 2013. I juli 2015, efterfølgende forbedringer i angrebet gør det stadig mere praktisk at besejre sikkerheden ved RC4-krypteret TLS.

Da mange moderne browsere er designet til at besejre BEAST -angreb (undtagen Safari til Mac OS X 10.7 eller tidligere, til iOS 6 eller tidligere og til Windows; se § Webbrowsere ), er RC4 ikke længere et godt valg for TLS 1.0. CBC -chifferne, der tidligere var påvirket af BEAST -angrebet, er blevet et mere populært valg for beskyttelse. Mozilla og Microsoft anbefaler at deaktivere RC4, hvor det er muligt. RFC  7465 forbyder brug af RC4 -chiffer -suiter i alle versioner af TLS.

Den 1. september 2015 annoncerede Microsoft, Google og Mozilla, at RC4 -chiffer -suiter som standard ville blive deaktiveret i deres browsere ( Microsoft Edge , Internet Explorer 11 på Windows 7/8.1/10, Firefox og Chrome ) i begyndelsen af ​​2016.

Afkortningsangreb

Et TLS (logout) trunkeringsangreb blokerer for et offers logout -anmodninger om en konto, så brugeren ubevidst forbliver logget ind på en webtjeneste. Når anmodningen om at logge ud sendes, injicerer angriberen en ukrypteret TCP FIN -meddelelse (ikke flere data fra afsenderen) for at lukke forbindelsen. Serveren modtager derfor ikke logout -anmodningen og er ikke klar over den unormale afslutning.

Angrebet blev offentliggjort i juli 2013 og får webtjenester som Gmail og Hotmail til at vise en side, der informerer brugeren om, at de er logget ud, samtidig med at det sikres, at brugerens browser opretholder autorisation til tjenesten, hvilket giver en angriber mulighed for efterfølgende adgang til browseren for at få adgang til og overtage kontrollen over brugerens loggede konto. Angrebet er ikke afhængigt af installation af malware på offerets computer; angribere behøver kun at placere sig selv mellem offeret og webserveren (f.eks. ved at oprette et useriøst trådløst hotspot). Denne sårbarhed kræver også adgang til offerets computer. En anden mulighed er, at når man bruger FTP, kan dataforbindelsen have en falsk FIN i datastrømmen, og hvis protokolreglerne for udveksling af close_notify -advarsler ikke overholdes, kan en fil afkortes.

Uhellig PAC -angreb

Dette angreb, der blev opdaget i midten af ​​2016, udnytter svagheder i Web Proxy Autodiscovery Protocol (WPAD) til at afsløre webadressen, som en webbruger forsøger at nå via et TLS-aktiveret weblink. Videregivelse af en URL kan krænke en brugers privatliv, ikke kun på grund af det tilgængelige websted, men også fordi URL'er undertiden bruges til at godkende brugere. Dokumentdelingstjenester, f.eks. Dem, der tilbydes af Google og Dropbox, fungerer også ved at sende en bruger et sikkerhedstoken, der er inkluderet i webadressen. En angriber, der får sådanne webadresser, kan muligvis få fuld adgang til et ofres konto eller data.

Udnyttelsen virker mod næsten alle browsere og operativsystemer.

Sweet32 angreb

Sweet32-angrebet bryder alle 64-bit blokchiffer, der bruges i CBC-tilstand som brugt i TLS, ved at udnytte et fødselsdagsangreb og enten et mand-i-midten-angreb eller indsprøjtning af et ondsindet JavaScript på en webside. Formålet med man-in-the-middle-angrebet eller JavaScript-injektionen er at give angriberen mulighed for at fange nok trafik til at montere et fødselsdagsangreb.

Implementeringsfejl: Heartbleed bug, BERserk angreb, Cloudflare bug

Den heartbleed-bug bug er en alvorlig sårbarhed bestemt til gennemførelsen af SSL / TLS i den populære OpenSSL kryptografisk software bibliotek, der påvirker versioner 1.0.1 til 1.0.1f. Denne svaghed, der blev rapporteret i april 2014, gør det muligt for angribere at stjæle private nøgler fra servere, der normalt bør beskyttes. Heartbleed -fejlen tillader alle på Internettet at læse hukommelsen til de systemer, der er beskyttet af de sårbare versioner af OpenSSL -softwaren. Dette kompromitterer de hemmelige private nøgler, der er knyttet til de offentlige certifikater, der bruges til at identificere tjenesteudbyderne og til at kryptere trafikken, brugernes navne og adgangskoder og det faktiske indhold. Dette gør det muligt for angriberne at aflytte kommunikation, stjæle data direkte fra tjenesterne og brugerne og efterligne tjenester og brugere. Sårbarheden skyldes en bufferoverlæsningsfejl i OpenSSL-softwaren frem for en defekt i SSL- eller TLS-protokollspecifikationen.

I september 2014 blev en variant af Daniel Bleichenbachers PKCS#1 v1.5 RSA Signature Forgery -sårbarhed annonceret af Intel Security Advanced Threat Research. Dette angreb, kaldet BERserk, er et resultat af ufuldstændig ASN.1-længde-afkodning af offentlige nøglesignaturer i nogle SSL-implementeringer og tillader et menneske-i-midten-angreb ved at forfalske en offentlig nøglesignatur.

I februar 2015, efter at medier rapporterede den skjulte forudinstallation af Superfish- adware på nogle Lenovo-notebooks, fandt en forsker et betroet rodcertifikat på berørte Lenovo-maskiner for at være usikkert, da nøglerne let kunne tilgås ved hjælp af firmanavnet, Komodia, som en adgangssætning. Komodia-biblioteket var designet til at opfange TLS/SSL-trafik på klientsiden til forældrekontrol og overvågning, men det blev også brugt i adskillige adware-programmer, herunder Superfish, der ofte blev installeret i hemmelighed uden for computeren. Til gengæld installerede disse potentielt uønskede programmer det korrupte rodcertifikat, så angribere helt kunne kontrollere webtrafik og bekræfte falske websteder som autentiske.

I maj 2016 blev det rapporteret, at snesevis af danske HTTPS-beskyttede websteder tilhørende Visa Inc. var sårbare over for angreb, der tillod hackere at injicere ondsindet kode og forfalsket indhold i besøgernes browsere. Angrebene fungerede, fordi TLS -implementeringen, der blev brugt på de berørte servere, forkert genbrugte tilfældige tal ( nonces ), der kun er beregnet til at blive brugt én gang, hvilket sikrer, at hvert TLS -håndtryk er unikt.

I februar 2017 skabte en implementeringsfejl forårsaget af et enkelt forkert indtastet tegn i kode, der blev brugt til at analysere HTML, en bufferoverløbsfejl på Cloudflare -servere. På samme måde som dens effekter til Heartbleed -bug opdaget i 2014, tillod denne overløbsfejl, almindeligt kendt som Cloudbleed , uautoriserede tredjeparter at læse data i hukommelsen til programmer, der kører på serverne - data, der ellers skulle have været beskyttet af TLS.

Undersøgelse af websteder, der er sårbare over for angreb

Fra juli 2021 estimerede Trustworthy Internet Movement forholdet mellem websteder, der er sårbare over for TLS -angreb.

Undersøgelse af TLS -sårbarhederne på de mest populære websteder

Angreb	Sikkerhed
	Usikker	Afhænger	Sikker	Andet
Genforhandlingsangreb	0,1% understøtter usikker genforhandling	<0,1% støtter begge dele	99,2% understøtter sikker genforhandling	0,7% ingen støtte
RC4 angreb	0,4% understøtter RC4 -suiter, der bruges med moderne browsere	6,5% understøtter nogle RC4 -suiter	93,1% ingen støtte	Ikke relevant
TLS -komprimering (CRIME -angreb)	> 0,0% sårbare	Ikke relevant	Ikke relevant	Ikke relevant
Heartbleed	> 0,0% sårbare	Ikke relevant	Ikke relevant	Ikke relevant
ChangeCipherSpec injektionsangreb	0,1% sårbare og udnyttelige	0,2% sårbar, ikke udnyttelig	98,5% ikke sårbare	1,2% ukendt
POODLE -angreb mod TLS (Original POODLE mod SSL 3.0 er ikke inkluderet)	0,1% sårbare og udnyttelige	0,1% sårbar, ikke udnyttelig	99,8% ikke sårbare	0,2% ukendt
Nedgradering af protokol	6,6% Nedgraderingsforsvar understøttes ikke	Ikke relevant	72,3% understøtter nedgradering af forsvar	21,0% ukendt

Frem hemmeligholdelse

Fremad hemmeligholdelse er en egenskab ved kryptografiske systemer, der sikrer, at en sessionsnøgle, der stammer fra et sæt offentlige og private nøgler, ikke kompromitteres, hvis en af ​​de private nøgler kompromitteres i fremtiden. Uden videregivelse af hemmeligholdelse, hvis serverens private nøgle er kompromitteret, vil ikke kun alle fremtidige TLS-krypterede sessioner, der bruger dette servercertifikat, blive kompromitteret, men også alle tidligere sessioner, der også har brugt den (forudsat at disse tidligere sessioner blev opsnappet og gemt på transmissionstidspunktet). En implementering af TLS kan give fortrolig hemmelighed ved at kræve brug af flygtig Diffie - Hellman -nøgleudveksling til at etablere sessionsnøgler, og nogle bemærkelsesværdige TLS -implementeringer gør det udelukkende: f.eks. Gmail og andre Google HTTPS -tjenester, der bruger OpenSSL . Mange klienter og servere, der understøtter TLS (herunder browsere og webservere), er imidlertid ikke konfigureret til at implementere sådanne begrænsninger. I praksis kan al den krypterede webtrafik til og fra denne tjeneste dekrypteres af en tredjepart, hvis en webtjeneste bruger Diffie - Hellman -nøgleudveksling til at implementere fortrolig hemmelighed; fx ved hjælp af en retskendelse.

Selv når Diffie-Hellman nøgleudveksling er implementeret, kan styringsmekanismer på serversiden påvirke fremadrettet hemmeligholdelse. Brugen af TLS -sessionbilletter (en TLS-udvidelse) bevirker, at sessionen er beskyttet af AES128-CBC-SHA256 uanset andre forhandlede TLS-parametre, herunder cifre til fremadrettede hemmeligholdelser, og de langtidsholdbare TLS-session-billetnøgler besejrer forsøget på at implementere videre hemmeligholdelse. Forskning ved Stanford University i 2014 fandt også, at af 473.802 undersøgte TLS -servere brugte 82,9% af serverne, der implementerede flygtig Diffie - Hellman (DHE) nøgleudveksling til understøttelse af hemmelig hemmelighed, svage Diffie - Hellman -parametre. Disse svage parametervalg kan potentielt kompromittere effektiviteten af ​​den fremadrettede hemmeligholdelse, som serverne søgte at give.

Siden slutningen af ​​2011 har Google som standard videregivet hemmeligholdelse med TLS til brugere af sin Gmail -tjeneste sammen med Google Docs og krypteret søgning. Siden november 2013 har Twitter videregivet hemmeligholdelse med TLS til brugere af sin service. Fra august 2019 er omkring 80% af TLS-aktiverede websteder konfigureret til at bruge chiffer-suiter, der giver de fleste webbrowsere hemmeligholdelse.

TLS aflytning

TLS-aflytning (eller HTTPS- aflytning, hvis den især anvendes på den protokol) er praksis med at opsnappe en krypteret datastrøm for at dekryptere den, læse og muligvis manipulere den og derefter genkryptere den og sende dataene på vej igen. Dette gøres ved hjælp af en " transparent proxy ": aflytningssoftwaren afslutter den indgående TLS -forbindelse, inspicerer HTTP -klarteksten og opretter derefter en ny TLS -forbindelse til destinationen.

TLS / HTTPS -aflytning bruges af netværksoperatører som en informationssikkerhedsforanstaltning for at kunne scanne efter og beskytte mod indtrængen af ​​ondsindet indhold i netværket, såsom computervirus og anden malware . Sådant indhold kunne ellers ikke opdages, så længe det er beskyttet af kryptering, hvilket i stigende grad er tilfældet som følge af den rutinemæssige brug af HTTPS og andre sikre protokoller.

En væsentlig ulempe ved TLS / HTTPS -aflytning er, at det introducerer nye egne sikkerhedsrisici. En bemærkelsesværdig begrænsning er, at det giver et punkt, hvor netværkstrafik er ukrypteret tilgængelig, hvilket giver angribere et incitament til at angribe dette punkt især for at få adgang til ellers sikkert indhold. Aflytningen giver også netværksoperatøren eller personer, der får adgang til dens aflytningssystem, mulighed for at udføre man-in-the-middle-angreb mod netbrugere. En undersøgelse fra 2017 viste, at "HTTPS -aflytning er blevet overraskende udbredt, og at aflytningsprodukter som en klasse har en dramatisk negativ indvirkning på forbindelsessikkerheden".

Protokol detaljer

TLS -protokollen udveksler poster , som indkapsler de data, der skal udveksles i et specifikt format (se nedenfor). Hver post kan komprimeres, polstres, tilføjes med en meddelelsesgodkendelseskode (MAC) eller krypteres, alt afhængigt af forbindelsens tilstand. Hver post har et indholdstypefelt , der angiver typen af ​​indkapslede data, et længdefelt og et TLS -versionsfelt. De indkapslede data kan være kontrol- eller proceduremeddelelser fra selve TLS'en eller simpelthen applikationsdata, der skal overføres af TLS. De specifikationer (chiffer -suite, nøgler osv.), Der kræves for at udveksle applikationsdata med TLS, aftales i "TLS -håndtrykket" mellem klienten, der anmoder om dataene, og serveren, der reagerer på anmodninger. Protokollen definerer derfor både strukturen af ​​nyttelast, der overføres i TLS, og proceduren for at etablere og overvåge overførslen.

TLS håndtryk

Når forbindelsen starter, indkapsler posten en "kontrol" -protokol - protokollen til håndtryk -beskeder ( indholdstype 22). Denne protokol bruges til at udveksle alle de oplysninger, der kræves af begge sider til udveksling af de faktiske applikationsdata med TLS. Det definerer formatet på meddelelser og rækkefølgen af ​​deres udveksling. Disse kan variere afhængigt af klientens og serverens krav - det vil sige, at der er flere mulige procedurer for at oprette forbindelsen. Denne første udveksling resulterer i en vellykket TLS -forbindelse (begge parter klar til at overføre applikationsdata med TLS) eller en advarselsmeddelelse (som angivet nedenfor).

Grundlæggende TLS håndtryk

Et typisk forbindelseseksempel følger, der illustrerer et håndtryk, hvor serveren (men ikke klienten) godkendes af sit certifikat:

1. Forhandlingsfase:
   • En klient sender en ClientHello -besked med angivelse af den højeste TLS -protokolversion, den understøtter, et tilfældigt tal, en liste over foreslåede chifferpakker og foreslåede komprimeringsmetoder. Hvis klienten forsøger at udføre et genoptaget håndtryk, sender den muligvis et sessions -id . Hvis klienten kan bruge Application-Layer protokol Forhandling , kan det indeholde en liste over understøttede ansøgning protokoller , såsom HTTP / 2 .
   • Serveren reagerer med en ServerHello -besked, der indeholder den valgte protokolversion, et tilfældigt tal, chifferpakke og komprimeringsmetode fra de valg, som klienten tilbyder. For at bekræfte eller tillade genoptaget håndtryk kan serveren sende et sessions -id . Den valgte protokolversion skal være den højeste, som både klienten og serveren understøtter. For eksempel, hvis klienten understøtter TLS version 1.1, og serveren understøtter version 1.2, skal version 1.1 vælges; version 1.2 bør ikke vælges.
   • Serveren sender sin certifikatmeddelelse (afhængigt af den valgte chiffer -pakke, kan dette blive udeladt af serveren).
   • Serveren sender sin ServerKeyExchange -meddelelse (afhængigt af den valgte chiffer -pakke kan dette blive udeladt af serveren). Denne meddelelse sendes til alle DHE , ECDHE og DH_anon cipher suiter.
   • Serveren sender en ServerHelloDone -besked, hvilket angiver, at det er udført med håndtryksforhandling.
   • Klienten reagerer med en ClientKeyExchange -meddelelse, som kan indeholde en PreMasterSecret , offentlig nøgle eller ingenting. (Igen afhænger dette af den valgte chiffer.) Denne PreMasterSecret er krypteret ved hjælp af servercertifikatets offentlige nøgle.
   • Klienten og serveren bruger derefter tilfældige tal og PreMasterSecret til at beregne en fælles hemmelighed, kaldet " hovedhemmeligheden ". Alle andre nøgledata ( sessionsnøgler som IV , symmetrisk krypteringsnøgle , MAC- nøgle) for denne forbindelse er afledt af denne hovedhemmelighed (og de klient- og servergenererede tilfældige værdier), som sendes gennem en omhyggeligt designet pseudosløjfunktion .
2. Klienten sender nu en ChangeCipherSpec -post , der hovedsageligt fortæller serveren, "Alt, hvad jeg fortæller dig fra nu af, vil blive godkendt (og krypteret, hvis der var krypteringsparametre i servercertifikatet)." ChangeCipherSpec er i sig selv en protokol på rekordniveau med indholdstype 20.
   • Klienten sender en godkendt og krypteret færdig besked, der indeholder en hash og MAC over de tidligere håndtryksbeskeder.
   • Serveren vil forsøge at dekryptere klientens færdige meddelelse og verificere hash og MAC. Hvis dekrypteringen eller verifikationen mislykkes, anses håndtrykket for at være mislykket, og forbindelsen skal rives ned.
3. Endelig sender serveren et ChangeCipherSpec , der fortæller klienten: "Alt, hvad jeg fortæller dig fra nu af, vil blive godkendt (og krypteret, hvis der blev forhandlet om kryptering)."
   • Serveren sender sin godkendte og krypterede færdige meddelelse.
   • Klienten udfører den samme dekrypterings- og verifikationsprocedure, som serveren gjorde i det foregående trin.
4. Applikationsfase: på dette tidspunkt er "håndtrykket" fuldført, og applikationsprotokollen er aktiveret, med indholdstype 23. Applikationsmeddelelser, der udveksles mellem klient og server, vil også blive godkendt og krypteret valgfrit nøjagtigt som i deres færdige meddelelse. Ellers returnerer indholdstypen 25, og klienten godkender ikke.

Klientgodkendt TLS-håndtryk

Følgende fulde eksempel viser en klient, der godkendes (ud over serveren som i eksemplet ovenfor; se gensidig godkendelse ) via TLS ved hjælp af certifikater, der udveksles mellem begge jævnaldrende.

1. Forhandlingsfase:
   • En klient sender en ClientHello -besked med angivelse af den højeste TLS -protokolversion, den understøtter, et tilfældigt tal, en liste over foreslåede chifferpakker og komprimeringsmetoder.
   • Serveren reagerer med en ServerHello -besked, der indeholder den valgte protokolversion, et tilfældigt tal, chifferpakke og komprimeringsmetode fra de valg, som klienten tilbyder. Serveren kan også sende et sessions -id som en del af meddelelsen for at udføre et genoptaget håndtryk.
   • Serveren sender sin certifikatmeddelelse (afhængigt af den valgte chiffer -pakke, kan dette blive udeladt af serveren).
   • Serveren sender sin ServerKeyExchange -meddelelse (afhængigt af den valgte chiffer -pakke kan dette blive udeladt af serveren). Denne besked sendes til alle DHE-, ECDHE- og DH_anon -cifersuitter.
   • Serveren sender en CertificateRequest -meddelelse for at anmode om et certifikat fra klienten.
   • Serveren sender en ServerHelloDone -besked, hvilket angiver, at det er udført med håndtryksforhandling.
   • Klienten reagerer med en certifikatbesked , som indeholder klientens certifikat.
   • Klienten sender en ClientKeyExchange -meddelelse, som kan indeholde en PreMasterSecret , offentlig nøgle eller ingenting. (Igen afhænger dette af den valgte chiffer.) Denne PreMasterSecret er krypteret ved hjælp af servercertifikatets offentlige nøgle.
   • Klienten sender en CertificateVerify -meddelelse, som er en signatur over de tidligere håndtryksbeskeder ved hjælp af klientens certifikats private nøgle. Denne signatur kan verificeres ved hjælp af klientcertifikatets offentlige nøgle. Dette lader serveren vide, at klienten har adgang til certifikatets private nøgle og dermed ejer certifikatet.
   • Klienten og serveren bruger derefter tilfældige tal og PreMasterSecret til at beregne en fælles hemmelighed, kaldet " hovedhemmeligheden ". Alle andre nøgledata ("sessionsnøgler") for denne forbindelse er afledt af denne hovedhemmelighed (og de klient- og servergenererede tilfældige værdier), som sendes gennem en omhyggeligt designet pseudorandom-funktion.
2. Klienten sender nu en ChangeCipherSpec- post, der hovedsagelig fortæller serveren, "Alt, hvad jeg fortæller dig fra nu af, vil blive godkendt (og krypteret, hvis der blev forhandlet om kryptering)." ChangeCipherSpec er i sig selv en protokol på postniveau og har type 20 og ikke 22 .
   • Endelig sender klienten en krypteret færdig besked, der indeholder en hash og MAC over de tidligere håndtryksbeskeder.
   • Serveren vil forsøge at dekryptere klientens færdige meddelelse og verificere hash og MAC. Hvis dekrypteringen eller verifikationen mislykkes, anses håndtrykket for at være mislykket, og forbindelsen skal rives ned.
3. Endelig sender serveren et ChangeCipherSpec , der fortæller klienten: "Alt, hvad jeg fortæller dig fra nu af, vil blive godkendt (og krypteret, hvis der blev forhandlet om kryptering)."
   • Serveren sender sin egen krypterede færdige meddelelse.
   • Klienten udfører den samme dekrypterings- og verifikationsprocedure, som serveren gjorde i det foregående trin.
4. Ansøgningsfase: på dette tidspunkt er "håndtrykket" fuldført, og applikationsprotokollen er aktiveret, med indholdstype 23. Applikationsmeddelelser, der udveksles mellem klient og server, vil også blive krypteret nøjagtigt som i deres færdige meddelelse.

Genoptaget TLS håndtryk

Offentlige nøglefunktioner (f.eks. RSA) er relativt dyre med hensyn til beregningskraft. TLS giver en sikker genvej i håndtryksmekanismen for at undgå disse handlinger: genoptaget sessioner. Genoptagne sessioner implementeres ved hjælp af sessions -id'er eller sessionbilletter.

Bortset fra præstationsfordelen kan genoptagne sessioner også bruges til enkelt login , da det garanterer, at både den originale session og enhver genoptaget session stammer fra den samme klient. Dette er af særlig betydning for FTP over TLS/SSL- protokollen, som ellers ville lide af et man-in-the-middle-angreb, hvor en angriber kunne opfange indholdet af de sekundære dataforbindelser.

TLS 1.3 håndtryk

TLS 1.3 -håndtrykket blev kondenseret til kun en rundtur sammenlignet med de to rundrejser, der kræves i tidligere versioner af TLS/SSL.

Først sender klienten en clientHello -meddelelse til serveren, der indeholder en liste over understøttede cifre i rækkefølge efter klientens præference og gætter på, hvilken nøglealgoritme der skal bruges, så den kan sende en hemmelig nøgle, hvis det er nødvendigt. Ved at gætte på hvilken nøglealgoritme der skal bruges, eliminerer serveren en rundtur. Efter modtagelse af clientHello sender serveren et serverHello med nøglen, et certifikat, den valgte chiffer -pakke og den færdige meddelelse.

Efter at klienten modtager serverens færdige meddelelse, koordineres den nu med den server, som chifferpakken skal bruges på.

Sessions -id'er

I et almindeligt fuldt håndtryk sender serveren et sessions -id som en del af ServerHello -meddelelsen. Klienten forbinder dette sessions -id med serverens IP -adresse og TCP -port, så når klienten opretter forbindelse igen til denne server, kan den bruge sessions -id'et til at genveje håndtrykket. På serveren tilknyttes sessions -id'et til de tidligere forhandlede kryptografiske parametre, specifikt "hovedhemmeligheden". Begge sider skal have den samme "hovedhemmelighed", ellers vil det genoptagne håndtryk mislykkes (dette forhindrer en aflytter i at bruge et sessions -id ). De tilfældige data i ClientHello- og ServerHello -meddelelserne garanterer stort set, at de genererede forbindelsesnøgler vil være forskellige fra den tidligere forbindelse. I RFC'erne kaldes denne type håndtryk et forkortet håndtryk. Det beskrives også i litteraturen som et genstartshåndtryk .

1. Forhandlingsfase:
   • En klient sender en ClientHello -besked med angivelse af den højeste TLS -protokolversion, den understøtter, et tilfældigt tal, en liste over foreslåede chifferpakker og komprimeringsmetoder. Inkluderet i meddelelsen er sessions -id'et fra den tidligere TLS -forbindelse.
   • Serveren reagerer med en ServerHello -besked, der indeholder den valgte protokolversion, et tilfældigt tal, chifferpakke og komprimeringsmetode fra de valg, som klienten tilbyder. Hvis serveren genkender det sessions -id, der sendes af klienten, reagerer det med det samme sessions -id . Klienten bruger dette til at genkende, at der genoptages et håndtryk. Hvis serveren ikke genkender det sessions -id, der sendes af klienten, sender den en anden værdi for sit sessions -id . Dette fortæller klienten, at et genoptaget håndtryk ikke vil blive udført. På dette tidspunkt har både klienten og serveren "hovedhemmeligheden" og tilfældige data til at generere de nøgledata, der skal bruges til denne forbindelse.
2. Serveren sender nu en ChangeCipherSpec -post , der hovedsageligt fortæller klienten, "Alt, hvad jeg fortæller dig fra nu af, vil blive krypteret." ChangeCipherSpec er i sig selv en protokol på rekordniveau og har type 20 og ikke 22.
   • Endelig sender serveren en krypteret færdig besked, der indeholder en hash og MAC over de tidligere håndtryksbeskeder.
   • Klienten vil forsøge at dekryptere serverens færdige meddelelse og verificere hash og MAC. Hvis dekrypteringen eller verifikationen mislykkes, anses håndtrykket for at være mislykket, og forbindelsen skal rives ned.
3. Endelig sender klienten et ChangeCipherSpec , der fortæller serveren: "Alt, hvad jeg fortæller dig fra nu af, vil blive krypteret."
   • Klienten sender sin egen krypterede færdige meddelelse.
   • Serveren udfører den samme dekrypterings- og verifikationsprocedure som klienten gjorde i det foregående trin.
4. Ansøgningsfase: på dette tidspunkt er "håndtrykket" fuldført, og applikationsprotokollen er aktiveret, med indholdstype 23. Applikationsmeddelelser, der udveksles mellem klient og server, vil også blive krypteret nøjagtigt som i deres færdige meddelelse.

Session billetter

RFC  5077 udvider TLS via brug af sessionbilletter i stedet for sessions -id'er. Det definerer en måde at genoptage en TLS-session uden at kræve, at sessionsspecifik tilstand er gemt på TLS-serveren.

Når du bruger sessionbilletter, gemmer TLS-serveren sin sessionsspecifikke tilstand i en sessionskort og sender sessionbilletten til TLS-klienten til lagring. Klienten genoptager en TLS-session ved at sende sessionsbilletten til serveren, og serveren genoptager TLS-sessionen i henhold til den sessionsspecifikke tilstand i billetten. Sessionsbilletten er krypteret og godkendt af serveren, og serveren verificerer dens gyldighed, før den bruger dens indhold.

En særlig svaghed ved denne metode med OpenSSL er, at den altid begrænser kryptering og godkendelsessikkerhed for den transmitterede TLS -sessionsbillet til AES128-CBC-SHA256, uanset hvilke andre TLS -parametre der blev forhandlet til den faktiske TLS -session. Det betyder, at statsoplysningerne (TLS -sessionsbilletten) ikke er så godt beskyttet som selve TLS -sessionen. Af særlig bekymring er OpenSSLs lagring af nøglerne i en applikationsomfattende kontekst ( SSL_CTX), dvs. i applikationens levetid, og ikke at tillade genindtastning af AES128-CBC-SHA256TLS-sessionbilletter uden at nulstille den applikationsomfattende OpenSSL-kontekst (hvilket er ualmindeligt , er tilbøjelig til fejl og kræver ofte manuel administrativ indgriben).

TLS -rekord

Dette er det generelle format for alle TLS -poster.

TLS -rekordformat, generelt

Forskydning	Byte +0	Byte +1	Byte +2	Byte +3
Byte 0	Indholdstype	Ikke relevant
Bytes 1..4	Ældre version		Længde
	(Major)	(Mindre)	(bits 15..8)	(bits 7..0)
Bytes 5 .. ( m −1)	Protokolmeddelelse (r)
Bytes m .. ( p −1)	MAC (valgfrit)
Bytes p .. ( q −1)	Polstring (kun blokchiffer)

Indholdstype

Dette felt identificerer den protokoltype, der indeholder denne lag.

Indholdstyper

Hex	Dec	Type
0x14	20	ChangeCipherSpec
0x15	21	Alert
0x16	22	Håndtryk
0x17	23	Ansøgning
0x18	24	Hjerteslag

Ældre version

Dette felt identificerer større og mindre version af TLS før TLS 1.3 for den indeholdte meddelelse. For en ClientHello -meddelelse behøver dette ikke at være den højeste version, der understøttes af klienten. For TLS 1.3 og nyere skal dette indstilles 0x0303, og applikationen skal sende understøttede versioner i en ekstra meddelelsesudvidelsesblok.

Versioner

Større version	Mindre version	Versionstype
3	0	SSL 3.0
3	1	TLS 1.0
3	2	TLS 1.1
3	3	TLS 1.2
3	4	TLS 1.3

Længde

Længden af ​​"protokolmeddelelse (r)", "MAC" og "polstring" felter kombineret (dvs. q −5), ikke overstige 2 ¹⁴ bytes (16 KiB).

Protokolmeddelelse (r)

En eller flere meddelelser identificeret ved protokolfeltet. Bemærk, at dette felt kan være krypteret afhængigt af forbindelsens tilstand.

MAC og polstring

En meddelelsesgodkendelseskode beregnet over feltet "protokolmeddelelse (r)" med yderligere nøglemateriale inkluderet. Bemærk, at dette felt kan være krypteret eller ikke inkluderet helt, afhængigt af forbindelsens tilstand.

Ingen "MAC" - eller "polstring" -felter kan være til stede ved afslutningen af ​​TLS -poster, før alle krypteringsalgoritmer og parametre er blevet forhandlet og håndrystet og derefter bekræftet ved at sende en CipherStateChange -post (se nedenfor) for at signalere, at disse parametre får virkning i alle yderligere optegnelser sendt af samme kollega.

Håndtryk protokol

De fleste meddelelser, der udveksles under opsætningen af ​​TLS -sessionen, er baseret på denne post, medmindre der opstår en fejl eller advarsel og skal signaleres af en Alert -protokolpost (se nedenfor), eller sessionens krypteringstilstand ændres af en anden post ( se ChangeCipherSpec -protokollen herunder).

TLS -rekordformat til håndtryksprotokol

Forskydning	Byte +0	Byte +1	Byte +2	Byte +3
Byte 0	22	Ikke relevant
Bytes 1..4	Ældre version		Længde
	(Major)	(Mindre)	(bits 15..8)	(bits 7..0)
Bytes 5..8	Meddelelsestype	Håndtryk meddelelsesdatalængde
		(bits 23..16)	(bits 15..8)	(bits 7..0)
Bytes 9 .. ( n −1)	Håndtryk meddelelsesdata
Bytes n .. ( n +3)	Meddelelsestype	Håndtryk meddelelsesdatalængde
		(bits 23..16)	(bits 15..8)	(bits 7..0)
Bytes ( n +4) ..	Håndtryk meddelelsesdata

Meddelelsestype

Dette felt identificerer håndtryksmeddelelsestypen.

Beskedtyper

Kode	Beskrivelse
0	Hej Anmodning
1	Klient Hej
2	Server Hej
4	NewSessionTicket
8	EncryptedExtensions (kun TLS 1.3)
11	Certifikat
12	ServerKeyExchange
13	Certifikatanmodning
14	ServerHelloDone
15	CertificateVerify
16	ClientKeyExchange
20	Færdig

Håndtryk meddelelsesdatalængde

Dette er et 3-byte felt, der angiver længden af ​​håndtryksdataene, inklusive overskriften.

Bemærk, at flere håndtryksmeddelelser kan kombineres i en post.

Advarselsprotokol

Denne rekord bør normalt ikke sendes under normal håndtryk eller applikationsudveksling. Denne meddelelse kan dog sendes når som helst under håndtrykket og op til sessionens afslutning. Hvis dette bruges til at signalere en dødelig fejl, lukkes sessionen umiddelbart efter afsendelse af denne post, så denne post bruges til at give en grund til denne lukning. Hvis advarselsniveauet er markeret som en advarsel, kan fjernbetjeningen beslutte at lukke sessionen, hvis den beslutter, at sessionen ikke er pålidelig nok til dens behov (inden den gør det, kan fjernbetjeningen også sende sit eget signal).

TLS -postformat til advarselsprotokol

Forskydning	Byte +0	Byte +1	Byte +2	Byte +3
Byte 0	21	Ikke relevant
Bytes 1..4	Ældre version		Længde
	(Major)	(Mindre)	0	2
Bytes 5..6	Niveau	Beskrivelse	Ikke relevant
Bytes 7 .. ( p −1)	MAC (valgfrit)
Bytes p .. ( q −1)	Polstring (kun blokchiffer)

Niveau

Dette felt identificerer alarmniveauet. Hvis niveauet er dødeligt, skal afsenderen lukke sessionen med det samme. Ellers kan modtageren beslutte at afslutte selve sessionen ved at sende sin egen fatale alarm og lukke selve sessionen umiddelbart efter at have sendt den. Brugen af ​​advarselsposter er valgfri, men hvis den mangler før sessionens lukning, kan sessionen genoptages automatisk (med sine håndtryk).

Normal lukning af en session efter afslutning af den transporterede applikation bør fortrinsvis advares med mindst Luk besked -advarselstype (med et enkelt advarselsniveau) for at forhindre sådan automatisk genoptagelse af en ny session. Signal eksplicit den normale lukning af en sikker session, før dens transportlag effektivt lukkes, er nyttig til at forhindre eller opdage angreb (f.eks. Forsøg på at trunke de sikkert transporterede data, hvis den i sagens natur ikke har en forudbestemt længde eller varighed, som modtageren af ​​de sikrede data kan forvente).

Typer af alarmniveauer

Kode	Niveau type	Tilslutningstilstand
1	advarsel	forbindelse eller sikkerhed kan være ustabil.
2	fatal	forbindelse eller sikkerhed kan blive kompromitteret, eller der er opstået en fejl, der ikke kan genoprettes.

Beskrivelse

Dette felt identificerer, hvilken type advarsel der sendes.

Beskedtyper for advarsler

Kode	Beskrivelse	Niveautyper	Bemærk
0	Luk besked	advarsel / dødelig
10	Uventet besked	fatal
20	Dårlig rekord MAC	fatal	Muligvis en dårlig SSL -implementering, eller nyttelast er blevet manipuleret med f.eks. FTP -firewallregel på FTPS -server.
21	Dekryptering mislykkedes	fatal	Kun TLS, forbeholdt
22	Rekordoverløb	fatal	Kun TLS
30	Dekompressionsfejl	fatal
40	Håndtryksfejl	fatal
41	Intet certifikat	advarsel / dødelig	Kun SSL 3.0, forbeholdt
42	Dårligt certifikat	advarsel / dødelig
43	Ikke -understøttet certifikat	advarsel / dødelig	f.eks. certifikat har kun servergodkendelsesbrug aktiveret og præsenteres som et klientcertifikat
44	Certifikat tilbagekaldt	advarsel / dødelig
45	Certifikatet er udløbet	advarsel / dødelig	Kontroller, at servercertifikat udløber, og kontroller, at intet certifikat i den præsenterede kæde er udløbet
46	Certifikat ukendt	advarsel / dødelig
47	Ulovlig parameter	fatal
48	Ukendt CA ( Certifikatmyndighed )	fatal	Kun TLS
49	Adgang nægtet	fatal	Kun TLS - f.eks. Er der ikke blevet præsenteret noget klientcertifikat (TLS: Tom certifikatbesked eller SSLv3: Ingen certifikatvarsel), men serveren er konfigureret til at kræve en.
50	Afkode fejl	fatal	Kun TLS
51	Dekrypter fejl	advarsel / dødelig	Kun TLS
60	Eksportbegrænsning	fatal	Kun TLS, forbeholdt
70	Protokolversion	fatal	Kun TLS
71	Utilstrækkelig sikkerhed	fatal	Kun TLS
80	Intern fejl	fatal	Kun TLS
86	Upassende tilbagevenden	fatal	Kun TLS
90	Bruger annulleret	fatal	Kun TLS
100	Ingen genforhandling	advarsel	Kun TLS
110	Udvidelse, der ikke understøttes	advarsel	Kun TLS
111	Certifikat kan ikke opnås	advarsel	Kun TLS
112	Ukendt navn	advarsel / dødelig	Kun TLS; klientens servernavnsindikator angav et værtsnavn, der ikke understøttes af serveren
113	Dårligt svar på certifikatstatus	fatal	Kun TLS
114	Dårlig værdi for certifikathash	fatal	Kun TLS
115	Ukendt PSK- identitet (brugt i TLS-PSK og TLS-SRP )	fatal	Kun TLS

ChangeCipherSpec -protokol

TLS -postformat til ChangeCipherSpec -protokol

Forskydning	Byte +0	Byte +1	Byte +2	Byte +3
Byte 0	20	Ikke relevant
Bytes 1..4	Ældre version		Længde
	(Major)	(Mindre)	0	1
Byte 5	CCS protokol type	Ikke relevant

CCS protokol type

I øjeblikket kun 1.

Ansøgningsprotokol

TLS -postformat til applikationsprotokol

Forskydning	Byte +0	Byte +1	Byte +2	Byte +3
Byte 0	23	Ikke relevant
Bytes 1..4	Ældre version		Længde
	(Major)	(Mindre)	(bits 15..8)	(bits 7..0)
Bytes 5 .. ( m −1)	Applikationsdata
Bytes m .. ( p −1)	MAC (valgfrit)
Bytes p .. ( q −1)	Polstring (kun blokchiffer)

Længde

Længde på applikationsdata (eksklusive protokoloverskriften og inklusive MAC- og polstringstrailere)

MAC

32 bytes for SHA -256 -baseret HMAC , 20 bytes for SHA -1 -baseret HMAC, 16 bytes for MD5 -baseret HMAC.

Polstring

Variabel længde; sidste byte indeholder polstringslængde.

Understøttelse af navnebaserede virtuelle servere

Set fra applikationsprotokollens synspunkt tilhører TLS et lavere lag, selvom TCP/IP -modellen er for grov til at vise det. Det betyder, at TLS -håndtrykket normalt udføres (undtagen i STARTTLS -sagen), før applikationsprotokollen kan starte. I den navnebaserede virtuelle serverfunktion , der leveres af applikationslaget, deler alle co-hostede virtuelle servere det samme certifikat, fordi serveren skal vælge og sende et certifikat umiddelbart efter ClientHello-meddelelsen. Dette er et stort problem i hostingmiljøer, fordi det betyder enten at dele det samme certifikat mellem alle kunder eller bruge en anden IP -adresse til hver af dem.

Der er to kendte løsninger, der leveres af X.509 :

• Hvis alle virtuelle servere tilhører det samme domæne, kan et wildcard -certifikat bruges. Udover det løse hostnavn valg, der kan være et problem eller ej, er der ingen fælles aftale om, hvordan man matcher wildcard -certifikater. Der anvendes forskellige regler afhængigt af applikationsprotokollen eller den anvendte software.
• Tilføj hvert virtuelt værtsnavn i udvidelsen subjectAltName. Det største problem er, at certifikatet skal genudgives, når der tilføjes en ny virtuel server.

For at angive servernavnet tillader RFC  4366 Transport Layer Security (TLS) -udvidelser klienter at inkludere en udvidelse af servernavnet (SNI) i den udvidede ClientHello -meddelelse. Denne udvidelse antyder serveren med det samme, hvilket navn klienten ønsker at oprette forbindelse til, så serveren kan vælge det relevante certifikat, der skal sendes til klienterne.

RFC  2817 dokumenterer også en metode til at implementere navnebaseret virtuel hosting ved at opgradere HTTP til TLS via et HTTP/1.1-opgraderingsoverskrift . Normalt er dette for at implementere HTTP på en sikker måde over TLS inden for det primære "http" URI -skema (som undgår forfalskning af URI -rummet og reducerer antallet af brugte porte), men få implementeringer understøtter dette i øjeblikket.

Standarder

Primære standarder

Den nuværende godkendte version af TLS er version 1.3, som er specificeret i:

• RFC  8446 : "The Transport Layer Security (TLS) Protocol Version 1.3".

Den nuværende standard erstatter disse tidligere versioner, som nu betragtes som forældede:

• RFC  2246 : "TLS -protokol version 1.0".
• RFC  4346 : "The Transport Layer Security (TLS) Protocol Version 1.1".
• RFC  5246 : "The Transport Layer Security (TLS) Protocol Version 1.2".

Samt den aldrig standardiserede SSL 2.0 og 3.0, der betragtes som forældede:

• Internetudkast (1995) , SSL version 2.0
• RFC  6101 : "Secure Sockets Layer (SSL) Protocol Version 3.0".

Udvidelser

Andre RFC'er udvidede efterfølgende TLS.

Udvidelser til TLS 1.0 inkluderer:

• RFC  2595 : "Brug af TLS med IMAP, POP3 og ACAP". Angiver en udvidelse til IMAP-, POP3- og ACAP-tjenesterne, der gør det muligt for serveren og klienten at bruge transportlags sikkerhed til at levere privat, godkendt kommunikation over internettet.
• RFC  2712 : "Tilføjelse af Kerberos Cipher Suites til Transport Layer Security (TLS)". De 40-bit cipher-suiter, der er defineret i dette notat, vises kun med det formål at dokumentere, at disse chiffer-suite-koder allerede er blevet tildelt.
• RFC  2817 : "Opgradering til TLS Inden for HTTP/1.1" forklarer, hvordan man bruger opgraderingsmekanismen i HTTP/1.1 til at starte Transport Layer Security (TLS) over en eksisterende TCP -forbindelse. Dette giver usikret og sikret HTTP -trafik mulighed for at dele den samme velkendte port (i dette tilfælde http: på 80 i stedet for https: ved 443).
• RFC  2818 : "HTTP Over TLS", adskiller sikret trafik fra usikker trafik ved brug af en anden 'serverport'.
• RFC  3207 : "SMTP Service Extension til Secure SMTP over Transport Layer Security". Angiver en udvidelse til SMTP-tjenesten, der gør det muligt for en SMTP-server og klient at bruge transportlags sikkerhed til at levere privat, godkendt kommunikation over internettet.
• RFC  3268 : "AES Ciphersuites for TLS". Tilføjer AES -krypteringssuiter ( Advanced Encryption Standard ) til de tidligere eksisterende symmetriske chiffer.
• RFC  3546 : "Transport Layer Security (TLS) Extensions", tilføjer en mekanisme til forhandling af protokoludvidelser under initialisering af sessionen og definerer nogle udvidelser. Gjorde forældet af RFC  4366 .
• RFC  3749 : "Transport Layer Security Protocol Compression Methods", angiver rammerne for komprimeringsmetoder og DEFLATE -komprimeringsmetoden .
• RFC  3943 : "Transport Layer Security (TLS) Protocol Compression Using Lempel-Ziv-Stac (LZS)".
• RFC  4132 : "Tilføjelse af Camellia Cipher Suites til Transport Layer Security (TLS)".
• RFC  4162 : "Tilføjelse af SEED Cipher Suites til Transport Layer Security (TLS)".
• RFC  4217 : "Sikring af FTP med TLS ".
• RFC  4279 : "Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)", tilføjer tre sæt nye chiffer-suiter til TLS-protokollen for at understøtte godkendelse baseret på forud delte nøgler.

Udvidelser til TLS 1.1 inkluderer:

• RFC  4347 : " Datagram Transport Layer Security " angiver en TLS -variant, der fungerer over datagramprotokoller (f.eks. UDP).
• RFC  4366 : "Transport Layer Security (TLS) Extensions" beskriver både et sæt specifikke udvidelser og en generisk udvidelsesmekanisme.
• RFC  4492 : " Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)".
• RFC  4680 : "TLS Handshake Message for Supplerende Data".
• RFC  4681 : "TLS User Mapping Extension".
• RFC  4785 : "Pre-Shared Key (PSK) chifferdragt med NULL-kryptering til transportlagsikkerhed (TLS)".
• RFC  5054 : "Brug af protokollen Secure Remote Password (SRP) til TLS -godkendelse". Definerer TLS-SRP ciphersuites.
• RFC  5077 : "Session genoptagelse af Transport Layer Security (TLS) uden tilstand på serversiden".
• RFC  5081 : "Brug af OpenPGP -nøgler til Transport Layer Security (TLS) -godkendelse", forældet af RFC  6091 .

Udvidelser til TLS 1.2 inkluderer:

• RFC  5288 : "AES Galois Counter Mode (GCM) Cipher Suites for TLS".
• RFC  5289 : "TLS Elliptic Curve Cipher Suites med SHA-256/384 og AES Galois Counter Mode (GCM)".
• RFC  5746 : "Transport Layer Security (TLS) Renegotiation Indication Extension".
• RFC  5878 : "Transport Layer Security (TLS) Authorization Extensions".
• RFC  5932 : "Camellia Cipher Suites for TLS"
• RFC  6066 : "Transport Layer Security (TLS) Extensions: Extension Definitions", inkluderer angivelse af servernavn og OCSP -hæftning .
• RFC  6091 : "Brug af OpenPGP -nøgler til Transport Layer Security (TLS) -godkendelse".
• RFC  6176 : "Forbyder Secure Sockets Layer (SSL) version 2.0".
• RFC  6209 : "Tilføjelse af ARIA Cipher Suites til Transport Layer Security (TLS)".
• RFC  6347 : "Datagram Transport Layer Security Version 1.2".
• RFC  6367 : "Tilføjelse af Camellia Cipher Suites til Transport Layer Security (TLS)".
• RFC  6460 : "Suite B -profil til Transport Layer Security (TLS)".
• RFC  6655 : "AES-CCM Cipher Suites for Transport Layer Security (TLS)".
• RFC  7027 : "Elliptic Curve Cryptography (ECC) Brainpool Curves for Transport Layer Security (TLS)".
• RFC  7251 : "AES-CCM Elliptic Curve Cryptography (ECC) Cipher Suites for TLS".
• RFC  7301 : "Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension".
• RFC  7366 : "Krypter-derefter-MAC til Transport Layer Security (TLS) og Datagram Transport Layer Security (DTLS)".
• RFC  7465 : "Forbyder RC4 Cipher Suites".
• RFC  7507 : "TLS Fallback Signaling Cipher Suite Value (SCSV) til forebyggelse af protokol -nedgraderingsangreb".
• RFC  7568 : "Udfasning af Secure Sockets Layer Version 3.0".
• RFC  7627 : "Transport Layer Security (TLS) Session Hash og Extended Master Secret Extension".
• RFC  7685 : "A Transport Layer Security (TLS) ClientHello Padding Extension".

Indkapslinger af TLS omfatter:

• RFC  5216 : " EAP -TLS -godkendelsesprotokollen"

Informations -RFC'er

• RFC  7457 : "Opsummering af kendte angreb på Transport Layer Security (TLS) og Datagram TLS (DTLS)"
• RFC  7525 : "Anbefalinger til sikker brug af Transport Layer Security (TLS) og Datagram Transport Layer Security (DTLS)"

Se også

• Application-Layer Protocol Negotiation -en TLS-udvidelse, der bruges til SPDY og TLS False Start
• Bullrun (dekrypteringsprogram)-et hemmeligt antikrypteringsprogram , der drives af US National Security Agency
• Certifikatmyndighed
• Certifikatgennemsigtighed
• HTTP streng transportsikkerhed - HSTS
• Nøglering fil
• QUIC (Quick UDP Internet Connections) - "... blev designet til at give sikkerhedsbeskyttelse svarende til TLS/SSL"; QUICs hovedmål er at forbedre den opfattede ydeevne for forbindelsesorienterede webapplikationer, der i øjeblikket bruger TCP
• Server-lukket kryptografi
• tcpcrypt
• DTLS
• TLS -acceleration

Referencer

Yderligere læsning

• Wagner, David; Schneier, Bruce (november 1996). "Analyse af SSL 3.0 -protokollen" (PDF) . Det andet USENIX -værksted om elektronisk handel . USENIX Tryk. s. 29–40.
• Eric Rescorla (2001). SSL og TLS: Design og opbygning af sikre systemer . USA: Addison-Wesley Pub Co. ISBN 978-0-201-61598-2.
• Stephen A. Thomas (2000). SSL og TLS essentials sikrer internettet . New York: Wiley. ISBN 978-0-471-38354-3.
• Bard, Gregory (2006). "Et udfordrende, men gennemføreligt Blockwise-Adaptive Chosen-Plaintext Attack på SSL" . International Association for Cryptologic Research (136) . Hentet 2011-09-23 .
• Canvel, Brice. "Adgangskode aflytning i en SSL/TLS -kanal" . Hentet 2007-04-20 .
• IETF flere forfattere. "RFC for ændring for TLS Renegotiation" . Hentet 2009-12-11 .
• Oprettelse af VPN'er med IPsec og SSL/TLS Linux Journal -artikel af Rami Rosen
• Joshua Davies (2010). Implementering af SSL/TLS . Wiley. ISBN 978-0470920411.
• Polk, Tim; McKay, Kerry; Chokhani, Santosh (april 2014). "Retningslinjer for valg, konfiguration og brug af implementeringer af transportlagsikkerhed (TLS)" (PDF) . National Institute of Standards and Technology. Arkiveret fra originalen (PDF) 2014-05-08 . Hentet 2014-05-07 .
• Abdou, AbdelRahman; van Oorschot, Paul (august 2017). "Verifikation af serverplacering (SLV) og fastgørelse af serverplacering: Forøgelse af TLS -godkendelse" . Transaktioner om fortrolighed og sikkerhed . ACM. 21 (1): 1: 1–1: 26. doi : 10.1145/3139294 . S2CID  5869541 .

eksterne links

• IETF (Internet Engineering Task Force) TLS -arbejdsgruppe