TLS

TLS ( engelsk  transport layer security  - Transport Layer Security Protocol [1] ), er ligesom sin forgænger SSL ( engelsk  secure sockets layer  - et lag af sikre sockets), kryptografiske protokoller , der giver sikker dataoverførsel mellem noder på internettet [2] . TLS og SSL bruger asymmetrisk kryptering til godkendelse, symmetrisk kryptering for privatliv og meddelelsesgodkendelseskoder for at bevare meddelelsens integritet.

Denne protokol er meget udbredt i internetapplikationer såsom webbrowsere , e- mail , instant messaging og Voice over IP (VoIP) .

TLS-protokollen er baseret på SSL version 3.0-protokolspecifikationen udviklet af Netscape Communications [3] . TLS-standarden er nu ved at blive udviklet af IETF . Den sidste protokolopdatering var i RFC 5246 (august 2008) og RFC 6176 (marts 2011).

Beskrivelse

TLS tillader klient-server-applikationer at kommunikere over et netværk på en sådan måde, at pakkesniffning og uautoriseret adgang ikke kan forekomme .

Da de fleste kommunikationsprotokoller kan bruges med eller uden TLS (eller SSL), skal du ved etablering af en forbindelse udtrykkeligt fortælle serveren, om klienten ønsker at etablere TLS. Dette kan opnås enten ved at bruge et ensartet portnummer , hvor forbindelsen altid etableres ved hjælp af TLS (som port 443 for HTTPS ), eller ved at bruge en brugerdefineret port og en speciel kommando fra klientsiden til serveren for at skifte forbindelsen til TLS ved hjælp af specielle protokolmekanismer (såsom STARTTLS for e -mail -protokoller ). Når klienten og serveren er blevet enige om at bruge TLS, skal de etablere en sikker forbindelse. Dette gøres ved hjælp af en håndtryksprocedure [4] [5] . Under denne proces bliver klienten og serveren enige om de forskellige parametre, der kræves for at etablere en sikker forbindelse.

De vigtigste trin i proceduren for oprettelse af en sikker kommunikationssession:

Dette fuldender håndtryksprocessen. Der etableres en sikker forbindelse mellem klienten og serveren, de data, der transmitteres over den, krypteres og dekrypteres ved hjælp af et symmetrisk kryptosystem, indtil forbindelsen er fuldført.

Hvis du støder på problemer med nogle af ovenstående trin, kan håndtrykket mislykkes, og en sikker forbindelse bliver muligvis ikke etableret.

Historie og versioner

SSL og TLS protokoller
Protokol Udgivelsesdato Stat
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 [6]
TLS 1.1 2006 Udfaset i 2020 [6]
TLS 1.2 2008
TLS 1.3 2018

De første forsøg på at implementere krypterede netværkssockets blev gjort i 1993 [7] . De originale SSL-protokoller blev udviklet af Netscape: version 1.0 blev ikke offentliggjort på grund af en række mangler, version 2.0 blev introduceret i 1995 og erstattet af version 3.0 i 1996 [8] . SSL 3.0 var en komplet revision af protokollen af ​​Paul Kocher og Netscape-bidragyderne Phil Karlton og Alan Freier med input fra Consensus Development. Efterfølgende versioner af SSL og TLS er baseret på SSL 3.0. Et udkast til standarden fra 1996 blev offentliggjort som RFC 6101 af IETF . Brugen af ​​SSL 2.0 blev udfaset i 2011 med udgivelsen af ​​RFC 6176 . I 2014 blev et POODLE- angreb foreslået mod SSL 3.0 -blokchiffer , og den eneste understøttede stream-ciffer, RC4 , havde andre sikkerhedsproblemer, da den blev brugt [9] . I juni 2015 blev SSL 3.0 udfaset ( RFC 7568 ).

TLS 1.0 dukkede op i 1999 som en opdatering til SSL 3.0 og er beskrevet i RFC 2246 . I 2018 opfordrede PCI DSS virksomheder til at opgive TLS 1.0 [10] og i oktober 2018 annoncerede de største aktører på browser- og OS-markedet ( Apple , Google, Microsoft , Mozilla ), at de ville stoppe med at understøtte TLS version 1.0 og 1.1 i marts 2020 [6] .

TLS 1.1 blev beskrevet i RFC 4346 i april 2006 [11] . Han tilføjede til TLS 1.0 en række beskyttelser mod angreb på CBC-chiffertilstande og blokstørrelsesudfyldningsfejl , begyndte at bruge en eksplicit initialiseringsvektor og registrering af numeriske koder for parametre i IANA [12] .

TLS 1.2 dukkede op i august 2008 som en opdatering til version 1.1, beskrevet i RFC 5246 . De forældede kryptografiske hash-funktioner MD5 og SHA-1 blev forbudt (erstattet af SHA-256), mekanismen til at blive enige om listerne over understøttede metoder af parterne blev forbedret, AEAD- metoderne ( GCM og CCM for AES ) blev introduceret [13] .

I marts 2011 forbød RFC 6176 bagudkompatibilitet med ældre versioner af SSL i alle TLS-protokoller.

Den nyeste opdatering var TLS 1.3, beskrevet i august 2018 i RFC 8446 . Denne version adskilte nøgleaftale-, godkendelses- og chifferpakkeprocesserne; svage og sparsomme elliptiske kurver, MD5 og SHA-224 hash er forbudt; indført obligatorisk digital signatur; implementeret HKDF og semi-ephemeral DH system. I stedet for fornyelsesmekanismen blev PSK og systemet med legitimationsoplysninger brugt, forbindelsesprocesser (1-RTT og 0-RTT) blev accelereret, og perfekt fremadrettet hemmeligholdelse blev postuleret for sessionsnøgler gennem DH- og ECDH-genereringsprotokollerne. Sådanne forældede og usikre muligheder som datakomprimering , genforhandling, cifre uden meddelelsesgodkendelse (dvs. ikke - AEAD -tilstande), ikke-hemmelige metoder til at opnå sessionsnøgler (RSA, statiske DH, DHE-grupper), hjælpemeddelelser (Change Cipher Spec, HELLO , feltet AD længde). Sluttede bagudkompatibilitet med SSL eller RC4. ChaCha20 -strømchiffer med MAC-kode Poly1305 , Ed25519 og Ed448 signaturer, x25519 og x448 nøgleudvekslingsprotokoller dukkede op .

Understøttelse af TLS 1.3 dukkede op i Mozilla Network Security Services (NSS) i februar 2017 (inkluderet i Firefox 60) [14] [15] . Google Chrome understøttede TLS 1.3 i et stykke tid i 2017, men deaktiverede den til fordel for Blue Coat webprox [16] . OpenSSL tilføjede denne version i september 2018-udgivelsen 1.1.1 [17] . Electronic Frontier Foundation opfordrede til TLS 1.3 og advarede mod forveksling med den lignende kleptografiske protokol hybrid ETS eller eTLS (det udelod bevidst vigtige sikkerhedsfunktioner fra TLS 1.3) [18] .

Sikkerhed

TLS har mange sikkerhedsforanstaltninger:

Sårbarheden af ​​TLS 1.0-protokollen, som blev betragtet som teoretisk, blev demonstreret på Ekoparty-konferencen i september 2011. Demoen inkluderede dekryptering af de cookies , der blev brugt til at autentificere brugeren [19] .

En sårbarhed i genforbindelsesfasen, opdaget i august 2009, gjorde det muligt for en kryptoanalytiker , der var i stand til at knække en https-forbindelse , at tilføje deres egne anmodninger til meddelelser sendt fra klienten til serveren [20] . Da kryptanalytikeren ikke kan dekryptere server-klient-kommunikationen, adskiller denne type angreb sig fra standardman -in-the-middle- angrebet . Hvis brugeren ikke er opmærksom på browserens indikation af, at sessionen er sikker (normalt et hængelåsikon), kan sårbarheden bruges til et man-in-the-middle- angreb [21] . For at eliminere denne sårbarhed blev det foreslået både på klientsiden og på serversiden at tilføje information om den tidligere forbindelse og kontrollere, hvornår forbindelsen genoptages. Dette blev introduceret i RFC 5746 og er også implementeret i nyere versioner af OpenSSL [22] og andre biblioteker [23] [24] .

Der er også angrebsmuligheder baseret direkte på softwareimplementeringen af ​​protokollen og ikke på dens algoritme [25] .

Håndtryksprocedure i TLS i detaljer

I henhold til TLS-protokollen udveksler applikationer poster, der indkapsler (lagrer i sig selv) den information, der skal transmitteres. Hver af posterne kan komprimeres, polstres, krypteres eller identificeres af en MAC (Message Authentication Code) afhængigt af forbindelsens aktuelle tilstand (protokoltilstand). Hver post i TLS indeholder følgende felter: Indholdstype (definerer indholdstypen for posten), Version (et felt, der angiver versionen af ​​TLS-protokollen) og Længde (et felt, der angiver pakkens længde).

Når forbindelsen netop er etableret, går interaktionen gennem TLS handshake-protokollen, hvis indholdstype er 22.

Simpelt håndtryk i TLS

Det følgende er et simpelt forbindelsesopsætningseksempel, hvor serveren (men ikke klienten) godkendes af sit certifikat.

  1. Forhandlingsfase:
    • Klienten sender en ClientHello- meddelelse , der angiver den seneste version af den understøttede TLS-protokol, et tilfældigt tal og en liste over understøttede krypteringspakker (krypteringsmetoder, engelske krypteringspakker), der er egnede til at arbejde med TLS;
    • Serveren svarer med en ServerHello- meddelelse, der indeholder: protokolversionen valgt af serveren, et tilfældigt tal genereret af serveren, en valgt ciphersuite fra listen leveret af klienten;
    • Serveren sender en certifikatmeddelelse , der indeholder serverens digitale certifikat (afhængigt af krypteringsalgoritmen kan dette trin springes over);
    • Hvis de data, der transmitteres af serveren, ikke er nok til at generere en delt symmetrisk hemmelig nøgle inden for den valgte ciphersuite, sender serveren en ServerKeyExchange-meddelelse, der indeholder de nødvendige data. For eksempel, i ServerKeyExchange sendes serverdelen af ​​udvekslingen for Diffie-Hellman-protokollen;
    • Serveren sender en ServerHelloDone- meddelelse, der identificerer slutningen af ​​den første runde af forbindelsesetablering;
    • Klienten svarer med en ClientKeyExchange- meddelelse, der indeholder klientdelen af ​​Diffie-Hellman-protokollen eller en hemmelighed ( PreMasterSecret ) krypteret med den offentlige nøgle fra serverens certifikat ;
    • Klienten og serveren, ved hjælp af PreMasterSecret- nøglen og tilfældigt genererede tal, beregner en delt hemmelighed. Alle andre sessionsnøgleoplysninger vil blive afledt af den delte hemmelighed;
  2. Klienten sender en ChangeCipherSpec- meddelelse , der angiver, at alle efterfølgende oplysninger vil blive krypteret ved hjælp af håndtryksalgoritmen, ved hjælp af den delte hemmelighed. Dette er en besked på rekordniveau og har derfor type 20, ikke 22;
    • Klienten sender en Færdig -meddelelse , der indeholder hash og MAC genereret fra de tidligere håndtrykmeddelelser;
    • Serveren forsøger at dekryptere klientens Færdig-meddelelse og verificere hash og MAC. Hvis dekrypteringen eller verifikationsprocessen mislykkes, betragtes håndtrykket som en fejl, og forbindelsen skal afbrydes;
  3. Serveren sender en ChangeCipherSpec og en krypteret Færdig-meddelelse, og klienten udfører igen dekrypteringen og valideringen.

Fra dette øjeblik betragtes bekræftelsen af ​​kommunikationen som afsluttet, protokollen er etableret. Alt efterfølgende pakkeindhold kommer med type 23, og alle data vil blive krypteret.

Håndtryk med klientgodkendelse

Dette eksempel viser fuld klientgodkendelse (ud over servergodkendelse som i det foregående eksempel) ved hjælp af certifikatudveksling mellem server og klient.

  1. Forhandlingsfase:
    • Klienten sender en ClientHello- meddelelse , der angiver den seneste version af den understøttede TLS-protokol, et tilfældigt tal og en liste over understøttede krypterings- og komprimeringsmetoder, der er egnede til at arbejde med TLS;
    • Serveren svarer med en ServerHello- meddelelse, der indeholder: protokolversionen valgt af serveren, et tilfældigt tal sendt af klienten, en passende krypterings- og komprimeringsalgoritme fra den liste, som klienten leverer;
    • Serveren sender en certifikatmeddelelse , der indeholder serverens digitale certifikat (afhængigt af krypteringsalgoritmen kan dette trin springes over);
    • Serveren sender en CertificateRequest -meddelelse indeholdende en klientcertifikatanmodning til gensidig godkendelse;
    • Klienten sender en certifikatmeddelelse , der indeholder klientens digitale certifikat;
    • Serveren sender en ServerHelloDone- meddelelse, der identificerer slutningen af ​​håndtrykket;
    • Klienten svarer med en ClientKeyExchange- meddelelse indeholdende den offentlige nøgle PreMasterSecret eller ingenting (igen afhænger af krypteringsalgoritmen);
    • Klienten og serveren, ved hjælp af PreMasterSecret- nøglen og tilfældigt genererede tal, beregner en delt hemmelig nøgle. Al anden information om nøglen vil blive hentet fra den delte hemmelige nøgle (og tilfældige værdier genereret af klienten og serveren);
  2. Klienten sender en ChangeCipherSpec- meddelelse , der angiver, at alle efterfølgende oplysninger vil blive krypteret ved hjælp af håndtryksalgoritmen, ved hjælp af den delte hemmelighed. Disse er meddelelser på rekordniveau og er derfor af type 20, ikke 22;
    • Klienten sender en Færdig -meddelelse , der indeholder hash og MAC genereret fra de tidligere håndtrykmeddelelser;
    • Serveren forsøger at dekryptere klientens Færdig-meddelelse og verificere hash og MAC. Hvis dekrypterings- eller verifikationsprocessen mislykkes, betragtes håndtrykket som en fejl, og forbindelsen skal afbrydes.
  3. Serveren sender en ChangeCipherSpec og en krypteret Færdig-meddelelse, og klienten udfører igen dekrypteringen og valideringen.

Fra dette øjeblik betragtes bekræftelsen af ​​kommunikationen som afsluttet, protokollen er etableret. Alt efterfølgende pakkeindhold kommer med type 23, og alle data vil blive krypteret.

Genoptagelse af en TLS-forbindelse

De asymmetriske krypteringsalgoritmer, der bruges til at generere sessionsnøglen, er normalt dyre med hensyn til computerkraft. For at undgå at gentage dem, når forbindelsen genoptages, opretter TLS et særligt håndtryk-tag, der bruges til at genoptage forbindelsen. I dette tilfælde, under et normalt håndtryk, tilføjer klienten identifikatoren for den forrige sessionsessions-id til ClientHello- meddelelsen . Klienten knytter sessions-id'et til serverens IP-adresse og TCP-port, så når der oprettes forbindelse til serveren, kan alle parametre for den tidligere forbindelse bruges. Serveren matcher den forrige sessions sessions-id med forbindelsesparametre såsom den anvendte krypteringsalgoritme og masterhemmeligheden. Begge parter skal have den samme hovedhemmelighed, ellers vil forbindelsen mislykkes. Dette forhindrer en kryptoanalytiker i at bruge sessions-id'et til at få uautoriseret adgang. De tilfældige numeriske sekvenser i ClientHello- og ServerHello -meddelelserne sikrer, at den genererede sessionsnøgle er forskellig fra den tidligere forbindelses sessionsnøgle. I RFC kaldes denne type håndtryk stenografi .

  1. Forhandlingsfase: [26]
    • Klienten sender en ClientHello- meddelelse , der angiver den seneste version af den understøttede TLS-protokol, et tilfældigt tal og en liste over understøttede krypterings- og komprimeringsmetoder, der er egnede til at arbejde med TLS; Den tidligere forbindelses sessions-id føjes også til beskeden .
    • Serveren svarer med en ServerHello- meddelelse, der indeholder: protokolversionen valgt af serveren, et tilfældigt tal sendt af klienten, en passende krypterings- og komprimeringsalgoritme fra den liste, som klienten leverer. Hvis serveren kender sessions-id'et , tilføjer den samme session-id til ServerHello- meddelelsen . Dette er et signal til klienten om, at genoptagelsen af ​​den forrige session kan bruges. Hvis serveren ikke genkender sessions-id'et , tilføjer den en anden værdi til ServerHello- meddelelsen i stedet for session-id'et . For klienten betyder det, at den genoptaget forbindelse ikke kan bruges. Således skal serveren og klienten have samme hovedhemmelige og tilfældige numre for at generere en sessionsnøgle;
  2. Serveren sender en ChangeCipherSpec- meddelelse , der angiver, at alle efterfølgende oplysninger vil blive krypteret ved hjælp af den algoritme, der er indstillet under håndtrykket ved hjælp af den delte hemmelighed. Disse er meddelelser på rekordniveau og er derfor af type 20, ikke 22;
    • Serveren sender en krypteret Færdig besked , der indeholder hash og MAC genereret fra de tidligere håndtryk beskeder;
    • Klienten forsøger at dekryptere serverens Færdig - meddelelse og verificere hash og MAC. Hvis dekrypteringen eller verifikationsprocessen mislykkes, betragtes håndtrykket som en fejl, og forbindelsen skal afbrydes;
  3. Klienten sender en ChangeCipherSpec- meddelelse , der angiver, at alle efterfølgende oplysninger vil blive krypteret ved hjælp af håndtryksalgoritmen, ved hjælp af den delte hemmelighed.
    • Klienten sender sin krypterede Færdig- meddelelse ;
    • Serveren forsøger på samme måde at dekryptere klientens Færdig -meddelelse og kontrollere hash og MAC;
  4. Fra dette øjeblik betragtes bekræftelsen af ​​kommunikationen som afsluttet, protokollen er etableret. Alt efterfølgende pakkeindhold kommer med type 23, og alle data vil blive krypteret.

Ud over præstationsfordelene [27] kan forbindelsesgenoptagelsesalgoritmen bruges til at implementere single sign -on, da det er garanteret, at den oprindelige session, ligesom enhver genoptaget session, initieres af den samme klient ( RFC 5077 ). Dette er især vigtigt for implementeringen af ​​FTPS -protokollen, som ellers ville være sårbar over for et man-in-the-middle-angreb, hvor en angriber kunne opsnappe indholdet af dataene ved genforbindelse [28] .

Sessionsmandater

RFC 5077 udvider TLS ved at bruge sessionsbilletter i stedet for session-id'er .  Den specificerer, hvordan man genoptager en TLS-session uden at kræve sessions-id'et for den forrige session, hvis tilstand er gemt på TLS-serveren.

Når du bruger sessionslegitimationsoplysninger, gemmer TLS-serveren sessionstilstanden i sessionsbilletten og sender billetten til TLS-klienten til lagring. Klienten genoptager TLS-sessionen ved at sende en sessionsbillet til serveren, og serveren genoptager TLS-sessionen i henhold til de specifikke sessionsparametre, der er gemt i den modtagne billet. Sessionsbilletten er krypteret, autentificeret til serveren i krypteret form, og serveren kontrollerer gyldigheden af ​​billetten, før dens indhold bruges.

En af svaghederne ved denne metode er, at kun AES128-CBC-SHA256-metoden altid bruges til at kryptere og autentificere de transmitterede sessionslegitimationsoplysninger, uanset hvilke TLS-parametre der vælges og bruges til selve TLS-forbindelsen [29] . Det betyder, at information om TLS-sessionen (gemt i sessionsbilletten) ikke er så godt beskyttet som i selve TLS-sessionen. Af særlig bekymring er lagring af OpenSSL-nøgler i applikationskonteksten (SSL_CTX) i applikationens levetid, hvilket forhindrer dem i at blive gentastet fra AES128-CBC-SHA256-sessionslegitimationsoplysninger uden at nulstille hele applikationens OpenSSL-kontekst (hvilket er sjældent, fejl- tilbøjelig, og kræver ofte manuel indgriben). administrator) [30] [31] .

CRIME and BREACH angreb

Forfatterne af BEAST-angrebet er også skaberne af det nyere CRIME-angreb, som kunne gøre det muligt for en angriber at gendanne indholdet af en webcookie, når han bruger datakomprimering sammen med TLS. [32] [33] Når du bruger hemmelige autentificeringscookies til at gendanne indholdet , kan en angriber kapre sessionen i en autentificeret websession.

Algoritmer brugt i TLS

Følgende algoritmer er tilgængelige i den aktuelle version af protokollen:

Algoritmer kan suppleres afhængigt af protokollens version. Før TLS 1.2 var følgende symmetriske krypteringsalgoritmer også tilgængelige, men de blev fjernet som usikre: RC2 , IDEA , DES [34] .

Sammenligning med jævnaldrende

Et anvendelsesområde for en TLS-forbindelse er forbindelsen af ​​værter i et virtuelt privat netværk . Ud over TLS kan IPSec -protokolpakken og SSH -forbindelsen også bruges . Hver af disse tilgange til implementering af et virtuelt privat netværk har sine egne fordele og ulemper [35] .

  1. TLS/SSL
    • Fordele:
      • Usynlig for protokoller på højere niveau;
      • Popularitet for brug i internetforbindelser og e-handelsapplikationer;
      • Mangel på en permanent forbindelse mellem serveren og klienten;
      • Giver dig mulighed for at oprette en tunnel til applikationer, der bruger TCP , såsom e-mail, programmeringsværktøjer osv.
    • Fejl:
      • Kan ikke bruges med UDP- og ICMP -protokoller ;
      • Behovet for at spore forbindelsens tilstand;
      • Yderligere softwarekrav til TLS-support.
  2. IPsec
    • Fordele:
      • Sikkerheden og sikkerheden af ​​databeskyttelsesprotokollen er blevet testet og bevist, siden protokollen er blevet vedtaget som en internetstandard;
      • Arbejder på det øverste lag af netværksprotokollen og kryptering af data over netværksprotokollaget.
    • Fejl:
      • Kompleksitet af implementering, hvilket skaber potentiale for sårbarheder;
      • Yderligere krav til netværksudstyr (routere osv.);
      • Der er mange forskellige implementeringer, som ikke altid interagerer korrekt med hinanden.
  3. SSH
    • Fordele:
      • Giver dig mulighed for at oprette en tunnel til applikationer, der bruger TCP/IP , såsom e-mail, programmeringsværktøjer osv.;
      • Sikkerhedslaget er usynligt for brugeren.
    • Fejl:
      • Svært at bruge i netværk med mange gateways såsom routere eller firewalls ;
      • Stor belastning på intranettrafikken;
      • Kan ikke bruges med UDP- og ICMP -protokoller .
      • Har ikke en PKI (PKI baseret på DNSSEC er ikke meget brugt).

CA'er

TLS-certifikater udstedes af CA'er. Certificeringscentres funktion er at verificere brugeren og certificere ægtheden af ​​ressourcen. Der er tusindvis af CA'er, hvoraf nogle har gratis tilbud.

Se også

Noter

  1. ↑ STATSSTANDARD STB 34.101.65-2014
  2. ↑ T. Dierks, E. Rescorla. Transport Layer Security (TLS) Protocol, version 1.2 (august 2008). Arkiveret fra originalen den 9. februar 2012. ; STATSSTANDARD STB 34.101.65-2014
  3. ↑ SSL-protokollen: Version 3.0 Arkiveret 28. november 2011 på Wayback Machine Netscapes endelige SSL 3.0-udkast (18. november 1996)
  4. ↑ Oversigt over SSL/TLS-kryptering Microsoft TechNet . Opdateret 31. juli 2003.
  5. ↑ SSL/TLS i detaljer Microsoft TechNet . Opdateret 31. juli 2003.
  6. ↑ 1 2 3 Bright, Peter Apple, Google, Microsoft og Mozilla går sammen for at afslutte TLS 1.0 (17. oktober 2018). Hentet 17. oktober 2018. Arkiveret fra originalen 17. oktober 2018.
  7. ↑ Thomas YC Woo, Raghuram Bindignavle, Shaowen Su og Simon S. Lam , SNP: En grænseflade til sikker netværksprogrammering Proceedings USENIX Summer Technical Conference, juni 1994
  8. ↑ Oppliger, Rolf. Introduktion // SSL og TLS: Teori og praksis  (neopr.) . — 2. — Artech House, 2016. - S. 13. - ISBN 978-1-60807-999-5 .
  9. ↑ POODLE: SSLv3 sårbarhed (CVE-2014-3566) . Dato for adgang: 21. oktober 2014. Arkiveret fra originalen 5. december 2014.
  10. ↑ Laura K. Gray. Datoændring for migrering fra SSL og tidlig TLS . Payment Card Industry Security Standards Council blog (18. december 2015). Hentet 5. april 2018. Arkiveret fra originalen 20. december 2015.
  11. ↑ Transport Layer Security (TLS) Protocol Version 1.1 (april 2006). Arkiveret fra originalen den 24. december 2017.
  12. ↑ Retningslinjer for udvælgelse, konfiguration og brug af Transport Layer Security (TLS) implementeringer 67. National Institute of Standards and Technology (april 2014). Hentet 7. maj 2014. Arkiveret fra originalen 8. maj 2014.
  13. ↑ "Færdig" afsnit 7.4.9. RFC 5246 .
  14. ↑ NSS 3.29 release notes . Mozilla Developer Network (februar 2017). Arkiveret fra originalen den 22. februar 2017.
  15. ↑ Firefox-Notes (60.0  ) . Mozilla . Hentet 10. maj 2018. Arkiveret fra originalen 09. maj 2018.
  16. ↑ ProxySG, ASG og WSS vil afbryde SSL-forbindelser, når klienter, der bruger TLS 1.3, tilgår websteder, der også bruger TLS 1.3 . BlueTouch Online (16. maj 2017). Hentet 11. september 2017. Arkiveret fra originalen 12. september 2017.
  17. ↑ OpenSSL 1.1.1 er udgivet . Matt Caswell (11. september 2018). Hentet 19. december 2018. Arkiveret fra originalen 15. september 2018.
  18. ↑ Hoffman-Andrews, Jacob ETS er ikke TLS, og du bør ikke bruge  det . Electronic Frontier Foundation (26. februar 2019). Hentet 27. februar 2019. Arkiveret fra originalen 26. februar 2019.
  19. ↑ Dan Goodin. Hackere bryder SSL-kryptering, der bruges af millioner af websteder . Registret (19. september 2011). Hentet 7. december 2011. Arkiveret fra originalen 9. februar 2012.
  20. ↑ Eric Rescorla. Forståelse af TLS-genforhandlingsangrebet . Uddannet gætværk (5. november 2009). Hentet 7. december 2011. Arkiveret fra originalen 9. februar 2012.
  21. ↑ McMillan, Robert . Security Pro siger, at nyt SSL-angreb kan ramme mange websteder , PC World  (20. november 2009). Arkiveret fra originalen den 19. januar 2012. Hentet 7. december 2011.
  22. ↑ SSL_CTX_set_options SECURE_RENEGOTIATION (downlink) . OpenSSL Docs (25. februar 2010). Hentet 7. december 2010. Arkiveret fra originalen 9. februar 2012. 
  23. ↑ GnuTLS 2.10.0 udgivet . GnuTLS release notes (25. juni 2010). Hentet 7. december 2011. Arkiveret fra originalen 9. februar 2012.
  24. ↑ NSS 3.12.6 release notes . NSS release notes (3. marts 2010). Hentet 24. juli 2011. Arkiveret fra originalen 6. marts 2012.
  25. ↑ Forskellige. IE SSL-sårbarhed (utilgængeligt link) . Uddannet gætværk (10. august 2002). Hentet 7. december 2010. Arkiveret fra originalen 9. februar 2012. 
  26. ↑ http://www.ict.kth.se/courses/IK1550/Sample-papers/2G1305_Assignment_Asa_Pehrsson_050908.pdf Arkiveret fra originalen den 9. februar 2012. Figur 3
  27. ↑ A. Pehhrson. Genoptagelse af TLS-sessions indvirkning på HTTP-ydeevne (marts 2008). Arkiveret fra originalen den 9. februar 2012.
  28. ↑ vsftpd-2.1.0 udgivet Arkiveret 7. juli 2012 på Wayback Machine Brug af TLS-session genoptage til FTPS-dataforbindelsesgodkendelse. Hentet 2009-04-28.
  29. ↑ Daignière, Florent TLS "Secrets": Whitepaper, der præsenterer sikkerhedsimplikationerne af implementeringen af ​​sessionsbilletter (RFC 5077) som implementeret i OpenSSL (link ikke tilgængeligt) . Matta Consulting Limited. Hentet 7. august 2013. Arkiveret fra originalen 6. august 2013. 
  30. ↑ Daignière, Florent TLS "Hemmeligheder": Hvad alle har glemt at fortælle dig... (downlink) . Matta Consulting Limited. Hentet 7. august 2013. Arkiveret fra originalen 5. august 2013. 
  31. ↑ Langley, Adam Sådan fejler du TLS videre hemmeligholdelse . imperialviolet.org (27. juni 2013). Dato for adgang: 31. januar 2014. Arkiveret fra originalen 8. august 2013.
  32. ↑ Dan Goodin. Knæk i internettets grundlag for tillid tillader HTTPS-sessionkapring . Ars Technica (13. september 2012). Dato for adgang: 31. juli 2013. Arkiveret fra originalen 1. august 2013.
  33. ↑ CRIME Attack bruger kompressionsforhold for TLS-anmodninger som sidekanal til at kapre sikre sessioner (13. september 2012). Hentet: 13. september 2012.
  34. ↑ Eric Rescorla. TLS 1.2 Opdatering  . 70 IETF-sager. - "Andre ændringer ... Fjernet RC2, DES og IDEA." Hentet 3. januar 2018. Arkiveret fra originalen 28. marts 2016.
  35. ↑ OM Dahl. Begrænsninger og forskelle ved at bruge IPsec, TLS/SSL eller SSH som VPN-løsning (oktober 2004). Arkiveret fra originalen den 9. februar 2012.

Links