TLS

TLS ( anglicky  transport layer security  - Transport Layer Security Protocol [1] ), stejně jako jeho předchůdce SSL ( anglicky  secure sockets layer  - vrstva bezpečných soketů), jsou kryptografické protokoly , které zajišťují bezpečný přenos dat mezi uzly na internetu [2] . TLS a SSL používají asymetrické šifrování pro ověřování, symetrické šifrování pro soukromí a ověřovací kódy zpráv pro zachování integrity zpráv.

Tento protokol je široce používán v internetových aplikacích , jako jsou webové prohlížeče , e-mail , instant messaging a Voice over IP (VoIP) .

Protokol TLS je založen na specifikaci protokolu SSL verze 3.0 vyvinuté společností Netscape Communications [3] . Standard TLS je nyní vyvíjen IETF . Poslední aktualizace protokolu byla v RFC 5246 (srpen 2008) a RFC 6176 (březen 2011).

Popis

TLS umožňuje aplikacím klient-server komunikovat po síti takovým způsobem, že nemůže dojít k odposlechu paketů a neoprávněnému přístupu .

Protože většinu komunikačních protokolů lze použít s nebo bez TLS (nebo SSL), musíte při navazování spojení výslovně sdělit serveru, zda chce klient navázat TLS. Toho lze dosáhnout buď použitím jednotného čísla portu , na kterém je připojení vždy navázáno pomocí TLS (jako port 443 pro HTTPS ), nebo použitím vlastního portu a speciálního příkazu ze strany klienta na server pro přepnutí připojení na TLS pomocí speciálních protokolových mechanismů (jako je STARTTLS pro e-mailové protokoly ). Jakmile se klient a server dohodnou na používání TLS, musí vytvořit zabezpečené připojení. To se provádí pomocí postupu handshaking [4] [5] . Během tohoto procesu se klient a server dohodnou na různých parametrech potřebných k vytvoření zabezpečeného připojení.

Hlavní kroky v postupu pro vytvoření zabezpečené komunikační relace:

Tím je proces podání ruky dokončen. Mezi klientem a serverem je navázáno zabezpečené spojení, data přenášená přes něj jsou šifrována a dešifrována pomocí symetrického kryptosystému, dokud není spojení dokončeno.

Pokud narazíte na problémy s některým z výše uvedených kroků, může dojít k selhání handshake a nemusí být navázáno zabezpečené připojení.

Historie a verze

Protokoly SSL a TLS
Protokol Datum publikace Stát
SSL 1.0 nezveřejněno nezveřejněno
SSL 2.0 1995 Zastaralé v roce 2011 ( RFC 6176 )
SSL 3.0 1996 Zastaralé v roce 2015 ( RFC 7568 )
TLS 1.0 1999 Zastaráno v roce 2020 [6]
TLS 1.1 2006 Zastaráno v roce 2020 [6]
TLS 1.2 2008
TLS 1.3 2018

První pokusy o implementaci šifrovaných síťových soketů byly provedeny v roce 1993 [7] . Původní protokoly SSL byly vyvinuty společností Netscape: verze 1.0 nebyla kvůli řadě nedostatků publikována, verze 2.0 byla představena v roce 1995 a nahrazena verzí 3.0 v roce 1996 [8] . SSL 3.0 byl kompletní revizí protokolu Paulem Kocherem a přispěvateli Netscape Philem Karltonem a Alanem Freierem s přispěním od Consensus Development. Následující verze SSL a TLS jsou založeny na SSL 3.0. Návrh normy z roku 1996 byl publikován jako RFC 6101 IETF . Použití SSL 2.0 bylo ukončeno v roce 2011 s vydáním RFC 6176 . V roce 2014 byl navržen útok POODLE proti blokovým šifrám SSL 3.0 a jediná podporovaná proudová šifra, RC4 , měla jiné bezpečnostní problémy, protože byla používána [9] . V červnu 2015 byla podpora SSL 3.0 ukončena ( RFC 7568 ).

TLS 1.0 se objevil v roce 1999 jako aktualizace SSL 3.0 a je popsán v RFC 2246 . V roce 2018 PCI DSS naléhala na korporace, aby opustily TLS 1.0 [10] a v říjnu 2018 největší hráči na trhu prohlížečů a OS ( Apple , Google, Microsoft , Mozilla ) oznámili, že v březnu přestanou podporovat TLS verze 1.0 a 1.1 2020 [6] .

TLS 1.1 byl popsán v RFC 4346 v dubnu 2006 [11] . Do TLS 1.0 přidal řadu ochran proti útokům na šifrovací režimy CBC a chybám vyplnění velikosti bloku , začal používat explicitní inicializační vektor a registraci číselných kódů pro parametry v IANA [12] .

TLS 1.2 se objevil v srpnu 2008 jako aktualizace na verzi 1.1, popsanou v RFC 5246 . Zastaralé kryptografické hašovací funkce MD5 a SHA-1 byly zakázány (nahrazeny SHA-256), byl vylepšen mechanismus pro odsouhlasení seznamů podporovaných metod stranami, byly zavedeny metody AEAD ( GCM a CCM pro AES ) [13] .

V březnu 2011 zakázal RFC 6176 zpětnou kompatibilitu se staršími verzemi SSL ve všech protokolech TLS.

Nejnovější aktualizace byla TLS 1.3, popsaná v srpnu 2018 v RFC 8446 . Tato verze oddělovala procesy shody klíčů, autentizace a šifrovací sady; slabé a řídké eliptické křivky, haše MD5 a SHA-224 jsou zakázány; zaveden povinný digitální podpis; implementován HKDF a semi-efemérní DH systém. Namísto mechanismu obnovy bylo použito PSK a systém pověření, byly zrychleny procesy připojení (1-RTT a 0-RTT) a bylo postulováno dokonalé dopředné utajení klíčů relace prostřednictvím protokolů generování DH a ECDH. Takové zastaralé a nezabezpečené možnosti jako komprese dat , opětovné vyjednávání, šifry bez ověřování zpráv (tj. režimy bez AEAD ), netajné metody pro získávání klíčů relace (RSA, statické skupiny DH, DHE), pomocné zprávy (Change Cipher Spec, HELLO , pole délky AD). Ukončena zpětná kompatibilita s SSL nebo RC4. Objevila se streamová šifra ChaCha20 s MAC kódem Poly1305 , podpisy Ed25519 a Ed448, x25519 a x448 protokoly pro výměnu klíčů .

Podpora pro TLS 1.3 se objevila ve službách Mozilla Network Security Services (NSS) v únoru 2017 (součástí Firefoxu 60) [14] [15] . Google Chrome v roce 2017 na chvíli podporoval TLS 1.3, ale zakázal jej ve prospěch webového serveru Blue Coat [16] . OpenSSL přidal tuto verzi ve verzi 1.1.1 ze září 2018 [17] . Electronic Frontier Foundation požadovala TLS 1.3 a varovala před záměnou s podobným hybridním kleptografickým protokolem ETS nebo eTLS (záměrně vynechala důležité bezpečnostní prvky z TLS 1.3) [18] .

Zabezpečení

TLS má mnoho bezpečnostních opatření:

Zranitelnost protokolu TLS 1.0, která byla považována za teoretickou, byla prokázána na konferenci Ekoparty v září 2011. Demo zahrnovalo dešifrování souborů cookie používaných k ověření uživatele [19] .

Chyba zabezpečení ve fázi opětovného připojení, objevená v srpnu 2009, umožnila kryptoanalytikovi schopnému prolomit https připojení přidávat vlastní požadavky do zpráv odeslaných z klienta na server [20] . Protože kryptoanalytik nemůže dešifrovat komunikaci mezi serverem a klientem, tento typ útoku se liší od standardního útoku typu man-in-the-middle . Pokud uživatel nevěnuje pozornost indikaci prohlížeče, že relace je bezpečná (obvykle ikona visacího zámku), lze zranitelnost využít k útoku typu man-in-the-middle [21] . K odstranění této chyby zabezpečení bylo navrženo jak na straně klienta, tak na straně serveru přidat informace o předchozím připojení a zkontrolovat, kdy je připojení obnoveno. Toto bylo představeno v RFC 5746 a je také implementováno v posledních verzích OpenSSL [22] a dalších knihovnách [23] [24] .

Existují také možnosti útoku založené přímo na softwarové implementaci protokolu, nikoli na jeho algoritmu [25] .

Postup handshakingu v TLS podrobně

Podle protokolu TLS si aplikace vyměňují záznamy, které zapouzdřují (ukládají do sebe) informace, které musí být přenášeny. Každý ze záznamů může být komprimován, doplněn, šifrován nebo identifikován pomocí MAC (Message Authentication Code) v závislosti na aktuálním stavu připojení (stavu protokolu). Každá položka v TLS obsahuje následující pole: Typ obsahu (definuje typ obsahu položky), Verze (pole udávající verzi protokolu TLS) a Délka (pole udávající délku paketu).

Když je připojení právě navázáno, interakce prochází protokolem TLS handshake, jehož typ obsahu je 22.

Jednoduché handshaking v TLS

Následuje jednoduchý příklad nastavení připojení, kde je server (ale ne klient) autentizován svým certifikátem.

  1. Fáze vyjednávání:
    • Klient odešle zprávu ClientHello označující nejnovější verzi podporovaného protokolu TLS, náhodné číslo a seznam podporovaných šifrovacích sad (metody šifrování, anglické šifrovací sady) vhodných pro práci s TLS;
    • Server odpoví zprávou ServerHello obsahující: verzi protokolu vybranou serverem, náhodné číslo vygenerované serverem, vybranou šifrovací sadu ze seznamu poskytnutého klientem;
    • Server odešle zprávu Certificate obsahující digitální certifikát serveru (v závislosti na šifrovacím algoritmu může být tento krok přeskočen);
    • Pokud data přenášená serverem nestačí k vygenerování sdíleného symetrického tajného klíče v rámci vybrané šifrovací sady, server odešle zprávu ServerKeyExchange obsahující potřebná data. Například v ServerKeyExchange se přenáší serverová část výměny pro protokol Diffie-Hellman;
    • Server odešle zprávu ServerHelloDone identifikující konec prvního kola navazování spojení;
    • Klient odpoví zprávou ClientKeyExchange , která obsahuje klientskou část protokolu Diffie-Hellman nebo tajemství ( PreMasterSecret ) zašifrované veřejným klíčem z certifikátu serveru ;
    • Klient a server pomocí klíče PreMasterSecret a náhodně generovaných čísel vypočítají sdílený tajný klíč. Všechny ostatní informace o klíči relace budou odvozeny ze sdíleného tajemství;
  2. Klient odešle zprávu ChangeCipherSpec oznamující, že všechny následné informace budou zašifrovány pomocí algoritmu handshake pomocí sdíleného tajného klíče. Toto je zpráva na úrovni záznamu, a proto má typ 20, nikoli 22;
    • Klient odešle zprávu Dokončeno , která obsahuje hash a MAC generované z předchozích zpráv handshake;
    • Server se pokusí dešifrovat klientovu zprávu Dokončeno a ověřit hash a MAC. Pokud proces dešifrování nebo ověření selže, je handshake považováno za selhání a spojení musí být ukončeno;
  3. Server odešle ChangeCipherSpec a zašifrovanou zprávu Dokončeno a klient zase provede dešifrování a ověření.

Od tohoto okamžiku je potvrzení komunikace považováno za dokončené, protokol je založen. Veškerý obsah následujících paketů je dodáván s typem 23 a všechna data budou šifrována.

Handshaking s autentizací klienta

Tento příklad ukazuje úplnou autentizaci klienta (kromě autentizace serveru jako v předchozím příkladu) pomocí výměny certifikátů mezi serverem a klientem.

  1. Fáze vyjednávání:
    • Klient odešle zprávu ClientHello označující nejnovější verzi podporovaného protokolu TLS, náhodné číslo a seznam podporovaných metod šifrování a komprese vhodných pro práci s TLS;
    • Server odpoví zprávou ServerHello obsahující: verzi protokolu zvolenou serverem, náhodné číslo zaslané klientem, vhodný šifrovací a kompresní algoritmus ze seznamu poskytnutého klientem;
    • Server odešle zprávu Certificate obsahující digitální certifikát serveru (v závislosti na šifrovacím algoritmu může být tento krok přeskočen);
    • Server odešle zprávu CertificateRequest obsahující žádost o klientský certifikát pro vzájemné ověření;
    • Klient odešle zprávu Certificate , která obsahuje digitální certifikát klienta;
    • Server odešle zprávu ServerHelloDone identifikující konec handshake;
    • Klient odpoví zprávou ClientKeyExchange obsahující veřejný klíč PreMasterSecret nebo nic (opět závisí na šifrovacím algoritmu);
    • Klient a server pomocí klíče PreMasterSecret a náhodně generovaných čísel vypočítají sdílený tajný klíč. Všechny ostatní informace o klíči budou získány ze sdíleného tajného klíče (a náhodných hodnot generovaných klientem a serverem);
  2. Klient odešle zprávu ChangeCipherSpec oznamující, že všechny následné informace budou zašifrovány pomocí algoritmu handshake pomocí sdíleného tajného klíče. Jedná se o zprávy na úrovni záznamů a jsou tedy typu 20, nikoli 22;
    • Klient odešle zprávu Dokončeno , která obsahuje hash a MAC generované z předchozích zpráv handshake;
    • Server se pokusí dešifrovat klientovu zprávu Dokončeno a ověřit hash a MAC. Pokud se proces dešifrování nebo ověření nezdaří, je handshake považováno za selhání a připojení musí být ukončeno.
  3. Server odešle ChangeCipherSpec a zašifrovanou zprávu Dokončeno a klient zase provede dešifrování a ověření.

Od tohoto okamžiku je potvrzení komunikace považováno za dokončené, protokol je založen. Veškerý obsah následujících paketů je dodáván s typem 23 a všechna data budou šifrována.

Obnovení připojení TLS

Asymetrické šifrovací algoritmy používané ke generování klíče relace jsou obvykle drahé z hlediska výpočetního výkonu. Aby se zabránilo jejich opakování při obnovení připojení, TLS vytvoří speciální značku handshake, která se používá k obnovení připojení. V tomto případě během normálního handshake klient přidá identifikátor předchozí relace relace do zprávy ClientHello . Klient přiřadí ID relace k IP adrese serveru a TCP portu, takže při připojení k serveru lze použít všechny parametry předchozího připojení. Server porovnává ID relace předchozí relace s parametry připojení, jako je použitý šifrovací algoritmus a hlavní tajný klíč. Obě strany musí mít stejné hlavní tajemství, jinak spojení selže. To zabraňuje kryptoanalytikovi použít ID relace k získání neoprávněného přístupu. Náhodné číselné sekvence ve zprávách ClientHello a ServerHello zajišťují, že vygenerovaný klíč relace se liší od klíče relace předchozího připojení. V RFC se tento typ handshake nazývá zkratka .

  1. Fáze vyjednávání: [26]
    • Klient odešle zprávu ClientHello označující nejnovější verzi podporovaného protokolu TLS, náhodné číslo a seznam podporovaných metod šifrování a komprese vhodných pro práci s TLS; Do zprávy je také přidáno ID relace předchozího připojení .
    • Server odpoví zprávou ServerHello obsahující: verzi protokolu zvolenou serverem, náhodné číslo zaslané klientem, vhodný šifrovací a kompresní algoritmus ze seznamu poskytnutého klientem. Pokud server zná ID relace , přidá stejné ID relace do zprávy ServerHello . To je signál pro klienta, že lze použít obnovení předchozí relace. Pokud server nerozpozná ID relace , přidá do zprávy ServerHello místo id relace jinou hodnotu . Pro klienta to znamená, že obnovené připojení nelze použít. Server a klient tedy musí mít stejné hlavní tajemství a náhodná čísla, aby bylo možné vygenerovat klíč relace;
  2. Server odešle zprávu ChangeCipherSpec oznamující, že všechny následné informace budou zašifrovány pomocí algoritmu nastaveného během handshake pomocí sdíleného tajného klíče. Jedná se o zprávy na úrovni záznamů a jsou tedy typu 20, nikoli 22;
    • Server odešle zašifrovanou zprávu Dokončeno , která obsahuje hash a MAC generované z předchozích zpráv handshake;
    • Klient se pokusí dešifrovat zprávu Dokončeno serveru a ověřit hash a MAC. Pokud proces dešifrování nebo ověření selže, je handshake považováno za selhání a spojení musí být ukončeno;
  3. Klient odešle zprávu ChangeCipherSpec oznamující, že všechny následné informace budou zašifrovány pomocí algoritmu handshake pomocí sdíleného tajného klíče.
    • Klient odešle svou zašifrovanou zprávu Dokončeno ;
    • Server se podobně pokusí dešifrovat klientovu zprávu Dokončeno a zkontrolovat hash a MAC;
  4. Od tohoto okamžiku je potvrzení komunikace považováno za dokončené, protokol je založen. Veškerý obsah následujících paketů je dodáván s typem 23 a všechna data budou šifrována.

Kromě výkonnostních výhod [27] lze k implementaci jednotného přihlášení použít algoritmus obnovení připojení , protože je zaručeno, že původní relace, stejně jako jakákoli obnovená relace, je iniciována stejným klientem ( RFC 5077 ). To je důležité zejména pro implementaci protokolu FTPS , který by byl jinak zranitelný vůči útoku typu man-in-the-middle, kdy by útočník mohl zachytit obsah dat při opětovném připojení [28] .

Mandáty zasedání

RFC 5077 rozšiřuje TLS tím , že místo ID relací používá lístky relace .  Určuje, jak obnovit relaci TLS, aniž by bylo vyžadováno ID relace předchozí relace, jejíž stav je uložen na serveru TLS.

Při použití přihlašovacích údajů relace uloží server TLS stav relace do lístku relace a odešle lístek klientovi TLS k uložení. Klient obnoví relaci TLS odesláním lístku relace na server a server obnoví relaci TLS podle specifických parametrů relace uložených v přijatém lístku. Lístek relace je zašifrován, ověřen na serveru v zašifrované podobě a server před použitím jeho obsahu zkontroluje platnost lístku.

Jednou ze slabin této metody je, že k šifrování a autentizaci přenášených přihlašovacích údajů relace se vždy používá pouze metoda AES128-CBC-SHA256, bez ohledu na to, jaké parametry TLS jsou zvoleny a použity pro samotné TLS spojení [29] . To znamená, že informace o relaci TLS (uložené v lístku relace) nejsou tak dobře chráněny jako v samotné relaci TLS. Zvláště důležité je ukládání klíčů OpenSSL v kontextu aplikace (SSL_CTX) po celou dobu životnosti aplikace, což zabraňuje jejich opětovnému klíčování z přihlašovacích údajů relace AES128-CBC-SHA256 bez resetování kontextu OpenSSL celé aplikace (což je vzácné, chyba- náchylný a často vyžaduje ruční zásah).správce) [30] [31] .

ZLOČIN a PORUŠENÍ útoky

Autoři útoku BEAST jsou také tvůrci novějšího útoku CRIME, který by mohl útočníkovi umožnit obnovit obsah webového cookie při použití komprese dat spolu s TLS. [32] [33] Při použití ověřovacích tajných souborů cookie k obnovení obsahu může útočník unést relaci v ověřené webové relaci.

Algoritmy používané v TLS

V aktuální verzi protokolu jsou k dispozici následující algoritmy:

Algoritmy mohou být doplněny v závislosti na verzi protokolu. Před TLS 1.2 byly k dispozici také následující symetrické šifrovací algoritmy, které však byly odstraněny jako nezabezpečené: RC2 , IDEA , DES [34] .

Srovnání s vrstevníky

Jednou z oblastí použití pro připojení TLS je připojení hostitelů ve virtuální privátní síti . Kromě TLS lze také použít sadu protokolů IPSec a připojení SSH . Každý z těchto přístupů k implementaci virtuální privátní sítě má své výhody a nevýhody [35] .

  1. TLS/SSL
    • výhody:
      • Neviditelný pro protokoly vyšší úrovně;
      • Popularita použití v internetových připojeních a aplikacích elektronického obchodování;
      • Nedostatek trvalého spojení mezi serverem a klientem;
      • Umožňuje vytvořit tunel pro aplikace, které používají TCP , jako je e-mail, programovací nástroje atd.
    • nedostatky:
      • Nelze použít s protokoly UDP a ICMP ;
      • Potřeba sledovat stav připojení;
      • Další softwarové požadavky pro podporu TLS.
  2. IPsec
    • výhody:
      • Bezpečnost a zabezpečení protokolu ochrany dat byla testována a ověřena od doby, kdy byl protokol přijat jako internetový standard;
      • Práce na nejvyšší vrstvě síťového protokolu a šifrování dat nad vrstvou síťového protokolu.
    • nedostatky:
      • Složitost implementace, vytváření potenciálu pro zranitelnosti;
      • Další požadavky na síťová zařízení (směrovače atd.);
      • Existuje mnoho různých implementací, které spolu ne vždy správně interagují.
  3. SSH
    • výhody:
      • Umožňuje vytvořit tunel pro aplikace využívající TCP/IP , jako je e-mail, programovací nástroje atd.;
      • Bezpečnostní vrstva je pro uživatele neviditelná.
    • nedostatky:
      • Obtížné použití v sítích s mnoha branami, jako jsou směrovače nebo firewally ;
      • Velké zatížení intranetového provozu;
      • Nelze použít s protokoly UDP a ICMP .
      • Nemá PKI (PKI založené na DNSSEC se příliš nepoužívá).

CA

Certifikáty TLS vydávají CA. Funkcí certifikačních center je ověřit uživatele a certifikovat pravost zdroje. Existují tisíce CA, z nichž některé mají bezplatné nabídky.

Viz také

Poznámky

  1. ↑ STÁTNÍ STANDARD STB 34.101.65-2014
  2. ↑ T. Dierks, E. Rescorla. Protokol TLS (Transport Layer Security), verze 1.2 (srpen 2008). Archivováno z originálu 9. února 2012. ; STÁTNÍ STANDARD STB 34.101.65-2014
  3. ↑ Protokol SSL: Verze 3.0 Archivováno 28. listopadu 2011 na konečném návrhu SSL 3.0 od společnosti Wayback Machine Netscape (18. listopadu 1996)
  4. ↑ Přehled šifrování SSL/TLS Microsoft TechNet . Aktualizováno 31. července 2003.
  5. ↑ SSL/TLS podrobně Microsoft TechNet . Aktualizováno 31. července 2003.
  6. ↑ 1 2 3 Bright, Peter Apple, Google, Microsoft a Mozilla se spojili, aby ukončili TLS 1.0 (17. října 2018). Získáno 17. října 2018. Archivováno z originálu 17. října 2018.
  7. ↑ Thomas YC Woo, Raghuram Bindignavle, Shaowen Su a Simon S. Lam , SNP: Rozhraní pro bezpečné síťové programování Sborník Letní technická konference USENIX, červen 1994
  8. ↑ Oppliger, Rolf. Úvod // SSL a TLS: Teorie a praxe  (neopr.) . — 2. — Artechův dům, 2016. - S. 13. - ISBN 978-1-60807-999-5 .
  9. ↑ POODLE: Zranitelnost SSLv3 (CVE-2014-3566) . Datum přístupu: 21. října 2014. Archivováno z originálu 5. prosince 2014.
  10. ↑ Laura K. Grayová. Změna data pro migraci z SSL a dřívějšího TLS . Blog Rady pro bezpečnostní standardy odvětví platebních karet (18. prosince 2015). Získáno 5. dubna 2018. Archivováno z originálu 20. prosince 2015.
  11. ↑ Protokol TLS (Transport Layer Security) verze 1.1 (duben 2006). Archivováno z originálu 24. prosince 2017.
  12. ↑ Pokyny pro výběr, konfiguraci a použití implementací zabezpečení transportní vrstvy (TLS) 67. Národní institut pro standardy a technologie (duben 2014). Získáno 7. 5. 2014. Archivováno z originálu 8. 5. 2014.
  13. ↑ Sekce „Dokončeno“ 7.4.9. RFC 5246 .
  14. ↑ Poznámky k vydání NSS 3.29 . Mozilla Developer Network (únor 2017). Archivováno z originálu 22. února 2017.
  15. ↑ Firefox-Notes (60.0  ) . Mozilla . Staženo 10. 5. 2018. Archivováno z originálu 09. 5. 2018.
  16. ↑ ProxySG, ASG a WSS přeruší připojení SSL, když klienti používající TLS 1.3 přistupují na stránky také používající TLS 1.3 . BlueTouch Online (16. května 2017). Získáno 11. září 2017. Archivováno z originálu 12. září 2017.
  17. ↑ Vydáno OpenSSL 1.1.1 . Matt Caswell (11. září 2018). Získáno 19. prosince 2018. Archivováno z originálu 15. září 2018.
  18. ↑ Hoffman-Andrewsi, Jacob ETS není TLS a neměli byste jej  používat . Electronic Frontier Foundation (26. února 2019). Získáno 27. února 2019. Archivováno z originálu dne 26. února 2019.
  19. ↑ Dan Goodin. Hackeři prolomili šifrování SSL používané miliony webů . The Register (19. září 2011). Získáno 7. prosince 2011. Archivováno z originálu dne 9. února 2012.
  20. ↑ Eric Rescorla. Pochopení útoku TLS Renegotiation Attack . Vzdělaný hádání (5. listopadu 2009). Získáno 7. prosince 2011. Archivováno z originálu dne 9. února 2012.
  21. ↑ McMillan, Robert . Security Pro říká, že nový útok SSL může zasáhnout mnoho webů , PC World  (20. listopadu 2009). Archivováno z originálu 19. ledna 2012. Staženo 7. prosince 2011.
  22. ↑ SSL_CTX_set_options SECURE_RENEGOTIATION (downlink) . Dokumenty OpenSSL (25. února 2010). Získáno 7. prosince 2010. Archivováno z originálu 9. února 2012. 
  23. ↑ Vydán GnuTLS 2.10.0 . Poznámky k vydání GnuTLS (25. června 2010). Získáno 7. prosince 2011. Archivováno z originálu dne 9. února 2012.
  24. ↑ Poznámky k vydání NSS 3.12.6 . Poznámky k vydání NSS (3. března 2010). Získáno 24. července 2011. Archivováno z originálu 6. března 2012.
  25. ↑ Různé. Chyba zabezpečení IE SSL (nedostupný odkaz) . Vzdělaný hádání (10. srpna 2002). Získáno 7. prosince 2010. Archivováno z originálu 9. února 2012. 
  26. ↑ http://www.ict.kth.se/courses/IK1550/Sample-papers/2G1305_Assignment_Asa_Pehrsson_050908.pdf Archivováno z originálu 9. února 2012. Obrázek 3
  27. ↑ A. Pehhrson. Vliv obnovení relace TLS na výkon HTTP (březen 2008). Archivováno z originálu 9. února 2012.
  28. ↑ vsftpd-2.1.0 vydán Archivováno 7. července 2012 na Wayback Machine Pomocí obnovení relace TLS pro ověřování datového připojení FTPS. Získáno 28. 4. 2009.
  29. ↑ Daignière, Florent TLS "Tajemství": Whitepaper představující bezpečnostní důsledky nasazení relačních lístků (RFC 5077), jak jsou implementovány v OpenSSL (odkaz není k dispozici) . Matta Consulting Limited. Získáno 7. srpna 2013. Archivováno z originálu dne 6. srpna 2013. 
  30. ↑ Daignière, Florent TLS „Secrets“: Co vám všichni zapomněli říct... (downlink) . Matta Consulting Limited. Získáno 7. srpna 2013. Archivováno z originálu dne 5. srpna 2013. 
  31. ↑ Langley, Adam Jak zpackat dopředné utajení TLS . imperialviolet.org (27. června 2013). Datum přístupu: 31. ledna 2014. Archivováno z originálu 8. srpna 2013.
  32. ↑ Dan Goodin. Crack in the Internet's foundation of trust umožňuje únos relace HTTPS . Ars Technica (13. září 2012). Datum přístupu: 31. července 2013. Archivováno z originálu 1. srpna 2013.
  33. ↑ CRIME Attack používá kompresní poměr požadavků TLS jako vedlejší kanál k únosu zabezpečených relací (13. září 2012). Staženo: 13. září 2012.
  34. ↑ Eric Rescorla. Aktualizace  TLS 1.2 . 70 Sborník IETF. - "Další změny... Odstraněno RC2, DES a IDEA." Získáno 3. ledna 2018. Archivováno z originálu dne 28. března 2016.
  35. ↑ OM Dahl. Omezení a rozdíly používání IPsec, TLS/SSL nebo SSH jako řešení VPN (říjen 2004). Archivováno z originálu 9. února 2012.

Odkazy