Zabezpečení transportní vrstvy - Transport Layer Security

Transport Layer Security ( TLS ), nástupce dnes již zastaralé Secure Sockets Layer ( SSL ), je kryptografický protokol navržený tak, aby zajišťoval zabezpečení komunikace přes počítačovou síť. Protokol je široce používán v aplikacích, jako je e -mail , rychlé zasílání zpráv a Voice over IP , ale jeho použití jako bezpečnostní vrstvy v HTTPS zůstává nejvíce veřejně viditelné.

Protokol TLS si klade za cíl především zajistit soukromí a integritu dat mezi dvěma nebo více komunikujícími počítačovými aplikacemi. Běží v aplikační vrstvě internetu a sám se skládá ze dvou vrstev: protokolu TLS a protokolů handshake TLS.

TLS je navrhovaný standard Internet Engineering Task Force (IETF), poprvé definovaný v roce 1999, a aktuální verze je TLS 1.3 definovaná v srpnu 2018. TLS navazuje na dřívější specifikace SSL (1994, 1995, 1996) vyvinuté společností Netscape Communications pro přidání protokol HTTPS do webového prohlížeče Navigator .

Popis

Aplikace klient-server používají protokol TLS ke komunikaci v síti způsobem, který je navržen tak, aby se zabránilo odposlouchávání a nedovolené manipulaci .

Protože aplikace mohou komunikovat s TLS (nebo SSL) nebo bez něj, je nutné, aby klient požadoval, aby server nastavil připojení TLS. Jedním z hlavních způsobů, jak toho dosáhnout, je použít pro připojení TLS jiné číslo portu . Například port 80 se obvykle používá pro nešifrovaný provoz HTTP, zatímco port 443 je společný port používaný pro šifrovaný provoz HTTPS . Dalším mechanismem je, aby klient odeslal serveru požadavek specifický pro protokol, aby přepnul připojení na TLS; například zadáním požadavku STARTTLS při použití poštovních a zpravodajských protokolů.

Jakmile se klient a server dohodnou na používání TLS, vyjednají stavové připojení pomocí postupu handshaking . Protokoly používají handshake s asymetrickou šifrou k vytvoření nejen nastavení šifry, ale také sdíleného klíče specifického pro relaci, pomocí kterého je další komunikace šifrována pomocí symetrické šifry . Během tohoto handshake se klient a server dohodnou na různých parametrech použitých k navázání zabezpečení připojení:

  • Handshake začíná, když se klient připojí k serveru s podporou TLS a požaduje zabezpečené připojení a klient předloží seznam podporovaných šifrovacích sad ( šifry a hashovací funkce ).
  • Z tohoto seznamu server vybere funkci šifrování a hash, kterou také podporuje, a upozorní klienta na rozhodnutí.
  • Server pak obvykle poskytuje identifikaci ve formě digitálního certifikátu . Certifikát obsahuje název serveru , důvěryhodnou certifikační autoritu (CA), která ručí za autentičnost certifikátu, a veřejný šifrovací klíč serveru.
  • Před pokračováním klient potvrdí platnost certifikátu.
  • Chcete -li vygenerovat klíče relace používané pro zabezpečené připojení, klient buď:
    • zašifruje náhodné číslo ( PreMasterSecret ) pomocí veřejného klíče serveru a odešle výsledek na server (který by pouze server měl být schopen dešifrovat pomocí svého soukromého klíče); obě strany poté použijí náhodné číslo ke generování jedinečného klíče relace pro následné šifrování a dešifrování dat během relace
    • používá výměnu klíčů Diffie – Hellman k bezpečnému generování náhodného a jedinečného klíče relace pro šifrování a dešifrování, který má další vlastnost dopředného utajení: pokud je v budoucnu odhalen soukromý klíč serveru, nelze jej použít k dešifrování aktuální relace, i když relace je zachycena a zaznamenána třetí stranou.

Tím je podání ruky ukončeno a začíná zabezpečené připojení, které je šifrováno a dešifrováno klíčem relace, dokud se připojení neukončí. Pokud některý z výše uvedených kroků selže, pak handshake TLS selže a připojení se nevytvoří.

TLS a SSL nezapadají úhledně do žádné jedné vrstvy modelu OSI nebo modelu TCP/IP . TLS běží „na vrcholu spolehlivého transportního protokolu (např. TCP)“, což by znamenalo, že je nad transportní vrstvou . Slouží šifrování vyšším vrstvám, což je normálně funkcí prezentační vrstvy . Aplikace však obecně používají TLS, jako by se jednalo o transportní vrstvu, přestože aplikace využívající TLS musí aktivně řídit inicializaci handshake TLS a manipulaci s vyměněnými ověřovacími certifikáty.

Když je zabezpečeno TLS, připojení mezi klientem (např. Webovým prohlížečem) a serverem (např. Wikipedia.org) by mělo mít jednu nebo více z následujících vlastností:

  • Připojení je soukromé (nebo zabezpečené ), protože k šifrování přenášených dat se používá algoritmus symetrických klíčů . Klíče pro toto symetrické šifrování jsou generovány jedinečně pro každé připojení a jsou založeny na sdíleném tajemství, které bylo sjednáno na začátku relace. Server a klient vyjednají podrobnosti o tom, jaký šifrovací algoritmus a kryptografické klíče použít před přenosem prvního bajtu dat (viz níže). Vyjednávání sdíleného tajemství je jak bezpečné (sjednané tajemství není pro odposlechy k dispozici a nemůže jej získat ani útočník, který se umístí doprostřed spojení), tak spolehlivé (žádný útočník nemůže během vyjednávání upravovat komunikaci, aniž by byl detekovány).
  • Totožnost komunikujících stran lze ověřit pomocí kryptografie s veřejným klíčem . Toto ověření je vyžadováno pro server a volitelné pro klienta.
  • Připojení je spolehlivé, protože každá přenášená zpráva obsahuje kontrolu integrity zprávy pomocí ověřovacího kódu zprávy, aby se zabránilo nezjištěné ztrátě nebo změně dat během přenosu.

Kromě výše uvedeného může pečlivá konfigurace TLS poskytovat další vlastnosti související s ochranou osobních údajů, jako je například dopředné utajení , což zajistí, že jakékoli budoucí zpřístupnění šifrovacích klíčů nelze použít k dešifrování jakékoli komunikace TLS zaznamenané v minulosti.

TLS podporuje mnoho různých metod pro výměnu klíčů, šifrování dat a ověřování integrity zpráv. Výsledkem je, že zabezpečená konfigurace TLS zahrnuje mnoho konfigurovatelných parametrů a ne všechny možnosti poskytují všechny vlastnosti související s ochranou osobních údajů popsané ve výše uvedeném seznamu (viz níže uvedené tabulky § Výměna klíčů , § Zabezpečení šifrování a § Integrita dat ).

Byly provedeny pokusy o rozvrácení aspektů zabezpečení komunikace, které se TLS snaží poskytnout, a protokol byl několikrát revidován, aby tyto bezpečnostní hrozby řešil. Vývojáři webových prohlížečů své produkty opakovaně revidovali, aby se chránili před potenciálními nedostatky zabezpečení poté, co byly objeveny (viz historie podpory webových prohlížečů TLS/SSL).

Historie a vývoj

Protokoly SSL a TLS
Protokol Zveřejněno Postavení
SSL 1.0 Nepublikovaný Nepublikovaný
SSL 2.0 1995 Zastaralé v roce 2011 ( RFC  6176 )
SSL 3.0 1996 Zastaralé v roce 2015 (RFC  7568 )
TLS 1.0 1999 Zastaralé v roce 2020 (RFC  8996 )
TLS 1.1 2006 Zastaralé v roce 2020 (RFC  8996 )
TLS 1.2 2008
TLS 1.3 2018

Systém zabezpečené datové sítě

Transport Layer Security Protocol (TLS), spolu s několika dalšími základními platformami zabezpečení sítě, byl vyvinut prostřednictvím společné iniciativy zahájené v srpnu 1986 mezi Národní bezpečnostní agenturou, Národním úřadem pro standardy, Agenturou pro obrannou komunikaci a dvanácti komunikačními a počítačové korporace, které zahájily speciální projekt s názvem Secure Data Network System (SDNS). Program byl popsán v září 1987 na 10. národní konferenci o počítačové bezpečnosti v rozsáhlé sadě publikovaných prací. Inovativní výzkumný program se zaměřil na navrhování příští generace zabezpečené počítačové komunikační sítě a specifikací produktů, které mají být implementovány pro aplikace na veřejném a soukromém internetu. Účelem bylo doplnit rychle se objevující nové internetové standardy OSI, které se posouvají vpřed jak ve vládních profilech americké vlády GOSIP, tak v obrovském mezinárodním úsilí ITU-ISO JTC1. Původně známý jako protokol SP4, byl přejmenován na TLS a následně publikován v roce 1995 jako mezinárodní standard ITU-T X.274 | ISO/IEC 10736: 1995.

Zabezpečené síťové programování

Rané výzkumné snahy o zabezpečení transportní vrstvy zahrnovaly aplikační programovací rozhraní (API) Secure Network Programming (SNP) , které v roce 1993 prozkoumalo přístup k tomu, že API zabezpečené transportní vrstvy se velmi podobá zásuvkám Berkeley , aby se usnadnilo dovybavení již existujících síťových aplikací zabezpečením opatření.

SSL 1.0, 2.0 a 3.0

Netscape vyvinul původní protokoly SSL a Taher Elgamal , vedoucí vědecký pracovník společnosti Netscape Communications v letech 1995 až 1998, byl popisován jako „otec SSL“. SSL verze 1.0 nebyla nikdy veřejně vydána z důvodu závažných bezpečnostních nedostatků v protokolu. Verze 2.0, poté, co byla vydána v únoru 1995, byla rychle objevena, že obsahuje řadu chyb v zabezpečení a použitelnosti. Pro ověřování a šifrování zpráv používalo stejné kryptografické klíče. Měl slabou konstrukci MAC, která používala hashovací funkci MD5 s tajnou předponou, takže byla zranitelná vůči útokům s prodloužením délky. A neposkytovalo to žádnou ochranu ani pro úvodní podání ruky, ani pro explicitní zavření zprávy, což obojí znamenalo, že útoky typu man-in-the-middle mohly zůstat nezjištěny. SSL 2.0 navíc předpokládal jedinou službu a certifikát pevné domény, což je v rozporu s široce používanou funkcí virtuálního hostingu na webových serverech, takže většina webů byla účinně znehodnocena používáním SSL.

Tyto nedostatky si vyžádaly kompletní přepracování protokolu na SSL verze 3.0. Vydáno v roce 1996, bylo vyrobeno Paulem Kocherem ve spolupráci s inženýry Netscape Philem Karltonem a Alanem Freierem, s referenční implementací Christophera Allena a Tima Dierkse z Consensus Development. Novější verze SSL/TLS jsou založeny na SSL 3.0. Návrh SSL 3.0 z roku 1996 publikovala IETF jako historický dokument v RFC  6101 .

SSL 2.0 byl v roce 2011 zastaralý RFC  6176 . V roce 2014 bylo zjištěno, že SSL 3.0 je zranitelný vůči útoku POODLE, který ovlivňuje všechny blokové šifry v SSL; RC4 , jediná nebloková šifra podporovaná protokolem SSL 3.0, je také možné prolomit, jak se používá v SSL 3.0. Podpora SSL 3.0 byla v červnu 2015 ukončena protokolem RFC  7568 .

TLS 1.0

TLS 1.0 byl poprvé definován v RFC  2246 v lednu 1999 jako upgrade SSL verze 3.0 a napsal Christopher Allen a Tim Dierks z Consensus Development. Jak je uvedeno v RFC, „rozdíly mezi tímto protokolem a SSL 3.0 nejsou nijak dramatické, ale jsou dostatečně významné, aby vyloučily interoperabilitu mezi TLS 1.0 a SSL 3.0“. Tim Dierks později napsal, že tyto změny a přejmenování z „SSL“ na „TLS“ byly pro Microsoft gesto šetřící obličej, „takže by to nevypadalo [jako], že IETF byl pouze razítko protokolu Netscape“.

Rada PCI navrhla, aby organizace migrovaly z TLS 1.0 na TLS 1.1 nebo vyšší před 30. červnem 2018. V říjnu 2018 společnosti Apple , Google , Microsoft a Mozilla společně oznámily, že v březnu 2020 zamítnou TLS 1.0 a 1.1.

TLS 1.1

TLS 1.1 byl definován v RFC  4346 v dubnu 2006. Jedná se o aktualizaci z TLS verze 1.0. Mezi významné rozdíly v této verzi patří:

Webové weby kolem roku 2020 široce ukončovaly podporu pro TLS verze 1.0 a 1.1, což znemožnilo přístup k verzím Firefoxu před 24. rokem a Google Chrome před 29. rokem.

TLS 1.2

TLS 1.2 byl definován v RFC  5246 v srpnu 2008. Vychází z dřívější specifikace TLS 1.1. Mezi hlavní rozdíly patří:

  • Kombinace MD5 - SHA-1 v pseudonáhodné funkci (PRF) byla nahrazena SHA-256 s možností použít PRF specifikované v šifrovací sadě .
  • MD5-SHA-1 kombinace v konečném zprávy hash byl nahrazen SHA-256, s možností použití šifrovací sady specifické hash algoritmy. Velikost hashe v dokončené zprávě však musí být stále alespoň 96 bitů .
  • Kombinace MD5 – SHA-1 v digitálně podepsaném prvku byla nahrazena jediným hashem vyjednaným během handshake , což je výchozí hodnota SHA-1.
  • Vylepšení schopnosti klienta a serveru určit, které algoritmy hash a podpis akceptují.
  • Rozšíření podpory ověřených šifrovacích kódů, které se používají hlavně pro Galois / Counter Mode (GCM) a režim CCM z Advanced Encryption Standard šifrování (AES).
  • Byla přidána definice rozšíření TLS a šifrovací sady AES.

Všechny verze TLS byly dále zdokonaleny v RFC  6176 v březnu 2011, čímž byla odstraněna jejich zpětná kompatibilita s SSL, takže relace TLS nikdy nevyjednávaly použití SSL (Secure Sockets Layer) verze 2.0.

TLS 1.3

TLS 1.3 byl definován v RFC  8446 v srpnu 2018. Vychází z dřívější specifikace TLS 1.2. Mezi hlavní rozdíly oproti TLS 1.2 patří:

  • Oddělení klíčových dohod a ověřovacích algoritmů od šifrovacích sad
  • Odebírání podpory pro slabé a méně používané pojmenované eliptické křivky
  • Odebírání podpory pro kryptografické hashovací funkce MD5 a SHA-224
  • Vyžadování digitálních podpisů, i když je použita předchozí konfigurace
  • Integrace HKDF a částečně efemérního návrhu DH
  • Výměna obnovení za PSK a lístky
  • Podpora 1- RTT handshakes a počáteční podpora pro 0- RTT
  • Nařízení dokonalého utajení dopředu pomocí použití dočasných klíčů při dohodě o klíče (EC) DH
  • Zrušení podpory pro mnoho nezabezpečených nebo zastaralých funkcí, včetně komprese , opětovného vyjednávání, šifer jiných než AEAD , výměny klíčů bez PFS (mezi nimiž jsou statické výměny klíčů RSA a statické DH ), vlastní skupiny DHE , vyjednávání formátu bodu EC, protokol Change Cipher Spec, Dobrý den, čas v systému UNIX a vstup AD do pole délky do šifer AEAD
  • Zákaz vyjednávání SSL nebo RC4 pro zpětnou kompatibilitu
  • Integrace použití hash relace
  • Zastaralé používání čísla verze záznamové vrstvy a zmrazení čísla pro lepší zpětnou kompatibilitu
  • Přesunutí některých detailů algoritmu souvisejících se zabezpečením z přílohy do specifikace a vyřazení ClientKeyShare do přílohy
  • Přidání šifry proudu ChaCha20 s ověřovacím kódem zprávy Poly1305
  • Přidání algoritmů digitálního podpisu Ed25519 a Ed448
  • Přidání protokolů pro výměnu klíčů x25519 a x448
  • Přidání podpory pro odesílání více odpovědí OCSP
  • Šifrování všech zpráv o handshake po ServerHello

Network Security Services (NSS), kryptografická knihovna vyvinutá společností Mozilla a používaná jejím webovým prohlížečem Firefox , ve výchozím nastavení povolila TLS 1.3 v únoru 2017. Následně byla přidána podpora TLS 1.3 - ale kvůli problémům s kompatibilitou pro malý počet uživatelů, nikoli automaticky povoleno - na Firefox 52.0 , který byl vydán v březnu 2017. TLS 1.3 byl ve výchozím nastavení povolen v květnu 2018 s vydáním Firefoxu 60.0 .

Google Chrome na krátkou dobu v roce 2017 na krátkou dobu nastavil TLS 1.3. Poté jej odstranil jako výchozí kvůli nekompatibilním prostředním boxům, jako jsou webové proxy Blue Coat .

Během Hackathonu IETF 100, který se konal v Singapuru v roce 2017, skupina TLS pracovala na přizpůsobení open-source aplikací tak, aby používaly TLS 1.3. Skupinu TLS tvořili jednotlivci z Japonska , Velké Británie a Mauricia prostřednictvím týmu cyberstorm.mu. Tato práce pokračovala na IETF 101 Hackathon v Londýně a IETF 102 Hackathon v Montrealu.

wolfSSL umožnil použití TLS 1.3 od verze 3.11.1, vydané v květnu 2017. Jako první komerční implementace TLS 1.3 podporovala wolfSSL 3.11.1 Draft 18 a nyní podporuje Draft 28, konečnou verzi, stejně jako mnoho starších verzí . Byla publikována řada blogů o rozdílech výkonu mezi TLS 1.2 a 1.3.

v „Populární projekt OpenSSL vydal verzi 1.1.1 své knihovny, ve které byla podpora TLS 1.3„ novou funkcí titulků “.

Zabezpečení dopravy podniku

Electronic Frontier Foundation chválen TLS 1.3 a vyjádřil znepokojení nad varianta protokolu podnikové bezpečnosti dopravy (ETS), který úmyslně zakáže důležitá bezpečnostní opatření v TLS 1.3. Původně nazvaný Enterprise TLS (eTLS), ETS je publikovaný standard známý jako 'ETSI TS103523-3', "Middlebox Security Protocol, Part3: Enterprise Transport Security". Je určen pro použití výhradně v rámci proprietárních sítí, jako jsou bankovní systémy. ETS nepodporuje utajení dopředu, aby organizace třetích stran připojené k proprietárním sítím mohly používat svůj soukromý klíč ke sledování síťového provozu pro detekci malwaru a usnadnit provádění auditů. Navzdory nárokovaným výhodám EFF varoval, že ztráta dopředného utajení by mohla usnadnit odhalení dat spolu s tím, že existují lepší způsoby, jak analyzovat provoz.

Digitální certifikáty

Příklad webové stránky s digitálním certifikátem

Digitální certifikát certifikuje vlastnictví veřejného klíče pojmenovaným subjektem certifikátu a uvádí určitá očekávaná použití tohoto klíče. To umožňuje ostatním (spoléhajícím se stranám) spoléhat se na podpisy nebo na tvrzení soukromého klíče, který odpovídá certifikovanému veřejnému klíči. Úložiště klíčů a obchody s důvěryhodností mohou mít různé formáty, například .pem, .crt, .pfx a .jks.

Certifikační autority

TLS se při ověřování pravosti certifikátů obvykle spoléhá na sadu důvěryhodných certifikačních autorit třetích stran. Důvěra je obvykle ukotvena v seznamu certifikátů distribuovaných pomocí softwaru agenta uživatele a může být upravena předávající stranou.

Podle Netcraft , který monitoruje aktivní certifikáty TLS, je vedoucí certifikační autoritou (CA) společnost Symantec od začátku jejich průzkumu (nebo VeriSign před zakoupením obchodní jednotky ověřovacích služeb společností Symantec). V roce 2015 společnost Symantec představovala necelou třetinu všech certifikátů a 44% platných certifikátů používaných 1 milionem nejrušnějších webů, jak uvádí Netcraft. V roce 2017 společnost Symantec prodala své podnikání s TLS/SSL společnosti DigiCert. V aktualizované zprávě, bylo prokázáno, že IdenTrust , DigiCert a Sectigo jsou top 3 certifikační autority, pokud jde o podíl na trhu od května 2019.

V důsledku výběru certifikátů X.509 jsou certifikační autority a infrastruktura veřejného klíče nezbytné k ověření vztahu mezi certifikátem a jeho vlastníkem, jakož i ke generování, podepisování a správě platnosti certifikátů. I když to může být pohodlnější než ověřování identit pomocí sítě důvěry , zveřejnění hromadného sledování z roku 2013 rozšířilo povědomí o tom, že certifikační autority jsou slabým místem z hlediska zabezpečení, což umožňuje útoky typu man-in-the-middle (MITM) pokud certifikační autorita spolupracuje (nebo je ohrožena).

Algoritmy

Výměna klíčů nebo dohoda o klíči

Než si klient a server mohou začít vyměňovat informace chráněné protokolem TLS, musí si bezpečně vyměnit nebo odsouhlasit šifrovací klíč a šifru, které se mají použít při šifrování dat (viz § Šifra ). Mezi metody používané pro výměnu/dohodu klíčů patří: veřejné a soukromé klíče generované pomocí RSA (označeny TLS_RSA v protokolu TLS handshake), Diffie – Hellman (TLS_DH), efemérní Diffie – Hellman (TLS_DHE), eliptická křivka Diffie – Hellman ( TLS_ECDH), efemérní eliptická křivka Diffie – Hellman (TLS_ECDHE), anonymní Diffie – Hellman (TLS_DH_anon), předem sdílený klíč (TLS_PSK) a bezpečné vzdálené heslo (TLS_SRP).

Metody dohod klíče TLS_DH_anon a TLS_ECDH_anon neověřují server ani uživatele, a proto se používají jen zřídka, protože jsou citlivé na útoky typu man-in-the-middle . Pouze TLS_DHE a TLS_ECDHE poskytují utajení dopředu .

Certifikáty veřejného klíče používané při výměně/dohodě se také liší velikostí veřejných/soukromých šifrovacích klíčů použitých během výměny, a tím i robustností poskytovaného zabezpečení. V červenci 2013 společnost Google oznámila, že již nebude používat 1024bitové veřejné klíče a místo toho přejde na 2048bitové klíče, aby se zvýšila bezpečnost šifrování TLS, které poskytuje svým uživatelům, protože síla šifrování přímo souvisí s velikostí klíče .

Výměna klíčů/dohoda a autentizace
Algoritmus SSL 2.0 SSL 3.0 TLS 1.0 TLS 1.1 TLS 1.2 TLS 1.3 Postavení
RSA Ano Ano Ano Ano Ano Ne Definováno pro TLS 1.2 v RFC
DH - RSA Ne Ano Ano Ano Ano Ne
DHE - RSA ( dopředné utajení ) Ne Ano Ano Ano Ano Ano
ECDH - RSA Ne Ne Ano Ano Ano Ne
ECDHE - RSA (forward secrecy ) Ne Ne Ano Ano Ano Ano
DH - DSS Ne Ano Ano Ano Ano Ne
DHE - DSS (dopředné utajení) Ne Ano Ano Ano Ano Ne
ECDH - ECDSA Ne Ne Ano Ano Ano Ne
ECDHE - ECDSA (vpřed tajemství) Ne Ne Ano Ano Ano Ano
ECDH - EdDSA Ne Ne Ano Ano Ano Ne
ECDHE - EdDSA (forward secrecy ) Ne Ne Ano Ano Ano Ano
PSK Ne Ne Ano Ano Ano
PSK - RSA Ne Ne Ano Ano Ano
DHE - PSK (dopředné utajení) Ne Ne Ano Ano Ano Ano
ECDHE - PSK (forward secrecy ) Ne Ne Ano Ano Ano Ano
SRP Ne Ne Ano Ano Ano
SRP - DSS Ne Ne Ano Ano Ano
SRP - RSA Ne Ne Ano Ano Ano
Kerberos Ne Ne Ano Ano Ano
DH -ANON (nezabezpečený) Ne Ano Ano Ano Ano
ECDH -ANON (nejistý) Ne Ne Ano Ano Ano
GOST R 34.10-94 / 34.10-2001 Ne Ne Ano Ano Ano Navrženo v konceptech RFC

Šifra

Šifrování zabezpečení proti veřejně známým proveditelným útokům
Šifra Verze protokolu Postavení
Typ Algoritmus Jmenovitá síla (bity) SSL 2.0 SSL 3.0
TLS 1.0
TLS 1.1
TLS 1.2
TLS 1.3
Bloková šifra
s
provozním režimem
AES GCM 256, 128 N/A N/A N/A N/A Zajistit Zajistit Definováno pro TLS 1.2 v RFC
AES CCM N/A N/A N/A N/A Zajistit Zajistit
AES CBC N/A Nejistý Záleží na zmírnění Záleží na zmírnění Záleží na zmírnění N/A
Camellia GCM 256, 128 N/A N/A N/A N/A Zajistit N/A
Camellia CBC N/A Nejistý Záleží na zmírnění Záleží na zmírnění Záleží na zmírnění N/A
ARIA GCM 256, 128 N/A N/A N/A N/A Zajistit N/A
ARIA CBC N/A N/A Záleží na zmírnění Záleží na zmírnění Záleží na zmírnění N/A
SEED CBC 128 N/A Nejistý Záleží na zmírnění Záleží na zmírnění Záleží na zmírnění N/A
3DES EDE CBC 112 Nejistý Nejistý Nejistý Nejistý Nejistý N/A
GOST 28147-89 CNT 256 N/A N/A Nejistý Nejistý Nejistý N/A Definováno v RFC  4357
IDEA CBC 128 Nejistý Nejistý Nejistý Nejistý N/A N/A Odebráno z TLS 1.2
DES CBC 056 Nejistý Nejistý Nejistý Nejistý N/A N/A
040 Nejistý Nejistý Nejistý N/A N/A N/A Zakázáno v TLS 1.1 a novějších
RC2 CBC 040 Nejistý Nejistý Nejistý N/A N/A N/A
Streamová šifra ChaCha20 - Poly1305 256 N/A N/A N/A N/A Zajistit Zajistit Definováno pro TLS 1.2 v RFC
RC4 128 Nejistý Nejistý Nejistý Nejistý Nejistý N/A Zakázáno ve všech verzích TLS RFC  7465
040 Nejistý Nejistý Nejistý N/A N/A N/A
Žádný Nula - Nejistý Nejistý Nejistý Nejistý Nejistý N/A Definováno pro TLS 1.2 v RFC
Poznámky

Integrita dat

Pro integritu dat se používá ověřovací kód zprávy (MAC). HMAC se používá pro režim CBC blokových šifer. Ověřené šifrování (AEAD), jako je režim GCM a režim CCM, používá MAC integrovaný v AEAD a nepoužívá HMAC . Pro podání ruky TLS se používá PRF na bázi HMAC nebo HKDF .

Integrita dat
Algoritmus SSL 2.0 SSL 3.0 TLS 1.0 TLS 1.1 TLS 1.2 TLS 1.3 Postavení
HMAC - MD5 Ano Ano Ano Ano Ano Ne Definováno pro TLS 1.2 v RFC
HMAC - SHA1 Ne Ano Ano Ano Ano Ne
HMAC - SHA256/384 Ne Ne Ne Ne Ano Ne
AEAD Ne Ne Ne Ne Ano Ano
GOST 28147-89 IMIT Ne Ne Ano Ano Ano Navrženo v konceptech RFC
GOST R 34,11-94 Ne Ne Ano Ano Ano

Přihlášky a adopce

V návrhu aplikací je TLS obvykle implementován nad protokoly Transport Layer a šifruje všechna data související s protokoly protokolů, jako jsou HTTP , FTP , SMTP , NNTP a XMPP .

Historicky byl TLS používán především se spolehlivými přenosovými protokoly, jako je Transaction Control Protocol (TCP). Byl však také implementován s transportními protokoly orientovanými na datagram, jako je User Datagram Protocol (UDP) a Datagram Congestion Control Protocol (DCCP), jejichž použití bylo standardizováno nezávisle pomocí termínu Datagram Transport Layer Security (DTLS) .

Webové stránky

Primárním využitím TLS je zajištění celosvětového provozu mezi webem a webovým prohlížečem kódovaným protokolem HTTP. Toto použití TLS k zabezpečení provozu HTTP představuje protokol HTTPS .

Podpora webového protokolu (září 2021)

Verze protokolu

Podpora webových stránek
Bezpečnostní
SSL 2.0 0,4% Nejistý
SSL 3.0 3,1% Nejistý
TLS 1.0 44,0% Zastaralé
TLS 1.1 48,1% Zastaralé
TLS 1.2 99,6% Záleží na šifře a zmírnění klientů
TLS 1.3 48,9% Zajistit
Poznámky

internetové prohlížeče

Jak dubna 2016, nejnovější verze všech hlavních webových prohlížečů podporují TLS 1.0, 1.1 a 1.2 a mají je ve výchozím nastavení povolené. Ne všechny podporované operační systémy Microsoft však podporují nejnovější verzi IE. Navíc mnoho operačních systémů aktuálně podporuje více verzí IE, ale to se změnilo podle častých dotazů o zásadách životního cyklu podpory Microsoftu Internet Explorer , „od 12. ledna 2016 bude technická podpora přijímána pouze z nejaktuálnější verze aplikace Internet Explorer, která je k dispozici pro podporovaný operační systém. aktualizace a aktualizace zabezpečení. “ Stránka poté pokračuje v seznamu nejnovější podporované verze IE k danému datu pro každý operační systém. Příští kritické datum bude, když operační systém dosáhne fáze konce životnosti, která je uvedena v informačním listu životního cyklu systému Microsoft Windows .

Zmírnění proti známým útokům zatím nestačí:

  • Zmírnění proti útoku POODLE : některé prohlížeče již zabraňují nouzovému přechodu na SSL 3.0; toto zmírnění však musí podporovat nejen klienti, ale i servery. Je vyžadováno zakázání samotného SSL 3.0, implementace „rozdělování záznamů anti-POODLE“ nebo odmítnutí šifer CBC v SSL 3.0.
    • Google Chrome: dokončeno (TLS_FALLBACK_SCSV je implementováno od verze 33, záložní verze SSL 3.0 je od verze 39 zakázána, SSL 3.0 je od verze 40 ve výchozím nastavení zakázáno. Podpora verze SSL 3.0 byla od verze 44 zrušena.)
    • Mozilla Firefox: kompletní (podpora samotného SSL 3.0 je od verze 39 zrušena . Samotný SSL 3.0 je ve výchozím nastavení zakázán a přechod na SSL 3.0 je zakázán od verze 34 , TLS_FALLBACK_SCSV je implementován od verze 35. V ESR je SSL 3.0 sám deaktivován výchozí a TLS_FALLBACK_SCSV je implementován od ESR 31.3.)
    • Internet Explorer: částečný (pouze ve verzi 11 je SSL 3.0 ve výchozím nastavení zakázán od dubna 2015. Verze 10 a starší jsou stále zranitelné vůči POODLE.)
    • Opera : Complete (TLS_FALLBACK_SCSV je implementován od verze 20, „rozdělování záznamů proti POODLE“, které je účinné pouze při implementaci na straně klienta, je implementováno od verze 25, samotný SSL 3.0 je od verze 27. ve výchozím nastavení zakázán. Podpora SSL 3.0 sám bude od verze 31. vypuštěn)
    • Safari: kompletní (pouze na OS X 10.8 a novějších a iOS 8, šifry CBC během nouzového přechodu na SSL 3.0 jsou odmítnuty, ale to znamená, že bude používat RC4, což se také nedoporučuje. Podpora samotného SSL 3.0 je na OS X zrušena 10.11 a novější a iOS 9.)
  • Zmírnění proti útokům RC4 :
    • Google Chrome deaktivoval RC4 s výjimkou jako záložní verze od verze 43. RC4 je od Chrome 48 zakázán.
    • Firefox deaktivoval RC4 s výjimkou jako záložní verze od verze 36. Firefox 44 ve výchozím nastavení deaktivoval RC4.
    • Opera deaktivována RC4 s výjimkou jako záložní verze 30. Verze RC4 je deaktivována od Opery 35.
    • Internet Explorer pro Windows 7 / Server 2008 R2 a pro Windows 8 / Server 2012 nastavil prioritu RC4 na nejnižší a může také RC4 deaktivovat, kromě toho, že je záložní nastavení registru. Internet Explorer 11 Mobile 11 pro Windows Phone 8.1 deaktivuje RC4 s výjimkou záložního, pokud nefunguje žádný jiný povolený algoritmus. Edge a IE 11 deaktivují RC4 úplně v srpnu 2016.
  • Zmírnění proti útoku FREAK :
    • Prohlížeč Android, který je součástí systému Android 4.0 a starších, je stále zranitelný útokem FREAK.
    • Internet Explorer 11 Mobile je stále zranitelný útokem FREAK.
    • Google Chrome, Internet Explorer (pro počítače), Safari (pro počítače a mobily) a Opera (pro mobily) mají zavedena omezení FREAK.
    • Mozilla Firefox na všech platformách a Google Chrome ve Windows nebyla FREAKem ovlivněna.
Historie podpory TLS/SSL webových prohlížečů
Prohlížeč Verze Platformy SSL protokoly Protokoly TLS Podpora certifikátu Opravené chyby zabezpečení Výběr protokolu uživatelem
SSL 2.0 (nezabezpečené) SSL 3.0 (nezabezpečené) TLS 1.0 (zastaralé) TLS 1.1 (zastaralé) TLS 1.2 TLS 1.3 EV
SHA-2
ECDSA
BESTIE ZLOČIN POODLE (SSLv3) RC4 ZLATO Nakupení plaveného dříví
Google Chrome
( Chrome pro Android )

1–9 Windows  (7+)
MacOS  (10.11+)
Linux
Android  (5.0 a vyšší)
iOS  (12.2+)
Chrome OS
Ve výchozím nastavení zakázáno Ve výchozím nastavení povoleno Ano Ne Ne Ne Ano
(pouze počítač)
potřebuje operační systém kompatibilní se SHA-2 potřebuje OS kompatibilní s ECC Není ovlivněn
Zranitelné
(HTTPS)
Zranitelný Zranitelný Zranitelné
(kromě systému Windows)
Zranitelný Ano
10–20 Ne Ve výchozím nastavení povoleno Ano Ne Ne Ne Ano
(pouze počítač)
potřebuje operační systém kompatibilní se SHA-2 potřebuje OS kompatibilní s ECC Není ovlivněn Zranitelné
(HTTPS/SPDY)
Zranitelný Zranitelný Zranitelné
(kromě systému Windows)
Zranitelný Ano
21 Ne Ve výchozím nastavení povoleno Ano Ne Ne Ne Ano
(pouze počítač)
potřebuje operační systém kompatibilní se SHA-2 potřebuje OS kompatibilní s ECC Není ovlivněn Zmírněné
Zranitelný Zranitelný Zranitelné
(kromě systému Windows)
Zranitelný Ano
22–29 Ne Ve výchozím nastavení povoleno Ano Ano Ne Ne Ano
(pouze počítač)
potřebuje operační systém kompatibilní se SHA-2 potřebuje OS kompatibilní s ECC Není ovlivněn Zmírněné Zranitelný Zranitelný Zranitelné
(kromě systému Windows)
Zranitelný Dočasný
30–32 Ne Ve výchozím nastavení povoleno Ano Ano Ano Ne Ano
(pouze počítač)
potřebuje operační systém kompatibilní se SHA-2 potřebuje OS kompatibilní s ECC Není ovlivněn Zmírněné Zranitelný Zranitelný Zranitelné
(kromě systému Windows)
Zranitelný Dočasný
33–37 Ne Ve výchozím nastavení povoleno Ano Ano Ano Ne Ano
(pouze počítač)
potřebuje operační systém kompatibilní se SHA-2 potřebuje OS kompatibilní s ECC Není ovlivněn Zmírněné Částečně zmírněno
Nejnižší priorita
Zranitelné
(kromě systému Windows)
Zranitelný Dočasný
38, 39 Ne Ve výchozím nastavení povoleno Ano Ano Ano Ne Ano
(pouze počítač)
Ano potřebuje OS kompatibilní s ECC Není ovlivněn Zmírněné Částečně zmírněno Nejnižší priorita Zranitelné
(kromě systému Windows)
Zranitelný Dočasný
40 Ne Ve výchozím nastavení zakázáno Ano Ano Ano Ne Ano
(pouze počítač)
Ano potřebuje OS kompatibilní s ECC Není ovlivněn Zmírněné Zmírněné
Nejnižší priorita Zranitelné
(kromě systému Windows)
Zranitelný Ano
41, 42 Ne Ve výchozím nastavení zakázáno Ano Ano Ano Ne Ano
(pouze počítač)
Ano potřebuje OS kompatibilní s ECC Není ovlivněn Zmírněné Zmírněné Nejnižší priorita Zmírněné Zranitelný Ano
43 Ne Ve výchozím nastavení zakázáno Ano Ano Ano Ne Ano
(pouze počítač)
Ano potřebuje OS kompatibilní s ECC Není ovlivněn Zmírněné Zmírněné Pouze jako záložní
Zmírněné Zranitelný Ano
44–47 Ne Ne Ano Ano Ano Ne Ano
(pouze počítač)
Ano potřebuje OS kompatibilní s ECC Není ovlivněn Zmírněné Není ovlivněn Pouze jako záložní
Zmírněné Zmírněné Dočasný
48, 49 Ne Ne Ano Ano Ano Ne Ano
(pouze počítač)
Ano potřebuje OS kompatibilní s ECC Není ovlivněn Zmírněné Není ovlivněn Ve výchozím nastavení zakázáno Zmírněné Zmírněné Dočasný
50–53 Ne Ne Ano Ano Ano Ne Ano
(pouze počítač)
Ano Ano Není ovlivněn Zmírněné Není ovlivněn Ve výchozím nastavení zakázáno Zmírněné Zmírněné Dočasný
54–66 Ne Ne Ano Ano Ano Ve výchozím nastavení zakázáno
(konceptní verze)
Ano
(pouze počítač)
Ano Ano Není ovlivněn Zmírněné Není ovlivněn Ve výchozím nastavení zakázáno Zmírněné Zmírněné Dočasný
67–69 Ne Ne Ano Ano Ano Ano
(konceptní verze)
Ano
(pouze počítač)
Ano Ano Není ovlivněn Zmírněné Není ovlivněn Ve výchozím nastavení zakázáno Zmírněné Zmírněné Dočasný
70–83 Ne Ne Ano Ano Ano Ano Ano
(pouze počítač)
Ano Ano Není ovlivněn Zmírněné Není ovlivněn Ve výchozím nastavení zakázáno Zmírněné Zmírněné Dočasný
84–90 Ne Ne Ve výchozím nastavení varovat Ve výchozím nastavení varovat Ano Ano Ano
(pouze počítač)
Ano Ano Není ovlivněn Zmírněné Není ovlivněn Ve výchozím nastavení zakázáno Zmírněné Zmírněné Dočasný
91–93 94 Ne Ne Ne Ne Ano Ano Ano
(pouze počítač)
Ano Ano Není ovlivněn Zmírněné Není ovlivněn Ve výchozím nastavení zakázáno Zmírněné Zmírněné Dočasný
Prohlížeč Verze Platformy SSL 2.0 (nezabezpečené) SSL 3.0 (nezabezpečené) TLS 1.0 (zastaralé) TLS 1.1 (zastaralé) TLS 1.2 TLS 1.3 EV certifikát Certifikát SHA-2 Certifikát ECDSA BESTIE ZLOČIN POODLE (SSLv3) RC4 ZLATO Nakupení plaveného dříví Výběr protokolu uživatelem
Microsoft Edge
(na bázi Chromium)
OS nezávislý
79–83 Windows  (7+)
macOS  (10.12+)
Linux 
Android  (4.4+)
iOS  (11.0+)
Ne Ne Ano Ano Ano Ano Ano Ano Ano Zmírněné Není ovlivněn Není ovlivněn Ve výchozím nastavení zakázáno Zmírněné Zmírněné Ano
84–90 Ne Ne Ve výchozím nastavení varovat Ve výchozím nastavení varovat Ano Ano Ano Ano Ano Zmírněné Není ovlivněn Není ovlivněn Ve výchozím nastavení zakázáno Zmírněné Zmírněné Ano
91-93 94 Ne Ne Ne Ne Ano Ano Ano Ano Ano Zmírněné Není ovlivněn Není ovlivněn Ve výchozím nastavení zakázáno Zmírněné Zmírněné Ano
Prohlížeč Verze Platformy SSL 2.0 (nezabezpečené) SSL 3.0 (nezabezpečené) TLS 1.0 (zastaralé) TLS 1.1 (zastaralé) TLS 1.2 TLS 1.3 EV certifikát Certifikát SHA-2 Certifikát ECDSA BESTIE ZLOČIN POODLE (SSLv3) RC4 ZLATO Nakupení plaveného dříví Výběr protokolu uživatelem
Mozilla Firefox
( Firefox pro mobilní zařízení )
1,0, 1,5 Windows  (7+)
macOS  (10.12+)
Linux
Android  ( 5.0+ )
iOS (11.4+)
Firefox OS
Maemo

ESR pouze pro:
Windows  (7+)
macOS  (10.9+)
Linux
Ve výchozím nastavení povoleno
Ve výchozím nastavení povoleno
Ano Ne Ne Ne Ne Ano Ne Není ovlivněn
Není ovlivněn Zranitelný Zranitelný Není ovlivněn Zranitelný Ano
2 Ve výchozím nastavení zakázáno
Ve výchozím nastavení povoleno Ano Ne Ne Ne Ne Ano Ano Není ovlivněn Není ovlivněn Zranitelný Zranitelný Není ovlivněn Zranitelný Ano
3–7 Ve výchozím nastavení zakázáno Ve výchozím nastavení povoleno Ano Ne Ne Ne Ano Ano Ano Není ovlivněn Není ovlivněn Zranitelný Zranitelný Není ovlivněn Zranitelný Ano
8–10
ESR 10
Ne Ve výchozím nastavení povoleno Ano Ne Ne Ne Ano Ano Ano Není ovlivněn Není ovlivněn Zranitelný Zranitelný Není ovlivněn Zranitelný Ano
11–14 Ne Ve výchozím nastavení povoleno Ano Ne Ne Ne Ano Ano Ano Není ovlivněn Zranitelný
(SPDY)
Zranitelný Zranitelný Není ovlivněn Zranitelný Ano
15–22
ESR 17.0–17.0.10
Ne Ve výchozím nastavení povoleno Ano Ne Ne Ne Ano Ano Ano Není ovlivněn Zmírněné Zranitelný Zranitelný Není ovlivněn Zranitelný Ano
ESR 17.0.11 Ne Ve výchozím nastavení povoleno Ano Ne Ne Ne Ano Ano Ano Není ovlivněn Zmírněné Zranitelný Nejnižší priorita
Není ovlivněn Zranitelný Ano
23 Ne Ve výchozím nastavení povoleno Ano Ve výchozím nastavení zakázáno
Ne Ne Ano Ano Ano Není ovlivněn Zmírněné Zranitelný Zranitelný Není ovlivněn Zranitelný Ano
24, 25.0.0
ESR 24.0–24.1.0
Ne Ve výchozím nastavení povoleno Ano Ve výchozím nastavení zakázáno Ve výchozím nastavení zakázáno
Ne Ano Ano Ano Není ovlivněn Zmírněné Zranitelný Zranitelný Není ovlivněn Zranitelný Ano
25.0.1, 26
ESR 24.1.1
Ne Ve výchozím nastavení povoleno Ano Ve výchozím nastavení zakázáno Ve výchozím nastavení zakázáno Ne Ano Ano Ano Není ovlivněn Zmírněné Zranitelný Nejnižší priorita
Není ovlivněn Zranitelný Ano
27–33
ESR 31.0–31.2
Ne Ve výchozím nastavení povoleno Ano Ano Ano Ne Ano Ano Ano Není ovlivněn Zmírněné Zranitelný Nejnižší priorita Není ovlivněn Zranitelný Ano
34, 35
ESR 31,3–31,7
Ne Ve výchozím nastavení zakázáno
Ano Ano Ano Ne Ano Ano Ano Není ovlivněn Zmírněné Zmírněné
Nejnižší priorita Není ovlivněn Zranitelný Ano
ESR 31.8 Ne Ve výchozím nastavení zakázáno Ano Ano Ano Ne Ano Ano Ano Není ovlivněn Zmírněné Zmírněné Nejnižší priorita Není ovlivněn Zmírněné Ano
36–38
ESR 38,0
Ne Ve výchozím nastavení zakázáno Ano Ano Ano Ne Ano Ano Ano Není ovlivněn Zmírněné Zmírněné Pouze jako záložní
Není ovlivněn Zranitelný Ano
ESR 38,1–38,8 Ne Ve výchozím nastavení zakázáno Ano Ano Ano Ne Ano Ano Ano Není ovlivněn Zmírněné Zmírněné Pouze jako záložní
Není ovlivněn Zmírněné Ano
39–43 Ne Ne Ano Ano Ano Ne Ano Ano Ano Není ovlivněn Zmírněné Není ovlivněn Pouze jako záložní
Není ovlivněn Zmírněné Ano
44–48
ESR 45
Ne Ne Ano Ano Ano Ne Ano Ano Ano Není ovlivněn Zmírněné Není ovlivněn Ve výchozím nastavení zakázáno Není ovlivněn Zmírněné Ano
49–59
ESR 52
Ne Ne Ano Ano Ano Ve výchozím stavu zakázáno
(pracovní verze)
Ano Ano Ano Není ovlivněn Zmírněné Není ovlivněn Ve výchozím nastavení zakázáno Není ovlivněn Zmírněné Ano
60–62
ESR 60
Ne Ne Ano Ano Ano Ano
(konceptní verze)
Ano Ano Ano Není ovlivněn Zmírněné Není ovlivněn Ve výchozím nastavení zakázáno Není ovlivněn Zmírněné Ano
63–77
ESR 68
Ne Ne Ano Ano Ano Ano Ano Ano Ano Není ovlivněn Zmírněné Není ovlivněn Ve výchozím nastavení zakázáno Není ovlivněn Zmírněné Ano
78–92
ESR 78,0–78,14
ESR 91,0–91,1
Ne Ne Ve výchozím nastavení zakázáno Ve výchozím nastavení zakázáno Ano Ano Ano Ano Ano Není ovlivněn Zmírněné Není ovlivněn Ve výchozím nastavení zakázáno Není ovlivněn Zmírněné Ano
ESR 78,15
ESR 91,2
93
Prohlížeč Verze Platformy SSL 2.0 (nezabezpečené) SSL 3.0 (nezabezpečené) TLS 1.0 (zastaralé) TLS 1.1 (zastaralé) TLS 1.2 TLS 1.3 EV certifikát Certifikát SHA-2 Certifikát ECDSA BESTIE ZLOČIN POODLE (SSLv3) RC4 ZLATO Nakupení plaveného dříví Výběr protokolu uživatelem
Microsoft Internet Explorer
(1–10)
1.x Windows 3.1 , 95 , NT ,
Mac OS 7 , 8
Žádná podpora SSL/TLS
2 Ano Ne Ne Ne Ne Ne Ne Ne Ne Žádná podpora SSL 3.0 nebo TLS Zranitelný Zranitelný Zranitelný N/A
3 Ano Ano Ne Ne Ne Ne Ne Ne Ne Zranitelný Není ovlivněn Zranitelný Zranitelný Zranitelný Zranitelný Neznámý
4 , 5 , 6 Windows 3.1 , 95 , 98 , NT , 2000
Mac OS 7.1 , 8 , X ,
Solaris , HP-UX
Ve výchozím nastavení povoleno Ve výchozím nastavení povoleno Ve výchozím nastavení zakázáno
Ne Ne Ne Ne Ne Ne Zranitelný Není ovlivněn Zranitelný Zranitelný Zranitelný Zranitelný Ano
6 Windows XP Ve výchozím nastavení povoleno Ve výchozím nastavení povoleno Ve výchozím nastavení zakázáno Ne Ne Ne Ne Ano
Ne Zmírněné Není ovlivněn Zranitelný Zranitelný Zranitelný Zranitelný Ano
7 , 8 Ve výchozím nastavení zakázáno
Ve výchozím nastavení povoleno Ano Ne Ne Ne Ano Ano
Ne Zmírněné Není ovlivněn Zranitelný Zranitelný Zranitelný Zranitelný Ano
6 Server 2003 Ve výchozím nastavení povoleno Ve výchozím nastavení povoleno Ve výchozím nastavení zakázáno Ne Ne Ne Ne Ano
Ne Zmírněné Není ovlivněn Zranitelný Zranitelný Zmírněné
Zmírněné
Ano
7 , 8 Ve výchozím nastavení zakázáno
Ve výchozím nastavení povoleno Ano Ne Ne Ne Ano Ano
Ne Zmírněné Není ovlivněn Zranitelný Zranitelný Zmírněné
Zmírněné
Ano
7 , 8 , 9 Windows Vista Ve výchozím nastavení zakázáno Ve výchozím nastavení povoleno Ano Ne Ne Ne Ano Ano Ano Zmírněné Není ovlivněn Zranitelný Zranitelný Zmírněné
Zmírněné
Ano
7 , 8 , 9 Server 2008 Ve výchozím nastavení zakázáno Ve výchozím nastavení povoleno Ano Ve výchozím nastavení zakázány
(KB4019276)
Ve výchozím nastavení zakázány
(KB4019276)
Ne Ano Ano Ano Zmírněné Není ovlivněn Zranitelný Zranitelný Zmírněné
Zmírněné
Ano
8 , 9 , 10 Windows 7 / 8
Server 2008 R2 / 2012
Ve výchozím nastavení zakázáno Ve výchozím nastavení povoleno Ano Ve výchozím nastavení zakázáno
Ve výchozím nastavení zakázáno
Ne Ano Ano Ano Zmírněné Není ovlivněn Zranitelný Nejnižší priorita
Zmírněné
Zmírněné
Ano
Internet Explorer 11
11 Windows 7
Server 2008 R2
Ve výchozím nastavení zakázáno Ve výchozím nastavení zakázáno
Ano Ano Ano Ne Ano Ano Ano Zmírněné Není ovlivněn Zmírněné
Ve výchozím nastavení zakázáno Zmírněné
Zmírněné
Ano
11 Windows 8.1 Ve výchozím nastavení zakázáno Ve výchozím nastavení zakázáno
Ano Ano Ano Ne Ano Ano Ano Zmírněné Není ovlivněn Zmírněné
Ve výchozím nastavení zakázáno Zmírněné
Zmírněné
Ano
Server 2012
Server 2012 R2
Prohlížeč Verze Platformy SSL 2.0 (nezabezpečené) SSL 3.0 (nezabezpečené) TLS 1.0 (zastaralé) TLS 1.1 (zastaralé) TLS 1.2 TLS 1.3 EV certifikát Certifikát SHA-2 Certifikát ECDSA BESTIE ZLOČIN POODLE (SSLv3) RC4 ZLATO Nakupení plaveného dříví Výběr protokolu uživatelem
Klient Microsoft Edge
(12–18)
(založený na EdgeHTML)
Pouze


Internet Explorer 11
11 12–13 Windows 10
1507–1511
Ve výchozím nastavení zakázáno Ve výchozím nastavení zakázáno Ano Ano Ano Ne Ano Ano Ano Zmírněné Není ovlivněn Zmírněné Ve výchozím nastavení zakázáno Zmírněné Zmírněné Ano
11 14–18
(pouze klient)
Windows 10
1607–1909
Windows Server (SAC)
1709–1909
Ne Ve výchozím nastavení zakázáno Ano Ano Ano Ne Ano Ano Ano Zmírněné Není ovlivněn Zmírněné Ve výchozím nastavení zakázáno Zmírněné Zmírněné Ano
11 18
(pouze klient)
Windows 10
2004
Windows Server (SAC)
2004
Ne Ve výchozím nastavení zakázáno Ano Ano Ano Ne Ano Ano Ano Zmírněné Není ovlivněn Zmírněné Ve výchozím nastavení zakázáno Zmírněné Zmírněné Ano
Internet Explorer 11
11 Windows 10
20H2
Windows Server (SAC) 20H2
Ne Ve výchozím nastavení zakázáno Ano Ano Ano Ne Ano Ano Ano Zmírněné Není ovlivněn Zmírněné Ve výchozím nastavení zakázáno Zmírněné Zmírněné Ano
11 Windows 10
21H1
Ne Ve výchozím nastavení zakázáno Ano Ano Ano Ne Ano Ano Ano Zmírněné Není ovlivněn Zmírněné Ve výchozím nastavení zakázáno Zmírněné Zmírněné Ano
11 Windows 10
21H2
Ne Ve výchozím nastavení zakázáno Ano Ano Ano Ne Ano Ano Ano Zmírněné Není ovlivněn Zmírněné Ve výchozím nastavení zakázáno Zmírněné Zmírněné Ano
11 Windows 11 Ne Ve výchozím nastavení zakázáno Ano Ano Ano Ano Ano Ano Ano Zmírněné Není ovlivněn Zmírněné Ve výchozím nastavení zakázáno Zmírněné Zmírněné Ano


Verze Internet Explorer 11 LTSC
11 Windows 10
LTSB 2015 (1507)
Ve výchozím nastavení zakázáno Ve výchozím nastavení zakázáno Ano Ano Ano Ne Ano Ano Ano Zmírněné Není ovlivněn Zmírněné Ve výchozím nastavení zakázáno Zmírněné Zmírněné Ano
11 Windows 10
LTSB 2016 (1607)
Ne Ve výchozím nastavení zakázáno Ano Ano Ano Ne Ano Ano Ano Zmírněné Není ovlivněn Zmírněné Ve výchozím nastavení zakázáno Zmírněné Zmírněné Ano
11 Windows Server 2016
(LTSB / 1607)
Ne Ve výchozím nastavení zakázáno Ano Ano Ano Ne Ano Ano Ano Zmírněné Není ovlivněn Zmírněné Ve výchozím nastavení zakázáno Zmírněné Zmírněné Ano
11 Windows 10
LTSC 2019 (1809)
Windows Server 2019
(LTSC / 1809)
Ne Ve výchozím nastavení zakázáno Ano Ano Ano Ne Ano Ano Ano Zmírněné Není ovlivněn Zmírněné Ve výchozím nastavení zakázáno Zmírněné Zmírněné Ano
11 Windows 10
LTSC 2022 (21H2)
Ne Ve výchozím nastavení zakázáno Ano Ano Ano Ne Ano Ano Ano Zmírněné Není ovlivněn Zmírněné Ve výchozím nastavení zakázáno Zmírněné Zmírněné Ano
11 Windows Server 2022
(LTSC / 21H2)
Ne Ve výchozím nastavení zakázáno Ano Ano Ano Ano Ano Ano Ano Zmírněné Není ovlivněn Zmírněné Ve výchozím nastavení zakázáno Zmírněné Zmírněné Ano
Prohlížeč Verze Platformy SSL 2.0 (nezabezpečené) SSL 3.0 (nezabezpečené) TLS 1.0 (zastaralé) TLS 1.1 (zastaralé) TLS 1.2 TLS 1.3 EV certifikát Certifikát SHA-2 Certifikát ECDSA BESTIE ZLOČIN POODLE (SSLv3) RC4 ZLATO Nakupení plaveného dříví Výběr protokolu uživatelem
Microsoft Internet Explorer Mobile
7, 9 Windows Phone 7, 7.5, 7.8 Ve výchozím nastavení zakázáno
Ve výchozím nastavení povoleno Ano Ne
Ne
Ne Ne
Ano Ano Neznámý Není ovlivněn Zranitelný Zranitelný Zranitelný Zranitelný Pouze s nástroji třetích stran
10 Windows Phone 8 Ve výchozím nastavení zakázáno Ve výchozím nastavení povoleno Ano Ve výchozím nastavení zakázáno
Ve výchozím nastavení zakázáno
Ne Ne
Ano Ano Zmírněné Není ovlivněn Zranitelný Zranitelný Zranitelný Zranitelný Pouze s nástroji třetích stran
11 Windows Phone 8.1 Ve výchozím nastavení zakázáno Ve výchozím nastavení povoleno Ano Ano Ano Ne Ne
Ano Ano Zmírněné Není ovlivněn Zranitelný Pouze jako záložní
Zranitelný Zranitelný Pouze s nástroji třetích stran
Microsoft Edge
(13–15)
(založené na EdgeHTML)
13 Windows 10 Mobile
1511
Ve výchozím nastavení zakázáno Ve výchozím nastavení zakázáno Ano Ano Ano Ne Ano Ano Ano Zmírněné Není ovlivněn Zmírněné Ve výchozím nastavení zakázáno Zmírněné Zmírněné Ne
14, 15 Windows 10 Mobile
1607–1709
Ne Ve výchozím nastavení zakázáno Ano Ano Ano Ne Ano Ano Ano Zmírněné Není ovlivněn Zmírněné Ve výchozím nastavení zakázáno Zmírněné Zmírněné Ne
Prohlížeč Verze Platformy SSL 2.0 (nezabezpečené) SSL 3.0 (nezabezpečené) TLS 1.0 (zastaralé) TLS 1.1 (zastaralé) TLS 1.2 TLS 1.3 EV certifikát Certifikát SHA-2 Certifikát ECDSA BESTIE ZLOČIN POODLE (SSLv3) RC4 ZLATO Nakupení plaveného dříví Výběr protokolu uživatelem
Apple Safari
1 Mac OS X 10.2 , 10.3 Ne Ano Ano Ne Ne Ne Ne Ne Ne Zranitelný Není ovlivněn Zranitelný Zranitelný Zranitelný Zranitelný Ne
2–5 Mac OS X 10.4 , 10.5 , Win XP Ne Ano Ano Ne Ne Ne od v3.2 Ne Ne Zranitelný Není ovlivněn Zranitelný Zranitelný Zranitelný Zranitelný Ne
3–5 Vista , Win 7 Ne Ano Ano Ne Ne Ne od v3.2 Ne Ano Zranitelný Není ovlivněn Zranitelný Zranitelný Zranitelný Zranitelný Ne
4–6 Mac OS X 10.6 , 10.7 Ne Ano Ano Ne Ne Ne Ano Ano Ano Zranitelný Není ovlivněn Zranitelný Zranitelný Zranitelný Zranitelný Ne
6 OS X 10.8 Ne Ano Ano Ne Ne Ne Ano Ano Ano Zmírněné
Není ovlivněn Zmírněné
Zranitelný
Zmírněné
Zranitelný Ne
7, 9 OS X 10.9 Ne Ano Ano Ano Ano Ne Ano Ano Ano Zmírněné
Není ovlivněn Zmírněné
Zranitelný
Zmírněné
Zranitelný Ne
8–10 OS X 10.10 Ne Ano Ano Ano Ano Ne Ano Ano Ano Zmírněné Není ovlivněn Zmírněné
Nejnižší priorita
Zmírněné
Zmírněné
Ne
9–11 OS X 10.11 Ne Ne Ano Ano Ano Ne Ano Ano Ano Zmírněné Není ovlivněn Není ovlivněn Nejnižší priorita Zmírněné Zmírněné Ne
10–13 macOS 10.12 , 10.13 Ne Ne Ano Ano Ano Ne Ano Ano Ano Zmírněné Není ovlivněn Není ovlivněn Ve výchozím nastavení zakázáno Zmírněné Zmírněné Ne
12, 13 14 macOS 10.14 Ne Ne Ano Ano Ano Ano (od macOS 10.14.4) Ano Ano Ano Zmírněné Není ovlivněn Není ovlivněn Ve výchozím nastavení zakázáno Zmírněné Zmírněné Ne
13, 14 15 macOS 10.15 Ne Ne Ano Ano Ano Ano Ano Ano Ano Zmírněné Není ovlivněn Není ovlivněn Ve výchozím nastavení zakázáno Zmírněné Zmírněné Ne
14 15 macOS 11 Ne Ne Ano Ano Ano Ano Ano Ano Ano Zmírněné Není ovlivněn Není ovlivněn Ve výchozím nastavení zakázáno Zmírněné Zmírněné Ne
15 macOS 12 Ne Ne Ano Ano Ano Ano Ano Ano Ano Zmírněné Není ovlivněn Není ovlivněn Ve výchozím nastavení zakázáno Zmírněné Zmírněné Ne
Prohlížeč Verze Platformy SSL 2.0 (nezabezpečené) SSL 3.0 (nezabezpečené) TLS 1.0 (zastaralé) TLS 1.1 (zastaralé) TLS 1.2 TLS 1.3 EV certifikát Certifikát SHA-2 Certifikát ECDSA BESTIE ZLOČIN POODLE (SSLv3) RC4 ZLATO Nakupení plaveného dříví Výběr protokolu uživatelem
Apple Safari
(mobilní)
3 iPhone OS 1 , 2 Ne Ano Ano Ne Ne Ne Ne Ne Ne Zranitelný Není ovlivněn Zranitelný Zranitelný Zranitelný Zranitelný Ne
4, 5 iPhone OS 3 , iOS 4 Ne Ano Ano Ne Ne Ne Ano Ano od iOS 4 Zranitelný Není ovlivněn Zranitelný Zranitelný Zranitelný Zranitelný Ne
5, 6 iOS 5 , 6 Ne Ano Ano Ano Ano Ne Ano Ano Ano Zranitelný Není ovlivněn Zranitelný Zranitelný Zranitelný Zranitelný Ne
7 IOS 7 Ne Ano Ano Ano Ano Ne Ano Ano Ano Zmírněné
Není ovlivněn Zranitelný Zranitelný Zranitelný Zranitelný Ne
8 iOS 8 Ne Ano Ano Ano Ano Ne Ano Ano Ano Zmírněné Není ovlivněn Zmírněné
Nejnižší priorita
Zmírněné
Zmírněné
Ne
9 iOS 9 Ne Ne Ano Ano Ano Ne Ano Ano Ano Zmírněné Není ovlivněn Není ovlivněn Nejnižší priorita Zmírněné Zmírněné Ne
10, 11 iOS 10 , 11 Ne Ne Ano Ano Ano Ne Ano Ano Ano Zmírněné Není ovlivněn Není ovlivněn Ve výchozím nastavení zakázáno Zmírněné Zmírněné Ne
12 iOS 12 Ne Ne Ano Ano Ano Ano (od iOS 12.2) Ano Ano Ano Zmírněné Není ovlivněn Není ovlivněn Ve výchozím nastavení zakázáno Zmírněné Zmírněné Ne
13, 14 iOS 13 , 14 Ne Ne Ano Ano Ano Ano Ano Ano Ano Zmírněné Není ovlivněn Není ovlivněn Ve výchozím nastavení zakázáno Zmírněné Zmírněné Ne
iPadOS 13, 14
15 iOS 15 Ne Ne Ano Ano Ano Ano Ano Ano Ano Zmírněné Není ovlivněn Není ovlivněn Ve výchozím nastavení zakázáno Zmírněné Zmírněné Ne
iPadOS 15
Prohlížeč Verze Platformy SSL 2.0 (nezabezpečené) SSL 3.0 (nezabezpečené) TLS 1.0 (zastaralé) TLS 1.1 (zastaralé) TLS 1.2 TLS 1.3 EV
SHA-2 ECDSA BESTIE ZLOČIN POODLE (SSLv3) RC4 ZLATO Nakupení plaveného dříví Výběr protokolu uživatelem
Google Android OS
Android 1.0–4.0.4 Ne Ve výchozím nastavení povoleno Ano Ne Ne Ne Neznámý Ano od 3.0 Neznámý Neznámý Zranitelný Zranitelný Zranitelný Zranitelný Ne
Android 4.1–4.4.4 Ne Ve výchozím nastavení povoleno Ano Ve výchozím nastavení zakázáno Ve výchozím nastavení zakázáno Ne Neznámý Ano Ano Neznámý Neznámý Zranitelný Zranitelný Zranitelný Zranitelný Ne
Android 5.0–5.0.2 Ne Ve výchozím nastavení povoleno Ano Ano Ano Ne Neznámý Ano Ano Neznámý Neznámý Zranitelný Zranitelný Zranitelný Zranitelný Ne
Android 5.1–5.1.1 Ne Ve výchozím nastavení zakázáno
Ano Ano Ano Ne Neznámý Ano Ano Neznámý Neznámý Není ovlivněn Pouze jako záložní
Zmírněné Zmírněné Ne
Android 6.0 - 7.1.2 Ne Ve výchozím nastavení zakázáno
Ano Ano Ano Ne Neznámý Ano Ano Neznámý Neznámý Není ovlivněn Ve výchozím nastavení zakázáno Zmírněné Zmírněné Ne
Android 8.0 Ne Ne
Ano Ano Ano Ne Neznámý Ano Ano Neznámý Neznámý Není ovlivněn Ve výchozím nastavení zakázáno Zmírněné Zmírněné Ne
Android 8.1 - 9 Ne Ne Ano Ano Ano Ne Neznámý Ano Ano Neznámý Neznámý Není ovlivněn Ve výchozím nastavení zakázáno Zmírněné Zmírněné Ne
Android 10 Ne Ne Ano Ano Ano Ano Neznámý Ano Ano Neznámý Neznámý Není ovlivněn Ve výchozím nastavení zakázáno Zmírněné Zmírněné Ne
Android 11 Ne Ne Ano Ano Ano Ano Neznámý Ano Ano Neznámý Neznámý Není ovlivněn Ve výchozím nastavení zakázáno Zmírněné Zmírněné Ne
Android 12 Ne Ne Neznámý Neznámý Ano Ano Neznámý Ano Ano Neznámý Neznámý Není ovlivněn Ve výchozím nastavení zakázáno Zmírněné Zmírněné Ne
Prohlížeč Verze Platformy SSL 2.0 (nezabezpečené) SSL 3.0 (nezabezpečené) TLS 1.0 (zastaralé) TLS 1.1 (zastaralé) TLS 1.2 TLS 1.3 EV certifikát Certifikát SHA-2 Certifikát ECDSA BESTIE ZLOČIN POODLE (SSLv3) RC4 ZLATO Nakupení plaveného dříví Výběr protokolu uživatelem
Barva nebo poznámka Význam
Verze prohlížeče Plošina
Verze prohlížeče Operační systém Budoucí vydání; ve vývoji
Verze prohlížeče Operační systém Aktuální nejnovější vydání
Verze prohlížeče Operační systém Bývalé vydání; stále podporováno
Verze prohlížeče Operační systém Bývalé vydání; dlouhodobá podpora je stále aktivní, ale skončí za méně než 12 měsíců
Verze prohlížeče Operační systém Bývalé vydání; již není podporováno
není k dispozici Operační systém Smíšené / nespecifikované
Operační systém (verze+) Minimální požadovaná verze operačního systému (pro podporované verze prohlížeče)
Operační systém Pro tento operační systém již není podporován
Poznámky

Knihovny

Většina programovacích knihoven SSL a TLS je bezplatný a open source software .

  • BoringSSL , vidlice OpenSSL pro Chrome/Chromium a Android a další aplikace Google.
  • Botan , kryptografická knihovna s licencí BSD napsaná v jazyce C ++.
  • BSAFE Micro Edition Suite: multiplatformní implementace TLS napsaná v jazyce C pomocí kryptografického modulu ověřeného FIPS
  • BSAFE SSL-J: knihovna TLS poskytující proprietární API i JSSE API pomocí kryptografického modulu ověřeného FIPS
  • cryptlib : přenosná open source kryptografická knihovna (zahrnuje implementaci TLS/SSL)
  • Programátoři Delphi mohou používat knihovnu s názvem Indy, která využívá OpenSSL nebo alternativně ICS, která nyní podporuje TLS 1.3.
  • GnuTLS : bezplatná implementace (s licencí LGPL)
  • Rozšíření Java Secure Socket : implementace Java zahrnutá v prostředí Java Runtime Environment podporovala TLS 1.1 a 1.2 počínaje jazykem Java 7. (TLS 1.1/1.2 byly ve výchozím nastavení pro klienta v Javě 7 ve výchozím nastavení zakázány, ale byly povoleny v lednu 2017.) Java 11 podporuje TLS 1.3.
  • LibreSSL : vidlice projektu OpenSSL od OpenBSD.
  • MatrixSSL : implementace se dvěma licencemi
  • mbed TLS (dříve PolarSSL): Malá implementace knihovny SSL pro integrovaná zařízení, která je navržena pro snadné použití
  • Služby zabezpečení sítě : otevřená knihovna s ověřením FIPS 140
  • OpenSSL : bezplatná implementace (licence BSD s některými rozšířeními)
  • SChannel : implementace SSL a TLS Microsoft Windows jako součást jeho balíčku.
  • Zabezpečená doprava : implementace SSL a TLS používaná v OS X a iOS jako součást jejich balíčků.
  • wolfSSL (dříve CyaSSL): Integrovaná knihovna SSL/TLS se silným zaměřením na rychlost a velikost.
Podpora knihovny pro TLS/SSL
Implementace SSL 2.0 (nezabezpečené) SSL 3.0 (nezabezpečené) TLS 1.0 TLS 1.1 TLS 1.2 TLS 1.3
Botan Ne Ne Ano Ano Ano
Sada BSAFE Micro Edition Ne Ve výchozím nastavení zakázáno Ano Ano Ano Ve vývoji
BSAFE SSL-J Ne Ve výchozím nastavení zakázáno Ano Ano Ano Ano
cryptlib Ne Ve výchozím nastavení zakázáno v době kompilace Ano Ano Ano
GnuTLS Ne Ve výchozím nastavení zakázáno Ano Ano Ano Ano
Rozšíření Java Secure Socket Ne Ve výchozím nastavení zakázáno Ano Ano Ano Ano
LibreSSL Ne Ne Ano Ano Ano Od verze 3.2.2
MatrixSSL Ne Ve výchozím nastavení zakázáno v době kompilace Ano Ano Ano ano
(konceptní verze)
mbed TLS (dříve PolarSSL) Ne Ve výchozím nastavení zakázáno Ano Ano Ano
Služby zabezpečení sítě Ne Ve výchozím nastavení zakázáno Ano Ano Ano Ano
OpenSSL Ne Ve výchozím nastavení povoleno Ano Ano Ano Ano
SChannel XP / 2003 Ve výchozím nastavení zakázáno MSIE 7 Ve výchozím nastavení povoleno Ve výchozím nastavení povoleno MSIE 7 Ne Ne Ne
SChannel Vista Ve výchozím nastavení zakázáno Ve výchozím nastavení povoleno Ano Ne Ne Ne
SChannel 2008 Ve výchozím nastavení zakázáno Ve výchozím nastavení povoleno Ano Ve výchozím nastavení zakázáno (KB4019276) Ve výchozím nastavení zakázáno (KB4019276) Ne
SChannel 7 /2008 R2 Ve výchozím nastavení zakázáno Ve výchozím nastavení zakázáno v MSIE 11 Ano Ve výchozím nastavení povoleno MSIE 11 Ve výchozím nastavení povoleno MSIE 11 Ne
SChannel 8/2012 Ve výchozím nastavení zakázáno Ve výchozím nastavení povoleno Ano Ve výchozím nastavení zakázáno Ve výchozím nastavení zakázáno Ne
SChannel 8.1 / 2012 R2, 10 v1507 a v1511 Ve výchozím nastavení zakázáno Ve výchozím nastavení zakázáno v MSIE 11 Ano Ano Ano Ne
SChannel 10 v1607 / 2016 Ne Ve výchozím nastavení zakázáno Ano Ano Ano Ne
SChannel 10 v1903 Ne Ve výchozím nastavení zakázáno Ano Ano Ano Ne
SChannel 10 v21H1 Ne Ve výchozím nastavení zakázáno Ano Ano Ano Ne
Secure Transport OS X 10.2–10.8 / iOS 1–4 Ano Ano Ano Ne Ne
Secure Transport OS X 10.9–10.10 / iOS 5–8 Ne Ano Ano Ano Ano
Secure Transport OS X 10.11 / iOS 9 Ne Ne Ano Ano Ano
Knihovna Seed7 TLS/SSL Ne Ano Ano Ano Ano
wolfSSL (dříve CyaSSL) Ne Ve výchozím nastavení zakázáno Ano Ano Ano Ano
Implementace SSL 2.0 (nezabezpečené) SSL 3.0 (nezabezpečené) TLS 1.0 TLS 1.1 TLS 1.2 TLS 1.3
  1. ^
    Dobrý den pro klienta SSL 2.0 je podporován, i když SSL 2.0 není podporován nebo je zakázán z důvodu zpětné kompatibility.
  2. ^
    Implementace protokolu SSL/TLS na straně serveru stále podporuje zpracování přijatých zpráv klienta hello kompatibilních s v2.
  3. ^
    Zabezpečená doprava: SSL 2.0 byl v OS X 10.8 ukončen. SSL 3.0 byl ukončen v OS X 10.11 a iOS 9. TLS 1.1 a 1.2 jsou k dispozici pro iOS 5.0 a novější a OS X 10.9 a novější.

Příspěvek představený na konferenci ACM 2012 o zabezpečení počítačů a komunikací ukázal, že několik aplikací správně používalo některé z těchto knihoven SSL, což vedlo k zranitelnostem. Podle autorů

"hlavní příčinou většiny těchto zranitelností je hrozný design rozhraní API pro základní knihovny SSL. Namísto vyjadřování vlastností zabezpečení na vysoké úrovni síťových tunelů, jako je důvěrnost a autentizace, tato rozhraní API odhalují podrobnosti o protokolu SSL na nízké úrovni" vývojářům aplikací. V důsledku toho vývojáři často používají rozhraní SSL API nesprávně, což si špatně vykládají a nechápou jejich mnohočetné parametry, možnosti, vedlejší efekty a návratové hodnoty. “

Jiné použití

Simple Mail Transfer Protocol (SMTP) může být také chráněna TLS. Tyto aplikace používají k ověření identity koncových bodů certifikáty veřejného klíče .

TLS lze také použít k tunelování celého síťového zásobníku k vytvoření VPN , což je případ OpenVPN a OpenConnect . Mnoho prodejců se již spojilo s možnostmi šifrování a autentizace TLS s autorizací. Od konce devadesátých let došlo také k významnému rozvoji při vytváření klientské technologie mimo webové prohlížeče, aby byla umožněna podpora aplikací klient/server. Ve srovnání s tradičními technologiemi VPN IPsec má TLS určité přirozené výhody v procházení brány firewall a NAT, které usnadňují správu pro velké populace vzdáleného přístupu.

TLS je také standardní metodou ochrany signalizace aplikace SIP ( Session Initiation Protocol ). TLS lze použít k poskytování autentizace a šifrování signalizace SIP spojené s VoIP a dalšími aplikacemi založenými na SIP.

Bezpečnostní

Útočí proti TLS/SSL

Významné útoky proti TLS/SSL jsou uvedeny níže.

V únoru 2015 vydal IETF informační RFC shrnující různé známé útoky proti TLS/SSL.

Přehodnocení útoku

V srpnu 2009 byla objevena zranitelnost postupu opětovného vyjednávání, která může vést k útokům injekcí prostého textu proti SSL 3.0 a všem současným verzím TLS. Například umožňuje útočníkovi, který může unést připojení https, spojit své vlastní požadavky na začátek konverzace, kterou má klient s webovým serverem. Útočník ve skutečnosti nemůže dešifrovat komunikaci klient-server, takže se liší od typického útoku typu man-in-the-middle. Krátkodobá oprava je, aby webové servery přestaly umožňovat opětovné vyjednávání, což obvykle nevyžaduje další změny, pokud není použito ověřování pomocí klientského certifikátu . K opravě této chyby zabezpečení bylo pro TLS navrženo rozšíření indikace opětovného vyjednávání. Bude vyžadovat, aby klient a server zahrnuli a ověřili informace o předchozích handshakech do jakýchkoli handshakes při opětovném vyjednávání. Toto rozšíření se stalo navrhovaným standardem a bylo mu přiděleno číslo RFC  5746 . RFC bylo implementováno několika knihovnami.

Downgrade útoky: FREAK útok a Logjam útok

Útok na nižší verzi protokolu (nazývaný také útok na vrácení verze) přiměje webový server, aby vyjednal spojení s předchozími verzemi TLS (jako je SSLv2), které byly již dávno opuštěny jako nezabezpečené.

Předchozí úpravy původních protokolů, jako False Start (přijatý a povolený prohlížečem Google Chrome) nebo Snap Start , údajně zavedly omezené útoky na downgrade protokolu TLS nebo umožnily úpravy seznamu šifrovacích sad zasílaných klientem na server. Přitom by se útočníkovi mohlo podařit ovlivnit výběr šifrovací sady ve snaze downgradovat šifrovací sadu vyjednanou tak, aby používala buď slabší symetrický šifrovací algoritmus, nebo slabší výměnu klíčů. Článek prezentovaný na konferenci ACM o zabezpečení počítačů a komunikací v roce 2012 ukázal, že rozšíření False Start bylo ohroženo: za určitých okolností by útočníkovi mohlo umožnit obnovit šifrovací klíče offline a získat přístup k šifrovaným datům.

Útoky na nižší úroveň šifrování mohou přinutit servery a klienty vyjednat připojení pomocí kryptograficky slabých klíčů. V roce 2014 byl objeven útok typu man-in-the-middle s názvem FREAK, který ovlivnil zásobník OpenSSL , výchozí webový prohlížeč Android a některé prohlížeče Safari . Útok zahrnoval podvádění serverů k vyjednávání o připojení TLS pomocí kryptograficky slabých 512bitových šifrovacích klíčů.

Logjam je bezpečnostní exploit objevil v květnu 2015, který využívá možnost použití odkazu „Export-grade“ 512-bit Diffie-Hellman skupiny se datuje do 1990. Nutí náchylné servery přejít na kryptograficky slabé 512bitové skupiny Diffie – Hellman. Útočník pak může odvodit klíče, které klient a server určí, pomocí výměny klíčů Diffie – Hellman .

Útoky mezi protokoly: DROWN

Utopit útok je zneužít, že útoky servery podporující současný SSL / TLS protokolu apartmá využívat k tomu jejich podporu pro zastaralé, nejisté, SSLv2 protokol využít k útoku na připojení pomocí up-to-date protokoly, které by jinak byly v bezpečí. DROWN využívá spíše zranitelnost použitých protokolů a konfigurace serveru než jakoukoli konkrétní chybu implementace. Úplné podrobnosti o DROWN byly oznámeny v březnu 2016 spolu s opravou pro exploit. V té době patřilo více než 81 000 z 1 milionu nejoblíbenějších webů mezi weby chráněné TLS, které byly zranitelné útokem DROWN.

BEAST útok

Dne 23. září 2011 výzkumníci Thai Duong a Juliano Rizzo předvedli důkaz konceptu s názvem BEAST ( Browser Exploit Against SSL/TLS ) pomocí Java appletu k porušení stejných omezení politiky původu , za dlouho známou zranitelnost šifrovacích blokových řetězců (CBC) v TLS 1.0: útočník pozorující 2 po sobě jdoucí bloky šifrovacího textu C0, C1 může testovat, zda je prostý textový blok P1 roven x výběrem dalšího bloku prostého textu P2 = x C0 C1; podle operace CBC C2 = E (C1 P2) = E (C1 x C0 C1) = E (C0 x), což se bude rovnat C1, pokud x = P1. Praktické exploity nebyly u této zranitelnosti dříve prokázány , což původně objevil Phillip Rogaway v roce 2002. Zranitelnost útoku byla opravena pomocí TLS 1.1 v roce 2006, ale TLS 1.1 nebyl před touto demonstrací útoku široce přijat.

RC4 jako proudová šifra je imunní vůči útoku BEAST. Proto byl RC4 široce používán jako způsob, jak zmírnit útok BEAST na straně serveru. V roce 2013 však výzkumníci zjistili více slabin v RC4. Poté již nebylo doporučeno povolit RC4 na straně serveru.

Chrome a Firefox samy o sobě nejsou náchylné k útoku BEAST, nicméně Mozilla aktualizovala své knihovny NSS, aby zmírnila útoky podobné BEAST . NSS používají Mozilla Firefox a Google Chrome k implementaci SSL. Některé webové servery, které mají nefunkční implementaci specifikace SSL, mohou v důsledku toho přestat fungovat.

Společnost Microsoft vydala 10. ledna 2012 bulletin zabezpečení MS12-006, který opravil zranitelnost BEAST změnou způsobu, jakým součást Windows Secure Channel ( SChannel ) přenáší šifrované síťové pakety z konce serveru. Uživatelé Internet Exploreru (před verzí 11), kteří běží na starších verzích Windows ( Windows 7 , Windows 8 a Windows Server 2008 R2 ), mohou omezit používání TLS na 1.1 nebo vyšší.

Apple opravil zranitelnost BEAST implementací rozdělení 1/n-1 a jeho výchozím zapnutím v OS X Mavericks , vydaném 22. října 2013.

ÚČINKY a PORUŠENÍ útoků

Autoři útoku BEAST jsou také tvůrci pozdějšího útoku CRIME , který může útočníkovi umožnit obnovit obsah webových cookies, když je spolu s TLS použita komprese dat . Když se používá k obnovení obsahu tajných ověřovacích souborů cookie , umožňuje útočníkovi provést únos relace na ověřené webové relaci.

Zatímco útok CRIME byl prezentován jako obecný útok, který by mohl účinně fungovat proti velkému počtu protokolů, mimo jiné včetně TLS, a protokoly aplikační vrstvy, jako je SPDY nebo HTTP , byly demonstrovány a do značné míry zmírněny pouze exploity proti TLS a SPDY v prohlížečích a serverech. Využití CRIME proti kompresi HTTP nebylo vůbec zmírněno, přestože autoři CRIME varovali, že tato chyba zabezpečení může být ještě rozšířenější než kombinace komprese SPDY a TLS. V roce 2013 byla oznámena nová instance útoku CRIME proti kompresi HTTP, nazvaná BREACH . Na základě útoku CRIME může útok BREACH extrahovat přihlašovací tokeny, e -mailové adresy nebo jiné citlivé informace ze šifrovaného webového provozu TLS za pouhých 30 sekund (v závislosti na počtu extrahovaných bajtů) za předpokladu, že útočník oklamá oběť, aby navštívila škodlivý webový odkaz nebo je schopen vložit obsah na platné stránky, které uživatel navštěvuje (např. bezdrátová síť pod kontrolou útočníka). Všechny verze TLS a SSL jsou ohroženy PORUŠENÍM bez ohledu na použitý šifrovací algoritmus nebo šifru. Na rozdíl od předchozích instancí CRIME, proti nimž se lze úspěšně bránit vypnutím komprese TLS nebo komprimace SPDY, využívá BREACH kompresi HTTP, kterou nelze realisticky vypnout, protože prakticky všechny webové servery na ni spoléhají při zlepšování rychlosti přenosu dat pro uživatele. Toto je známé omezení TLS, protože je náchylné k útoku zvoleného prostého textu proti datům aplikační vrstvy, která byla určena k ochraně.

Načasování útoků na polstrování

Dřívější verze TLS byly zranitelné vůči polstrujícímu útoku věštec objevenému v roce 2002. V roce 2013 byla zveřejněna nová varianta, nazvaná Lucky Thirteen útok .

Někteří odborníci také doporučili vyhnout se Triple-DES CBC. Vzhledem k tomu, že poslední podporované šifry vyvinut pro podporu libovolný program pomocí systému Windows XP SSL ‚s / TLS knihovna jako Internet Explorer v systému Windows XP jsou RC4 a Triple-DES, a protože RC4 je nyní zastaralé (viz diskuse o RC4 útoků ), to ztěžuje podporovat jakoukoli verzi SSL pro jakýkoli program využívající tuto knihovnu v systému XP.

Oprava byla vydána jako rozšíření Encrypt-then-MAC ke specifikaci TLS vydané jako RFC  7366 . Útok Lucky Thirteen lze v TLS 1.2 zmírnit pouze pomocí šifer AES_GCM; AES_CBC zůstává zranitelný.

POODLE útok

14. října 2014 vědci společnosti Google zveřejnili chybu zabezpečení v návrhu SSL 3.0, díky které je režim provozu CBC s SSL 3.0 zranitelný vůči útoku padding ( CVE - 2014-3566 ). Tento útok pojmenovali POODLE ( Padding Oracle On Downgraded Legacy Encryption ). Útočníkům stačí k odhalení jednoho bajtu šifrovaných zpráv v průměru zadat pouze 256 požadavků SSL 3.0.

Ačkoli tato chyba zabezpečení existuje pouze v SSL 3.0 a většina klientů a serverů podporuje TLS 1.0 a vyšší, všechny hlavní prohlížeče dobrovolně přejdou na SSL 3.0, pokud se nezdaří handshakes s novějšími verzemi TLS, pokud neposkytnou uživateli nebo správci možnost zakázat SSL 3.0 a uživatel nebo správce tak činí. Man-in-the-mid proto může nejprve provést útok na vrácení verze a poté tuto chybu zabezpečení zneužít.

Dne 8.

Útoky RC4

Navzdory existenci útoků na RC4, které narušily jeho zabezpečení, byly šifrovací sady v SSL a TLS, které byly založeny na RC4, stále považovány za bezpečné před rokem 2013 na základě způsobu, jakým byly použity v SSL a TLS. V roce 2011 byla sada RC4 skutečně doporučena jako řešení útoku BEAST . Nové formy útoku zveřejněné v březnu 2013 přesvědčivě prokázaly proveditelnost prolomení RC4 v TLS, což naznačuje, že to nebylo dobré řešení pro BEAST. AlFardan, Bernstein, Paterson, Poettering a Schuldt navrhli scénář útoku, který použil nově objevené statistické zkreslení v tabulce klíčů RC4 k obnovení částí holého textu s velkým počtem šifrování TLS. Útok na RC4 v TLS a SSL, který k rozbití RC4 vyžaduje 13 × 2 20 šifrování, byl odhalen 8. července 2013 a později byl popsán jako „proveditelný“ v doprovodné prezentaci na bezpečnostním sympoziu USENIX v srpnu 2013. V červenci 2015 následovala další vylepšení při útoku je stále praktičtější porazit zabezpečení TLS šifrovaného RC4.

Protože mnoho moderních prohlížečů bylo navrženo tak, aby porazily útoky BEAST (kromě Safari pro Mac OS X 10.7 nebo starší, pro iOS 6 nebo starší a pro Windows; viz § Webové prohlížeče ), RC4 již není dobrou volbou pro TLS 1.0. Šifry CBC, které byly v minulosti ovlivněny útokem BEAST, se staly populárnější volbou pro ochranu. Mozilla a Microsoft doporučují vypnout RC4, kde je to možné. RFC  7465 zakazuje používání šifrovacích sad RC4 ve všech verzích TLS.

1. září 2015 společnosti Microsoft, Google a Mozilla oznámily, že šifrovací sady RC4 budou ve výchozím nastavení ve svých prohlížečích ( Microsoft Edge , Internet Explorer 11 ve Windows 7/8.1/10, Firefox a Chrome ) počátkem roku 2016 deaktivovány .

Zkrácení útoku

Útok zkrácení TLS (odhlášení) blokuje požadavky na odhlášení účtu oběti, takže uživatel nevědomky zůstane přihlášen k webové službě. Když je odeslán požadavek na odhlášení, útočník vloží nešifrovanou zprávu TCP FIN (žádná další data od odesílatele), aby se připojení ukončilo. Server proto neobdrží žádost o odhlášení a neví o neobvyklém ukončení.

Zveřejněn v červenci 2013, útok způsobí, že webové služby, jako jsou Gmail a Hotmail , zobrazí stránku, která uživatele informuje o tom, že se úspěšně odhlásil, a zároveň zajistí, aby si prohlížeč uživatele udržoval autorizaci se službou, což útočníkovi s následným přístupem umožní prohlížeč k přístupu a převzetí kontroly nad přihlášeným účtem uživatele. Útok nezávisí na instalaci malwaru do počítače oběti; útočníkům stačí, aby se umístili mezi obětí a webovým serverem (např. nastavením nepoctivého bezdrátového hotspotu). Tato chyba zabezpečení také vyžaduje přístup k počítači oběti. Další možností je, že při použití FTP může mít datové připojení v datovém proudu falešné FIN, a pokud nebudou dodržena pravidla protokolu pro výměnu výstrah close_notify k souboru, může být zkrácen.

Bezbožný útok PAC

Tento útok, objevený v polovině roku 2016, využívá slabiny protokolu WPAD ( Web Proxy Autodiscovery Protocol ) k odhalení adresy URL, na kterou se webový uživatel pokouší dosáhnout prostřednictvím webového odkazu s podporou TLS. Zveřejnění adresy URL může narušit soukromí uživatele, a to nejen kvůli navštíveným webovým stránkám, ale také proto, že adresy URL se někdy používají k autentizaci uživatelů. Služby sdílení dokumentů, jako jsou služby nabízené společnostmi Google a Dropbox, fungují také tak, že uživateli pošlete token zabezpečení, který je součástí adresy URL. Útočník, který získá takové adresy URL, může získat plný přístup k účtu nebo údajům oběti.

Exploit funguje proti téměř všem prohlížečům a operačním systémům.

Sweet32 útok

Útok Sweet32 přeruší všechny 64bitové blokové šifry používané v režimu CBC, jak se používají v TLS, využíváním útoku narozenin a buď útoku typu man-in-the-middle, nebo vložením škodlivého JavaScriptu na webovou stránku. Účelem útoku typu man-in-the-middle nebo JavaScriptu je umožnit útočníkovi zachytit dostatečnou návštěvnost, aby mohl zahájit narozeninový útok.

Chyby implementace: Upřímná chyba, Útok BERserk, chyba Cloudflare

Heartbleed chyba je vážná zranitelnosti specifické pro implementaci SSL / TLS v populární OpenSSL knihovny šifrovací software, který ovlivňuje verze 1.0.1 pro 1.0.1f. Tato slabina, hlášená v dubnu 2014, umožňuje útočníkům ukrást soukromé klíče ze serverů, které by za normálních okolností měly být chráněny. Chyba Heartbleed umožňuje komukoli na internetu číst paměť systémů chráněných zranitelnými verzemi softwaru OpenSSL. To kompromituje tajné soukromé klíče spojené s veřejnými certifikáty používanými k identifikaci poskytovatelů služeb a k šifrování provozu, jmen a hesel uživatelů a skutečného obsahu. To umožňuje útočníkům odposlouchávat komunikaci, krást data přímo od služeb a uživatelů a vydávat se za služby a uživatele. Tato chyba zabezpečení je způsobena spíše chybou při čtení vyrovnávací paměti v softwaru OpenSSL, než vadou specifikace protokolu SSL nebo TLS.

V září 2014 byla Intel Security Advanced Threat Research oznámena varianta zranitelnosti PKCS#1 v1.5 RSA Signature Forgery Daniela Bleichenbachera . Tento útok, nazvaný BERserk, je výsledkem neúplného dekódování podpisů veřejného klíče v některých implementacích SSL na délku ASN.1 a umožňuje útok typu man-in-the-middle vytvořením podpisu veřejného klíče.

V únoru 2015 poté, co média informovala o skryté předinstalaci adwaru Superfish na některých noteboocích Lenovo, zjistil výzkumník důvěryhodný kořenový certifikát na postižených počítačích Lenovo jako nejistý, protože ke klíčům lze snadno přistupovat pomocí názvu společnosti, Komodia, as heslo. Knihovna Komodia byla navržena k zachycení provozu TLS/SSL na straně klienta pro rodičovskou kontrolu a dohled, ale byla také použita v mnoha adware programech, včetně Superfish, které byly často tajně instalovány bez vědomí uživatele počítače. Na druhé straně tyto potenciálně nežádoucí programy nainstalovaly poškozený kořenový certifikát, což útočníkům umožnilo zcela kontrolovat webový provoz a potvrzovat falešné weby jako autentické.

V květnu 2016 bylo oznámeno, že desítky dánských webů chráněných HTTPS patřících společnosti Visa Inc. byly zranitelné vůči útokům, které hackerům umožňovaly vkládat škodlivý kód a padělaný obsah do prohlížečů návštěvníků. Útoky fungovaly, protože implementace TLS použitá na dotčených serverech nesprávně znovu použila náhodná čísla ( nonces ), která jsou určena k použití pouze jednou, což zajišťuje, že každé podání ruky TLS je jedinečné.

V únoru 2017 vytvořila chyba implementace způsobená jediným chybně zadaným znakem v kódu použitém k analýze HTML chybu přetečení vyrovnávací paměti na serverech Cloudflare . Podobně jako v případě chyby Heartbleed objevené v roce 2014, tato chyba přetečení, obecně známá jako Cloudbleed , umožnila neoprávněným třetím stranám číst data v paměti programů běžících na serverech - data, která by jinak měla být chráněna protokolem TLS.

Průzkum webů ohrožených útoky

V červenci 2021 odhadovalo Důvěryhodné internetové hnutí poměr webů, které jsou citlivé na útoky TLS.

Přehled zranitelností TLS nejpopulárnějších webů
Útoky Bezpečnostní
Nejistý Záleží Zajistit jiný
Přehodnocení útoku 0,1%
podporuje nejisté opětovné vyjednávání
<0,1%
podporuje obojí
99,2%
podporuje bezpečné opětovné vyjednávání
0,7%
bez podpory
Útoky RC4 0,4%
podporuje sady RC4 používané v moderních prohlížečích
6,5%
podporuje některé sady RC4
93,1%
bez podpory
N/A
Komprese TLS (útok CRIME) > 0,0%
zranitelné
N/A N/A N/A
Se srdcem > 0,0%
zranitelné
N/A N/A N/A
ChangeCipherSpec injekční útok 0,1%
zranitelnosti a zneužití
0,2%
zranitelných, nevyužitelných
98,5%
není zranitelných
1,2%
neznámé
Útok POODLE proti TLS
(původní POODLE proti SSL 3.0 není součástí dodávky)
0,1%
zranitelnosti a zneužití
0,1%
zranitelných, nevyužitelných
99,8%
není zranitelných
0,2%
neznámé
Downgrade protokolu 6,6%
Obrana proti downgradu není podporována
N/A
Podporována obrana downgrade 72,3%
21,0%
neznámé

Vpřed tajemství

Forward secrecy je vlastnost kryptografických systémů, která zajišťuje, že klíč relace odvozený ze sady veřejných a soukromých klíčů nebude ohrožen, pokud bude v budoucnu kompromitován jeden ze soukromých klíčů. Bez dopředného utajení budou v případě kompromitace soukromého klíče serveru ohroženy nejen všechny budoucí relace šifrované pomocí TLS pomocí tohoto certifikátu serveru, ale také všechny předchozí relace, které jej také používaly (samozřejmě za předpokladu, že tyto minulé relace byly zachyceny a uloženy v době přenosu). Implementace TLS může zajistit dopředné utajení tím, že vyžaduje použití pomíjivé výměny klíčů Diffie – Hellman k vytvoření klíčů relace a některé pozoruhodné implementace TLS tak činí výhradně: např. Gmail a další služby Google HTTPS využívající OpenSSL . Mnoho klientů a serverů podporujících TLS (včetně prohlížečů a webových serverů) však není nakonfigurováno k implementaci takových omezení. V praxi, pokud webová služba nepoužívá výměnu klíčů Diffie – Hellman k implementaci dopředného utajení, veškerý šifrovaný webový provoz do az této služby může být dešifrován třetí stranou, pokud získá hlavní (soukromý) klíč serveru; např. soudním příkazem.

I tam, kde je implementována výměna klíčů Diffie – Hellman, mohou mechanismy správy relací na straně serveru ovlivnit dopředné utajení. Použití lístků na relaci TLS (rozšíření TLS) způsobí, že relace bude chráněna AES128-CBC-SHA256 bez ohledu na jakékoli jiné sjednané parametry TLS, včetně cifersuites pro dopředné utajení, a klíče lístku do relace TLS s dlouhou životností znemožní pokus o implementaci dopředu utajení. Výzkum Stanfordské univerzity v roce 2014 také zjistil, že ze 473 802 zkoumaných serverů TLS 82,9% serverů využívajících dočasnou výměnu klíčů Diffie – Hellman (DHE) na podporu dopředného utajení používalo slabé parametry Diffie – Hellman. Tyto slabé volby parametrů by mohly potenciálně ohrozit účinnost dopředného utajení, které se servery snažily poskytnout.

Od konce roku 2011 poskytuje společnost Google uživatelům své služby Gmail ve výchozím nastavení dopředné utajení pomocí TLS , spolu s Dokumenty Google a šifrovaným vyhledáváním, mimo jiné. Od listopadu 2013 poskytuje Twitter uživatelům své služby dopředu utajení pomocí TLS. V srpnu 2019 je asi 80% webů s podporou TLS nakonfigurováno tak, aby používaly šifrovací sady, které většině webových prohlížečů poskytují utajení.

Odposlech TLS

Zachycení TLS (nebo zachycení HTTPS, je- li aplikováno zejména na tento protokol) je praxe zachycení šifrovaného datového proudu za účelem jeho dešifrování, čtení a případné manipulace s ním a poté opětovného zašifrování a odeslání dat na jeho cestu znovu. To se provádí pomocí „ transparentního proxy “: software pro odposlech ukončí příchozí připojení TLS, zkontroluje prostý text HTTP a poté vytvoří nové připojení TLS k cíli.

Zachycování TLS / HTTPS používají operátoři sítí jako opatření k zabezpečení informací , aby mohli vyhledávat a chránit se před vniknutím škodlivého obsahu do sítě, jako jsou počítačové viry a další malware . Takový obsah by jinak nemohl být detekován, pokud je chráněn šifrováním, což je stále častější v důsledku rutinního používání HTTPS a dalších zabezpečených protokolů.

Významnou nevýhodou odposlechu TLS / HTTPS je, že přináší nová vlastní bezpečnostní rizika. Jedním z pozoruhodných omezení je, že poskytuje místo, kde je síťový provoz k dispozici nešifrovaný, což dává útočníkům podnět k útoku na tento bod, zejména za účelem získání přístupu k jinak zabezpečenému obsahu. Odposlech také umožňuje provozovateli sítě nebo osobám, které získají přístup k jeho odposlechovému systému, provádět útoky typu man-in-the-middle proti uživatelům sítě. Studie z roku 2017 zjistila, že „odposlechy HTTPS se překvapivě rozšířily a že odposlouchávací produkty jako třída mají dramaticky negativní dopad na zabezpečení připojení“.

Podrobnosti o protokolu

Protokol TLS vyměňuje záznamy , které zapouzdřují data, která mají být vyměňována, ve specifickém formátu (viz níže). Každý záznam může být komprimovaný, polstrovaný, připojený pomocí ověřovacího kódu zprávy (MAC) nebo šifrovaný, vše v závislosti na stavu připojení. Každý záznam má pole typu obsahu, které určuje typ zapouzdřených dat, pole délky a pole verze TLS. Zapouzdřená data mohou být řídicí nebo procedurální zprávy samotného TLS nebo jednoduše data aplikace potřebná k přenosu pomocí TLS. Specifikace (šifrovací sada, klíče atd.) Požadované pro výměnu aplikačních dat pomocí TLS jsou dohodnuty v „handshake TLS“ mezi klientem požadujícím data a serverem reagujícím na požadavky. Protokol proto definuje jak strukturu užitečného zatížení přeneseného v TLS, tak postup pro stanovení a monitorování přenosu.

TLS handshake

Zjednodušená ilustrace úplného podání ruky TLS 1.2 s informacemi o načasování.

Když se připojení spustí, záznam zapouzdří „kontrolní“ protokol - protokol pro zasílání zpráv o handshake ( typ obsahu 22). Tento protokol se používá k výměně všech informací požadovaných oběma stranami pro výměnu skutečných dat aplikace prostřednictvím TLS. Definuje formát zpráv a pořadí jejich výměny. Ty se mohou lišit podle požadavků klienta a serveru - tj. Existuje několik možných postupů pro nastavení připojení. Tato počáteční výměna má za následek úspěšné připojení TLS (obě strany jsou připraveny přenášet data aplikace pomocí TLS) nebo výstražnou zprávu (jak je uvedeno níže).

Základní podání ruky TLS

Následuje typický příklad připojení, který ilustruje handshake, kde je server (ale ne klient) ověřen svým certifikátem:

  1. Fáze vyjednávání:
    • Klient odešle zprávu ClientHello určující nejvyšší verzi protokolu TLS, kterou podporuje, náhodné číslo, seznam doporučených šifrovacích sad a doporučené metody komprese. Pokud se klient pokouší provést obnovení handshake, může odeslat ID relace . Pokud klient může použít vyjednávání protokolu aplikační vrstvy , může obsahovat seznam podporovaných aplikačních protokolů , například HTTP/2 .
    • Server odpoví zprávou ServerHello , která obsahuje zvolenou verzi protokolu, náhodné číslo, šifrovací sadu a metodu komprese z možností nabízených klientem. Za účelem potvrzení nebo povolení obnoveného potřesení rukou může server odeslat ID relace . Zvolená verze protokolu by měla být nejvyšší, kterou klient i server podporují. Pokud například klient podporuje TLS verze 1.1 a server podporuje verzi 1.2, měla by být vybrána verze 1.1; verze 1.2 by neměla být vybrána.
    • Server odešle svou zprávu o certifikátu (v závislosti na zvolené šifrovací sadě to může server vynechat).
    • Server odešle svou zprávu ServerKeyExchange (v závislosti na zvolené šifrovací sadě to může server vynechat). Tato zpráva je odeslána pro všechny šifrovací sady DHE , ECDHE a DH_anon.
    • Server odešle zprávu ServerHelloDone , která označuje, že se provádí vyjednávání handshake.
    • Klient odpoví zprávou ClientKeyExchange , která může obsahovat PreMasterSecret , veřejný klíč nebo nic. (Opět to závisí na zvolené šifře.) Tento PreMasterSecret je šifrován pomocí veřejného klíče certifikátu serveru.
    • Klient a server poté použijí náhodná čísla a PreMasterSecret k výpočtu společného tajemství, kterému se říká „hlavní tajemství“. Všechna ostatní klíčová data ( relační klíče, jako jsou IV , symetrický šifrovací klíč, MAC klíč) pro toto připojení jsou odvozena z tohoto hlavního tajemství (a náhodných hodnot generovaných klientem a serverem), která jsou předávána pečlivě navrženou pseudonáhodnou funkcí.
  2. Klient nyní odešle záznam ChangeCipherSpec , v podstatě sdělující serveru: „Vše, co vám od této chvíle řeknu, bude ověřeno (a zašifrováno, pokud byly v certifikátu serveru přítomny parametry šifrování).“ ChangeCipherSpec je sám protokol na úrovni záznamu s typem obsahu 20.
    • Klient odešle ověřenou a šifrovanou dokončenou zprávu obsahující hash a MAC přes předchozí zprávy handshake.
    • Server se pokusí dešifrovat klientovu zprávu Hotovo a ověří hash a MAC. Pokud dešifrování nebo ověření selže, považuje se podání ruky za neúspěšné a připojení by mělo být přerušeno.
  3. Nakonec server odešle ChangeCipherSpec a řekne klientovi: „Všechno, co vám od této chvíle řeknu, bude ověřeno (a šifrováno, pokud bylo dohodnuto šifrování).“
    • Server odešle svou ověřenou a šifrovanou zprávu Dokončeno .
    • Klient provádí stejnou dešifrovací a ověřovací proceduru jako server v předchozím kroku.
  4. Fáze aplikace: v tomto okamžiku je „handshake“ dokončen a je povolen aplikační protokol s typem obsahu 23. Zprávy aplikací vyměňované mezi klientem a serverem budou také ověřeny a volitelně zašifrovány přesně jako v jejich dokončené zprávě. Jinak typ obsahu vrátí 25 a klient se neověří.

Handshake TLS ověřený klientem

Následující úplný příklad ukazuje, že klient je ověřován (kromě serveru jako ve výše uvedeném příkladu; viz vzájemné ověřování ) prostřednictvím TLS pomocí certifikátů vyměněných mezi oběma peer.

  1. Fáze vyjednávání:
    • Klient odešle zprávu ClientHello určující nejvyšší verzi protokolu TLS, kterou podporuje, náhodné číslo, seznam navrhovaných šifrovacích sad a metody komprese.
    • Server odpoví zprávou ServerHello , která obsahuje zvolenou verzi protokolu, náhodné číslo, šifrovací sadu a metodu komprese z možností nabízených klientem. Server může také odeslat ID relace jako součást zprávy, aby provedl obnovené handshake.
    • Server odešle svou zprávu o certifikátu (v závislosti na zvolené šifrovací sadě to může server vynechat).
    • Server odešle svou zprávu ServerKeyExchange (v závislosti na zvolené šifrovací sadě to může server vynechat). Tato zpráva je odeslána pro všechny cifersuity DHE, ECDHE a DH_anon.
    • Server odešle zprávu CertificateRequest na vyžádání certifikátu od klienta.
    • Server odešle zprávu ServerHelloDone , která označuje, že se provádí vyjednávání handshake.
    • Klient odpoví zprávou s certifikátem , která obsahuje certifikát klienta.
    • Klient odešle zprávu ClientKeyExchange , která může obsahovat PreMasterSecret , veřejný klíč nebo nic. (Opět to závisí na zvolené šifře.) Tento PreMasterSecret je šifrován pomocí veřejného klíče certifikátu serveru.
    • Klient odešle zprávu CertificateVerify , což je podpis přes předchozí zprávy handshake pomocí soukromého klíče certifikátu klienta. Tento podpis lze ověřit pomocí veřejného klíče certifikátu klienta. Server tak bude vědět, že klient má přístup k soukromému klíči certifikátu, a tedy certifikát vlastní.
    • Klient a server poté použijí náhodná čísla a PreMasterSecret k výpočtu společného tajemství, kterému se říká „hlavní tajemství“. Všechna další klíčová data („klíče relace“) pro toto připojení jsou odvozena z tohoto hlavního tajemství (a náhodných hodnot generovaných klientem a serverem), která jsou předávána pečlivě navrženou pseudonáhodnou funkcí.
  2. Klient nyní odešle záznam ChangeCipherSpec , v podstatě říká serveru: „Všechno, co vám odteď řeknu, bude ověřeno (a zašifrováno, pokud bylo sjednáno šifrování).“ ChangeCipherSpec je sám protokolem na úrovni záznamu a má typ 20 a ne 22 .
    • Nakonec klient odešle šifrovanou dokončenou zprávu obsahující hash a MAC přes předchozí zprávy handshake.
    • Server se pokusí dešifrovat klientovu zprávu Hotovo a ověří hash a MAC. Pokud dešifrování nebo ověření selže, považuje se podání ruky za neúspěšné a připojení by mělo být přerušeno.
  3. Nakonec server odešle ChangeCipherSpec a řekne klientovi: „Vše, co vám od této chvíle řeknu, bude ověřeno (a zašifrováno, pokud bylo sjednáno šifrování).“
    • Server odešle vlastní šifrovanou zprávu Dokončeno .
    • Klient provádí stejnou dešifrovací a ověřovací proceduru jako server v předchozím kroku.
  4. Fáze aplikace: v tomto okamžiku je „handshake“ dokončeno a je povolen aplikační protokol s typem obsahu 23. Zprávy aplikací vyměňované mezi klientem a serverem budou také šifrovány přesně jako v jejich dokončené zprávě.

Obnoveno podání ruky TLS

Operace s veřejným klíčem (např. RSA) jsou z hlediska výpočetního výkonu relativně drahé. TLS poskytuje bezpečnou zkratku v mechanismu handshake, aby se zabránilo těmto operacím: obnovené relace. Obnovené relace jsou implementovány pomocí ID relace nebo lístků na relaci.

Kromě výhody pro výkon lze obnovené relace použít také pro jednotné přihlášení , protože zaručuje, že jak původní relace, tak jakákoli obnovená relace pocházejí ze stejného klienta. To je zvláště důležité pro protokol FTP přes TLS/SSL , který by jinak trpěl útokem typu man-in-the-middle, při kterém by útočník mohl zachytit obsah sekundárních datových připojení.

Podání ruky TLS 1.3

Podání ruky TLS 1.3 bylo zhuštěno pouze na jednu zpáteční cestu ve srovnání se dvěma zpátečními jízdami požadovanými v předchozích verzích TLS/SSL.

Nejprve klient odešle zprávu clientHello na server, který obsahuje seznam podporovaných šifer v pořadí podle preferencí klienta, a odhadne, jaký klíčový algoritmus bude použit, aby mohl v případě potřeby odeslat tajný klíč ke sdílení. Hádáním, jaký klíčový algoritmus bude použit, server eliminuje zpáteční cestu. Po obdržení clientHello server odešle serverHello s klíčem, certifikátem, zvolenou šifrovací sadou a dokončenou zprávou.

Poté, co klient obdrží hotovou zprávu serveru, je nyní koordinována se serverem, na kterém se má použít šifrovací sada.

ID relací

Při běžném úplném podání ruky server odešle ID relace jako součást zprávy ServerHello . Klient spojí toto ID relace s IP adresou serveru a portem TCP, takže když se klient znovu připojí k tomuto serveru, může použít ID relace ke zkratce handshake. Na serveru se ID relace mapuje na dříve vyjednané kryptografické parametry, konkrétně „hlavní tajemství“. Obě strany musí mít stejné „hlavní tajemství“, jinak obnovené potřesení rukou selže (to znemožní odposlechu použít ID relace ). Náhodná data ve zprávách ClientHello a ServerHello prakticky zaručují, že se generované klíče připojení budou lišit od v předchozím připojení. V RFC se tento typ handshake nazývá zkráceně handshake. V literatuře je také popisován jako restart handshake.

  1. Fáze vyjednávání:
    • Klient odešle zprávu ClientHello určující nejvyšší verzi protokolu TLS, kterou podporuje, náhodné číslo, seznam navrhovaných šifrovacích sad a metody komprese. Ve zprávě je zahrnuto ID relace z předchozího připojení TLS.
    • Server odpoví zprávou ServerHello , která obsahuje zvolenou verzi protokolu, náhodné číslo, šifrovací sadu a metodu komprese z možností nabízených klientem. Pokud server rozpozná ID relace odeslané klientem, odpoví stejným ID relace . Klient to používá k rozpoznání, že probíhá obnovení handshake. Pokud server nerozpozná ID relace odeslané klientem, odešle pro jeho ID relace jinou hodnotu . To řekne klientovi, že obnovené handshake nebude provedeno. V tomto okamžiku mají klient i server „hlavní tajemství“ a náhodná data pro generování klíčových dat, která budou použita pro toto připojení.
  2. Server nyní odešle záznam ChangeCipherSpec , v podstatě klientovi řekne: „Všechno, co vám od této chvíle řeknu, bude šifrováno.“ ChangeCipherSpec je sám protokol na úrovni záznamu a má typ 20 a ne 22.
    • Nakonec server odešle šifrovanou dokončenou zprávu obsahující hash a MAC přes předchozí zprávy handshake.
    • Klient se pokusí dešifrovat zprávu serveru Dokončeno a ověřit hash a MAC. Pokud dešifrování nebo ověření selže, považuje se podání ruky za neúspěšné a připojení by mělo být přerušeno.
  3. Nakonec klient odešle ChangeCipherSpec a řekne serveru: „Všechno, co vám od této chvíle řeknu, bude šifrováno.“
    • Klient odešle vlastní šifrovanou zprávu Dokončeno .
    • Server provádí stejnou dešifrovací a ověřovací proceduru jako klient v předchozím kroku.
  4. Fáze aplikace: v tomto okamžiku je „handshake“ dokončeno a je povolen aplikační protokol s typem obsahu 23. Zprávy aplikací vyměňované mezi klientem a serverem budou také šifrovány přesně jako v jejich dokončené zprávě.
Vstupenky na zasedání

RFC  5077 rozšiřuje TLS pomocí relačních lístků namísto ID relací. Definuje způsob, jak obnovit relaci TLS bez požadavku, aby byl stav specifický pro relaci uložen na serveru TLS.

Při použití lístků na relace server TLS uloží svůj stav specifický pro relaci do lístku na relaci a odešle lístek na relaci klientovi TLS k uložení. Klient obnoví relaci TLS odesláním lístku relace na server a server obnoví relaci TLS podle stavu specifického pro relaci v lístku. Vstupenka na relaci je šifrována a ověřována serverem a server před použitím jejího obsahu ověří její platnost.

Jednou konkrétní slabinou této metody u OpenSSL je, že vždy omezuje zabezpečení šifrování a autentizace přenášeného lístku relace TLS na AES128-CBC-SHA256bez ohledu na to, jaké další parametry TLS byly sjednány pro aktuální relaci TLS. To znamená, že informace o stavu (lístek relace TLS) nejsou tak dobře chráněny jako samotná relace TLS. Obzvláště znepokojující je ukládání klíčů OpenSSL v kontextu celé aplikace ( SSL_CTX), tj. Po celou dobu životnosti aplikace, a neumožňuje opětovné klíčování AES128-CBC-SHA256lístků relací TLS bez resetování kontextu aplikace OpenSSL v celé aplikaci (což je neobvyklé) , náchylné k chybám a často vyžadují ruční administrativní zásah).

Záznam TLS

Toto je obecný formát všech záznamů TLS.

Formát záznamu TLS, obecný
Ofset Byte +0 Byte +1 Byte +2 Byte +3
Byte
0
Typ obsahu N/A
Byty
1..4
Starší verze Délka
(Hlavní, důležitý) (Méně důležitý) (bity 15..8) (bity 7..0)
Bajty
5 .. ( m −1)
Protokol zprávy
Bajtů
m .. ( p −1)
MAC (volitelně)
Bajty
p .. ( q −1)
Polstrování (pouze blokové šifry)
Typ obsahu
Toto pole identifikuje typ protokolu vrstvy záznamu obsažený v tomto záznamu.
Typy obsahu
Hex Prosince Typ
0x14 20 ChangeCipherSpec
0x15 21 Upozornění
0x16 22 Podání ruky
0x17 23 aplikace
0x18 24 Tlukot srdce
Starší verze
Toto pole identifikuje hlavní a vedlejší verzi TLS před TLS 1.3 pro obsaženou zprávu. U zprávy ClientHello nemusí jít o nejvyšší verzi podporovanou klientem. Pro TLS 1.3 a novější musí být toto nastaveno na 0x0303 a aplikace musí odesílat podporované verze v extra bloku rozšíření zprávy.
Verze
Hlavní
verze
Drobná
verze
Typ verze
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
Délka
Celková délka polí „protokol (y) protokolu“, „MAC“ a „odsazení“ (tj. Q −5) nesmí překročit 2 14 bajtů (16 KiB).
Protokol zprávy
Jedna nebo více zpráv identifikovaných v poli Protokol. Toto pole může být šifrováno v závislosti na stavu připojení.
MAC a polstrování
Autentizační kód zprávy vypočítány nad „protokolové zprávy (y)“ v terénu, s přídavným materiálem klíče hotelu. V závislosti na stavu připojení může být toto pole zašifrováno nebo nemusí být zahrnuto úplně.
Na konci záznamů TLS nemohou být žádná pole „MAC“ nebo „padding“, než budou všechny šifrovací algoritmy a parametry vyjednány a handshakovány a poté potvrzeny odesláním záznamu CipherStateChange (viz níže) pro signalizaci, že tyto parametry budou účinné ve všech další záznamy zaslané stejným partnerem.

Protokol handshake

Většina zpráv vyměňovaných během nastavení relace TLS je založena na tomto záznamu, pokud nedojde k chybě nebo varování a je třeba je signalizovat záznamem protokolu Alert (viz níže), nebo pokud je režim šifrování relace upraven jiným záznamem ( viz protokol ChangeCipherSpec níže).

Formát záznamu TLS pro protokol handshake
Ofset Byte +0 Byte +1 Byte +2 Byte +3
Byte
0
22 N/A
Byty
1..4
Starší verze Délka
(Hlavní, důležitý) (Méně důležitý) (bity 15..8) (bity 7..0)
Bajty
5..8
Typ zprávy Délka dat zprávy handshake
(bity 23..16) (bity 15..8) (bity 7..0)
Bajty
9 .. ( n −1)
Data zprávy handshake
Bajtů
n .. ( n +3)
Typ zprávy Délka dat zprávy handshake
(bity 23..16) (bity 15..8) (bity 7..0)
Byty
( n +4) ..
Data zprávy handshake
Typ zprávy
Toto pole identifikuje typ zprávy handshake.
Typy zpráv
Kód Popis
0 HelloRequest
1 Klient ahoj
2 Server Ahoj
4 Vstupenka NewSession
8 EncryptedExtensions (pouze TLS 1.3)
11 Osvědčení
12 ServerKeyExchange
13 CertificateRequest
14 Server Dobrý den
15 CertificateVerify
16 ClientKeyExchange
20 Hotovo
Délka dat zprávy handshake
Toto je 3bajtové pole udávající délku handshake dat, bez záhlaví.

V jednom záznamu lze kombinovat více zpráv o podání ruky.

Výstražný protokol

Tento záznam by normálně neměl být zasílán během běžného handshaking nebo výměny aplikací. Tuto zprávu však lze odeslat kdykoli během podání ruky a až do ukončení relace. Pokud toto slouží k signalizaci závažné chyby, relace bude uzavřena ihned po odeslání tohoto záznamu, takže tento záznam slouží k udání důvodu tohoto uzavření. Pokud je výstražná úroveň označena jako varování, dálkový ovladač se může rozhodnout relaci ukončit, pokud rozhodne, že relace není dostatečně spolehlivá pro své potřeby (před tím může dálkový ovladač také odeslat vlastní signál).

Formát záznamu TLS pro výstražný protokol
Ofset Byte +0 Byte +1 Byte +2 Byte +3
Byte
0
21 N/A
Byty
1..4
Starší verze Délka
(Hlavní, důležitý) (Méně důležitý) 0 2
Bajty
5..6
Úroveň Popis N/A
Bajty
7 .. ( p −1)
MAC (volitelně)
Bajty
p .. ( q −1)
Polstrování (pouze blokové šifry)
Úroveň
Toto pole určuje úroveň výstrahy. Pokud je úroveň fatální, odesílatel by měl relaci okamžitě ukončit. V opačném případě se příjemce může rozhodnout ukončit samotnou relaci odesláním vlastního smrtelného upozornění a uzavřením samotné relace bezprostředně po jejím odeslání. Použití záznamů výstrah je volitelné, pokud však před uzavřením relace chybí, lze relaci automaticky obnovit (potřesením rukou).
Normální ukončení relace po ukončení přenesené aplikace by mělo být přednostně upozorněno alespoň typem upozornění na upozornění na zavření (s jednoduchou úrovní varování), aby se zabránilo takovému automatickému obnovení nové relace. Signalizace explicitního normálního uzavření zabezpečené relace před účinným uzavřením její transportní vrstvy je užitečná pro prevenci nebo detekci útoků (jako jsou pokusy o zkrácení bezpečně přenášených dat, pokud ze své podstaty nemají předem stanovenou délku nebo dobu trvání, kterou má příjemce zabezpečených dat lze očekávat).
Typy úrovní výstrah
Kód Typ úrovně Stav připojení
1 Varování připojení nebo zabezpečení může být nestabilní.
2 fatální připojení nebo zabezpečení může být narušeno nebo došlo k neopravitelné chybě.
Popis
Toto pole určuje, jaký typ upozornění se odesílá.
Typy popisu výstrah
Kód Popis Typy úrovní Poznámka
0 Zavřít upozornění varování / smrtelné
10 Neočekávaná zpráva fatální
20 Špatný záznam MAC fatální Pravděpodobně špatná implementace SSL nebo užitečné zatížení bylo narušeno např. Pravidlem brány firewall FTP na serveru FTPS.
21 Dešifrování se nezdařilo fatální Pouze TLS, vyhrazeno
22 Přetečení záznamu fatální Pouze TLS
30 Selhání dekomprese fatální
40 Selhání podání ruky fatální
41 Žádný certifikát varování / smrtelné Pouze SSL 3.0, vyhrazeno
42 Špatný certifikát varování / smrtelné
43 Nepodporovaný certifikát varování / smrtelné např. certifikát má povoleno pouze použití ověřování serveru a je prezentován jako klientský certifikát
44 Certifikát zrušen varování / smrtelné
45 Platnost certifikátu vypršela varování / smrtelné Zkontrolujte, zda platnost certifikátu serveru vypršela, a také zkontrolujte, zda nevypršela platnost žádného certifikátu v uvedeném řetězci
46 Certifikát neznámý varování / smrtelné
47 Neplatný parametr fatální
48 Neznámý CA ( certifikační autorita ) fatální Pouze TLS
49 Přístup odepřen fatální Pouze TLS - např. Nebyl předložen žádný klientský certifikát (TLS: prázdná zpráva certifikátu nebo SSLv3: upozornění bez certifikátu), ale server je nakonfigurován tak, aby jeden vyžadoval.
50 Chyba dekódování fatální Pouze TLS
51 Chyba dešifrování varování / smrtelné Pouze TLS
60 Omezení exportu fatální Pouze TLS, vyhrazeno
70 Verze protokolu fatální Pouze TLS
71 Nedostatečné zabezpečení fatální Pouze TLS
80 Interní chyba fatální Pouze TLS
86 Nevhodné nouzové řešení fatální Pouze TLS
90 Uživatel zrušen fatální Pouze TLS
100 Žádné nové vyjednávání Varování Pouze TLS
110 Nepodporované rozšíření Varování Pouze TLS
111 Certifikát nelze získat Varování Pouze TLS
112 Nerozpoznané jméno varování / smrtelné Pouze TLS; klient's Server Name Indicator specifikoval název hostitele, který server nepodporuje
113 Špatná odpověď na stav certifikátu fatální Pouze TLS
114 Špatná hodnota hash certifikátu fatální Pouze TLS
115 Neznámá identita PSK (používá se v TLS-PSK a TLS-SRP ) fatální Pouze TLS

Změňte protokol CipherSpec

Formát záznamu TLS pro protokol ChangeCipherSpec
Ofset Byte +0 Byte +1 Byte +2 Byte +3
Byte
0
20 N/A
Byty
1..4
Starší verze Délka
(Hlavní, důležitý) (Méně důležitý) 0 1
Byte
5
Typ protokolu CCS N/A
Typ protokolu CCS
Aktuálně pouze 1.

Aplikační protokol

Formát záznamu TLS pro aplikační protokol
Ofset Byte +0 Byte +1 Byte +2 Byte +3
Byte
0
23 N/A
Byty
1..4
Starší verze Délka
(Hlavní, důležitý) (Méně důležitý) (bity 15..8) (bity 7..0)
Bajty
5 .. ( m −1)
Data aplikace
Bajtů
m .. ( p −1)
MAC (volitelně)
Bajty
p .. ( q −1)
Polstrování (pouze blokové šifry)
Délka
Délka dat aplikace (kromě záhlaví protokolu a včetně MAC a padding upoutávek)
MAC
32 bytů pro HMAC na bázi SHA -256 , 20 bytů pro HMAC na základě SHA -1 , 16 bytů pro HMAC na bázi MD5 .
Polstrování
Variabilní délka; poslední bajt obsahuje délku odsazení.

Podpora pro virtuální servery založené na jménech

Z hlediska aplikačního protokolu patří TLS k nižší vrstvě, přestože model TCP/IP je příliš hrubý na to, aby to ukázal. To znamená, že handshake TLS se obvykle (kromě případu STARTTLS ) provádí před spuštěním aplikačního protokolu. Ve funkci virtuálního serveru založeného na jménech, kterou poskytuje aplikační vrstva, sdílejí všechny společně hostované virtuální servery stejný certifikát, protože server musí vybrat a odeslat certifikát bezprostředně po zprávě ClientHello. To je v hostitelských prostředích velký problém, protože to znamená buď sdílení stejného certifikátu mezi všemi zákazníky, nebo použití jiné IP adresy pro každého z nich.

X.509 nabízí dvě známá řešení :

  • Pokud všechny virtuální servery patří do stejné domény, lze použít zástupný certifikát . Kromě volného výběru názvu hostitele, který může být problém nebo ne, neexistuje žádná společná dohoda o tom, jak porovnat zástupné certifikáty. V závislosti na použitém aplikačním protokolu nebo softwaru se používají různá pravidla.
  • Přidejte každé jméno virtuálního hostitele do rozšíření subjectAltName. Hlavním problémem je, že certifikát je třeba znovu vydat při každém přidání nového virtuálního serveru.

Chcete -li zadat název serveru, rozšíření RFC  4366 Transport Layer Security (TLS) umožňují klientům zahrnout do rozšířené zprávy ClientHello rozšíření označení názvu serveru (SNI). Toto rozšíření okamžitě napoví serveru, ke kterému jménu se chce klient připojit, aby server mohl vybrat příslušný certifikát, který chce klientům odeslat.

RFC  2817 také dokumentuje způsob implementace virtuálního hostování založeného na jménech upgradováním HTTP na TLS pomocí záhlaví upgradu HTTP/1.1 . Normálně se jedná o bezpečnou implementaci HTTP přes TLS v rámci hlavního schématu URI „http“ (což zamezuje rozdvojení prostoru URI a snižuje počet použitých portů), v současné době to však podporuje jen málo implementací.

Standardy

Primární standardy

Aktuální schválená verze TLS je verze 1.3, která je uvedena v:

  • RFC  8446 : „Protokol Transport Layer Security (TLS), verze 1.3“.

Současný standard nahrazuje tyto dřívější verze, které jsou nyní považovány za zastaralé:

  • RFC  2246 : „Protokol TLS verze 1.0“.
  • RFC  4346 : „Protokol Transport Layer Security (TLS), verze 1.1“.
  • RFC  5246 : „Protokol Transport Layer Security (TLS), verze 1.2“.

Stejně jako nikdy standardizované SSL 2.0 a 3.0, které jsou považovány za zastaralé:

Rozšíření

Ostatní RFC následně rozšířily TLS.

Rozšíření TLS 1.0 zahrnují:

  • RFC  2595 : „Používání TLS s IMAP, POP3 a ACAP“. Určuje rozšíření služeb IMAP, POP3 a ACAP, které umožňují serveru a klientovi používat zabezpečení transportní vrstvy k poskytování soukromé ověřené komunikace přes internet.
  • RFC  2712 : „Přidání sad Kerberos Cipher Suite k zabezpečení TLS (Transport Layer Security)“. 40bitové šifrovací sady definované v této poznámce se objevují pouze za účelem dokumentování skutečnosti, že tyto kódy šifrovacích sad již byly přiřazeny.
  • RFC  2817 : „Upgrade to TLS Within HTTP/1.1“, vysvětluje, jak pomocí mechanismu upgradu v HTTP/1.1 zahájit TLS (Transport Layer Security) přes stávající připojení TCP. To umožňuje nezabezpečenému a zabezpečenému provozu HTTP sdílet stejný dobře známý port (v tomto případě http: na 80 místo https: na 443).
  • RFC  2818 : „HTTP Over TLS“, odlišuje zabezpečený provoz od nezabezpečeného provozu použitím jiného „portu serveru“.
  • RFC  3207 : „Rozšíření služby SMTP pro zabezpečené zabezpečení SMTP přes transportní vrstvu“. Určuje rozšíření služby SMTP, které umožňuje serveru SMTP a klientovi používat zabezpečení transportní vrstvy k poskytování soukromé ověřené komunikace přes internet.
  • RFC  3268 : „AES Ciphersuites for TLS“. Přidá šifrovací sady Advanced Encryption Standard (AES) k dříve existujícím symetrickým šifrám.
  • RFC  3546 : „Rozšíření zabezpečení transportní vrstvy (TLS)“, přidává mechanismus pro vyjednávání o rozšířeních protokolu během inicializace relace a definuje některá rozšíření. Vyrobeno zastaralým RFC  4366 .
  • RFC  3749 : "Transport Layer Security Protocol Compression Methods", určuje rámec pro kompresní metody a DEFLATE kompresní metodu.
  • RFC  3943 : "Komprese protokolu Transport Layer Security (TLS) pomocí Lempel-Ziv-Stac (LZS)".
  • RFC  4132 : „Přidání šifrovacích sad Camellia k zabezpečení transportní vrstvy (TLS)“.
  • RFC  4162 : „Přidání šifrovacích sad SEED k zabezpečení TLS (Transport Layer Security)“.
  • RFC  4217 : „Zabezpečení FTP pomocí TLS “.
  • RFC  4279 : „Ciphersuites pre-Shared Key for Transport Layer Security (TLS)“, přidává tři sady nových šifrovacích sad pro protokol TLS na podporu ověřování na základě předem sdílených klíčů.

Rozšíření TLS 1.1 zahrnují:

  • RFC  4347 : „ Zabezpečení vrstvy přenosu datagramu“ určuje variantu TLS, která funguje přes protokoly datagramu (například UDP).
  • RFC  4366 : „Rozšíření zabezpečení TLS (Transport Layer Security)“ popisuje jak sadu konkrétních rozšíření, tak obecný mechanismus rozšíření.
  • RFC  4492 : „ Šifrovací sady eliptické křivkové kryptografie (ECC) pro zabezpečení transportní vrstvy (TLS)“.
  • RFC  4680 : „TLS Handshake Message for Supplemental Data“.
  • RFC  4681 : „Rozšíření mapování uživatelů TLS“.
  • RFC  4785 : „Ciphersuites s předem sdíleným klíčem (PSK) s šifrováním NULL pro zabezpečení TLS (Transport Layer Security)“.
  • RFC  5054 : „Použití protokolu Secure Remote Password (SRP) pro ověřování TLS“. Definuje šifrovací sady TLS-SRP .
  • RFC  5077 : " Obnovení relace Transport Layer Security (TLS) bez stavu na straně serveru".
  • RFC  5081 : „Používání klíčů OpenPGP pro ověřování TLS (Transport Layer Security)“, zastaralé RFC  6091 .

Rozšíření TLS 1.2 zahrnují:

  • RFC  5288 : „AES Galois Counter Mode (GCM) Cipher Suites for TLS“.
  • RFC  5289 : „TLS Elliptic Curve Cipher Suites with SHA-256/384 and AES Galois Counter Mode (GCM)“.
  • RFC  5746 : „Rozšíření indikace opětovného vyjednávání Transport Layer Security (TLS)“.
  • RFC  5878 : „Autorizační rozšíření zabezpečení transportní vrstvy (TLS)“.
  • RFC  5932 : "Camellia Cipher Suite pro TLS"
  • RFC  6066 : „Rozšíření zabezpečení transportní vrstvy (TLS): definice rozšíření“, obsahuje označení názvu serveru a sešívání OCSP .
  • RFC  6091 : „Používání klíčů OpenPGP pro ověřování TLS (Transport Layer Security)“.
  • RFC  6176 : „Prohibiting Secure Sockets Layer (SSL) Version 2.0“.
  • RFC  6209 : „Přidání šifrovacích sad ARIA k zabezpečení TLS (Transport Layer Security)“.
  • RFC  6347 : "Datagram Transport Layer Security verze 1.2".
  • RFC  6367 : „Přidání šifrovacích sad Camellia k zabezpečení TLS (Transport Layer Security)“.
  • RFC  6460 : „Profil sady B pro zabezpečení transportní vrstvy (TLS)“.
  • RFC  6655 : „Šifrovací sady AES-CCM pro zabezpečení transportní vrstvy (TLS)“.
  • RFC  7027 : „Kryptografie eliptické křivky (ECC) Brainpool pro zabezpečení transportní vrstvy (TLS)“.
  • RFC  7251 : „Šifrovací sady eliptické křivkové kryptografie (ECC) AES-CCM pro TLS“.
  • RFC  7301 : „Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension“.
  • RFC  7366 : „Encrypt-then-MAC for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)“.
  • RFC  7465 : „Zákaz šifrovacích sad RC4“.
  • RFC  7507 : „TLS Fallback Signaling Cipher Suite Value (SCSV) for Prevening Protocol Downgrade Attacks“.
  • RFC  7568 : „Ukončení podpory vrstvy Secure Sockets Layer verze 3.0“.
  • RFC  7627 : „Hash relace zabezpečení transportní vrstvy (TLS) a rozšířené hlavní tajné rozšíření“.
  • RFC  7685 : „ClientHello Padding Extension A Transport Layer Security (TLS)“.

Zapouzdření TLS zahrnují:

Informační RFC

  • RFC  7457 : „Shrnutí známých útoků na zabezpečení transportní vrstvy (TLS) a Datagram TLS (DTLS)“
  • RFC  7525 : „Doporučení pro zabezpečené používání zabezpečení Transport Layer Security (TLS) a Datagram Transport Layer Security (DTLS)“

Viz také

Reference

Další čtení

externí odkazy