Transport Layer Security

Protokol(y) TLS umožňují aplikacím komunikovat po síti způsobem, který zabraňuje odposlouchávání či falšování zpráv. Pomocí kryptografie poskytuje TLS svým koncovým bodům autentizaci a soukromí při komunikaci Internetem. Typicky je autentizován pouze server (tedy jeho totožnost je zaručena), zatímco klient zůstává neautentizován. To znamená, že koncový uživatel (ať člověk či aplikace, jako třeba webový prohlížeč) si může být jist, s kým komunikuje. Další úroveň zabezpečení – při níž oba konce „konverzace“ mají jistotu, s kým komunikují – je označována jako vzájemná autentizace. Vzájemná autentizace vyžaduje nasazení infrastruktury veřejných klíčů (PKI) pro klienty.

TLS zahrnuje tři základní fáze:

1. dohodu účastníků na podporovaných algoritmech
2. výměnu klíčů založenou na šifrování s veřejným klíčem a autentizaci vycházející z certifikátů
3. šifrování provozu symetrickou šifrou

Během první fáze se klient a server dohodnou na používaných kryptografických algoritmech. Současné implementace podporují následující možnosti:

• pro kryptografii s veřejným klíčem: RSA, Diffie-Hellman, DSA
• pro symetrické šifrování: RC2, RC4, IDEA, DES, Triple DES, AES, Camellia
• pro jednosměrné hešování: Message-Digest algorithm (MD2, MD4, MD5), Secure Hash Algorithm (SHA-1, SHA-2, SHA-3)

Protokol TLS je založen na výměně záznamů. Každý záznam může být volitelně komprimován, může k němu být připojen autentizační kód (message authentication code, MAC) a může být zašifrován. Každému záznamu je přiřazen typ obsahu, který určuje protokol vyšší úrovně.

Při zahájení spojení vrstva záznamů obaluje jiný protokol – iniciační protokol (handshake protocol), jehož typ obsahu má hodnotu 22.

Typická inicializace probíhá následovně:

• Klient pošle zprávu ClientHello oznamující nejvyšší verzi TLS, kterou podporuje, náhodné číslo a seznam doporučených šifrovacích sad a kompresních metod.
• Server odpoví zprávou ServerHello obsahující zvolenou verzi protokolu, náhodné číslo, šifrovací a kompresní metodu vybranou z klientem nabídnutého seznamu.
• Server pošle svůj certifikát (Certificate), pokud to zvolená šifra umožňuje. Současné certifikáty jsou založeny na X.509, ale existuje návrh na používání certifikátů vycházejících z OpenPGP.
• Server může pomocí CertificateRequest vyžadovat certifikát od klienta, aby bylo spojení autentizováno vzájemně.
• Server pošle zprávu ServerHelloDone, která signalizuje, že ukončil iniciační dohodu na používaných mechanismech.
• Klient odpoví zprávou ClientKeyExchange, jež může obsahovat PreMasterSecret, veřejný klíč nebo nic (v závislosti na zvolené šifře).
• Klient a server následně z náhodných čísel a PreMasterSecret pomocí pečlivě navržené pseudonáhodné funkce vypočítají „master secret“. Veškeré ostatní klíče jsou odvozeny z něj (a z generovaných náhodných hodnot).
• Klient nyní odešle zprávu ChangeCipherSpec, jíž v podstatě sděluje „veškerá další data ode mne budou šifrována“. Za pozornost stojí, že ChangeCipherSpec je sám o sobě protokolem záznamové vrstvy s typem 20, nikoli 22.
• Na závěr klient pošle šifrovanou zprávu Finished obsahující hash a MAC předchozích iniciačních zpráv.
• Server se pokusí dešifrovat klientovu zprávu Finished a ověřit její hash a MAC. Pokud dešifrování či ověření selže, inicializace je považována za neúspěšnou a spojení by mělo být ukončeno.
• Konečně server pošle zprávy ChangeCipherSpec a svou zašifrovanou Finished a klient provede analogické dešifrování a ověření.
• V tomto okamžiku je inicializace dokončena a je povolen aplikační protokol, jehož typem obsahu je 23. Aplikační zprávy vyměňované mezi klientem a serverem budou zašifrovány.

Dát si dohromady výše popsaný proces spojování TLS/SSL s typickým použitím prohlížeče může být poněkud obtížné. Pomozme si v lepším pochopení typického TLS/SSL spojení tím, co bývá obvykle označováno za šestikrokový SSL proces. SSL naváže stavové spojení dohodnuté výše popsanou iniciační procedurou mezi klientem a serverem. Během inicializace si oba vymění specifikace pro šifrování, které budou při komunikaci používat.

• Inicializace (handshake) začíná, když se klient připojí k serveru používajícímu TLS/SSL a požaduje, aby mu server poslal svou identifikaci.
• Server pošle identifikaci v zabezpečené podobě digitálního certifikátu. Certifikát obsahuje (většinou všechny následující proměnné, závisí to však na použitém standardu X.509) jméno serveru, důvěryhodnou certifikační autoritu (CA) a veřejný klíč serveru.

Prohlížeč může kontaktovat důvěryhodnou CA a ověřit pravost certifikátu, než bude pokračovat. Následně prohlížeč nabídne seznam šifrovacích algoritmů a hashovacích funkcí.

• Z tohoto seznamu server vybere nejsilnější šifrování, které také podporuje a oznámí toto rozhodnutí klientovi.

K vygenerování klíčů seance použitých pro zabezpečení spojení použije prohlížeč veřejný klíč serveru z certifikátu. Zašifruje jím náhodná data a zašle je serveru.

• Tato data klient dokáže zašifrovat, ale pouze server je umí rozšifrovat (pomocí svého soukromého klíče): tímto způsobem zůstane budoucí klíč seance skryt před případným odposlouchávajícím, znají jej pouze server a klient.
• Server odpoví dalšími náhodnými daty (která není třeba šifrovat) a následně:
• Obě strany nějakým dohodnutým způsobem zkombinují náhodná data od klienta a od serveru. Na takto zkombinovaná náhodná data použijí vybranou hashovací funkci, a tím vytvoří klíč seance, který zná jen server a klient.

Tím končí handshake a začíná zabezpečené spojení, které je šifrováno a dešifrováno klíči seance po zbytek svého trvání.

Pokud je libovolný z těchto kroků neúspěšný, selže TLS/SSL handshake a nedojde k vytvoření spojení.

Protocol

Tato položka identifikuje typ protokolu vrstvy záznamů obsažený v tomto záznamu.

Dostupné typy protokolů jsou: 
20 ChangeCipherSpec
21 Alert
22 Handshake
23 Application

Version

Identifikuje hlavní a dílčí verzi SSL pro obsaženou zprávu. Pro zprávu ClientHello se nemusí jednat o nejvyšší verzi podporovanou klientem.

Verze jsou:
3 | 0 SSLv3
3 | 1 TLS 1.0
3 | 2 TLS 1.1
3 | 3 TLS 1.2
3 | 4 TLS 1.3

Length

Délka zpráv protokolu. Nesmí překročit 2¹⁴ bajtů.

Zprávy protokolu

Jedna nebo více zpráv identifikovaných položkou Protocol. Tato položka může být zašifrována v závislosti na stavu spojení.

MAC

Kód ověřující autentičnost zprávy vypočítaný ze Zpráv protokolu doplněné o klíče. Položka může být zašifrována nebo může chybět, opět v závislosti na stavu spojení.

Level

Položka identifikující úroveň výstrahy.

Úrovně jsou: 
1 Varování – spojení nebo bezpečnost mohou být nestabilní
2 Fatální – spojení nebo bezpečnost mohou být kompromitovány nebo došlo k nenapravitelné chybě

Description

Identifikuje typ zasílané výstrahy.

Dostupné popisy jsou: 
0 Close notify
10 Unexpected message (fatal)
20 Bad record MAC (fatal)
21 Decryption failed (fatal, TLS only)
22 Record overflow (fatal, TLS only)
30 Decompression failure (fatal)
40 Handshake failure (fatal)
41 No certificate (SSL v3 only)
42 Bad certificate 
43 Unsupported certificate 
44 Certificate revoked
45 Certificate expired
46 Certificate unknown
47 Illegal parameter (fatal)
48 Unknown CA (fatal, TLS only)
49 Access denied (fatal, TLS only)
50 Decode error (fatal, TLS only)
51 Decrypt error (TLS only)
60 Export restriction (fatal, TLS only)
70 Protocol version (fatal, TLS only)
71 Insufficient security (fatal, TLS only)
80 Internal error (fatal, TLS only)
90 User cancelled (fatal, TLS only)
100 No renegotiation (warning, TLS only)

Message type

Identifikuje typ zprávy.

Dostupné typy jsou: 
 0 HelloRequest
 1 ClientHello 
 2 ServerHello
11 Certificate
12 ServerKeyExchange
13 CertificateRequest
14 ServerHelloDone
15 CertificateVerify
16 ClientKeyExchange
20 Finished

Message length

Jedná se o tříbajtovou položku obsahující délku handshake dat, hlavička se nepočítá.

TLS zahrnuje řadu bezpečnostních opatření:

• Klient používá veřejný klíč certifikační autority (CA) k ověření jejího digitálního podpisu v serverovém certifikátu. Lze-li digitální podpis CA ověřit, klient přijme serverový certifikát jako platný certifikát vydaný důvěryhodnou CA.
• Klient ověřuje, zda je vydávající certifikační autorita na seznamu důvěryhodných CA.
• Klient kontroluje dobu životnosti serverového certifikátu. Autentizační proces se zastaví, pokud doba jeho platnosti vypršela.
• K ochraně před útoky typu Man-in-the-Middle porovnává klient aktuální DNS jméno serveru se jménem z certifikátu.
• Ochrana před několika známými útoky (včetně Man-in-the-Middle), jako je snaha o použití nižší (méně bezpečné) verze protokolu nebo slabšího šifrovacího algoritmu.
• Opatření všech aplikačních záznamů pořadovými čísly a používání těchto čísel v MAC.
• Používání ověřovacího kódu zprávy rozšířeného o klíč, takže jen vlastník klíče dokáže MAC ověřit. Definováno v RFC 2104. Jen v TLS.
• Zpráva ukončující inicializaci (Finished) obsahuje hash všech zpráv vyměněných v rámci inicializace oběma stranami.
• Pseudonáhodná funkce rozděluje vstupní data na poloviny a zpracovává každou z nich jiným hashovacím algoritmem (MD5 a SHA), pak je XORuje dohromady. To poskytuje ochranu, pokud by byla nalezena slabina jednoho z algoritmů. Jen v TLS.
• SSL v3 je proti SSL v2 vylepšeno přidáním šifer založených na SHA-1 a podporou autentizace certifikáty. Další vylepšení SSL v3 zahrnují lepší inicializační protokol a vyšší odolnost proti útokům typu man-in-the-middle. V roce 2014 ale většina certifikátů internetových stránek používá (místo SHA-2 či SHA-3) zastaralé a nedostačující SHA-1,^[2] které v blízké době^[kdy?] nebude podporováno (např. Microsoft je nebude v roce 2017 akceptovat).^{[potřebuje aktualizovat]}

TLS běží ve vrstvě pod aplikačními protokoly, jako jsou HTTP, FTP, SMTP, NNTP či XMPP, a nad spolehlivým transportním protokolem, např. TCP. Dokáže přidat zabezpečení libovolnému protokolu používajícímu spolehlivá spojení (např. pomocí TCP), nicméně nejčastěji se používá pro HTTP k vytvoření HTTPS. Jeho prostřednictvím jsou zabezpečeny webové aplikace, jako je elektronická komerce či správa aktiv. Míra využití TLS v SMTP také roste (je definována v RFC 3207). Tyto aplikace využívají k ověření identity koncových bodů certifikáty s veřejnými klíči.

Počet serverů a klientů nativně podporujících TLS stále roste, nicméně v řadě z nich podpora stále chybí. Jako alternativu mohou uživatelé použít samostatné TLS produkty, jako je Stunnel. Obalové mechanismy jako Stunnel stavějí na schopnosti získat TLS spojení přímo jednoduchým připojením na samostatný port vyhrazený pro tento účel. Například implicitní TCP port pro HTTPS je 443, aby se odlišil od portu 80 pro obyčejné HTTP. Nicméně v roce 1997 Internet Engineering Task Force doporučilo, aby aplikační protokoly vždy zahajovaly činnost bez zabezpečení a místo samostatných portů nabídly způsob pro přechod na TLS. S tím se jednoduché balení aplikačních dat do TLS, jaké používá Stunnel, nedokáže vypořádat.

TLS lze také použít pro tunelování všech síťových protokolů a vytvoření VPN, jak to dělá OpenVPN. Řada výrobců v současnosti spojuje šifrovací a autentizační mechanismy TLS s autorizací. Koncem 90. let bylo vynaloženo značné úsilí na vývoj klientských technologií mimo prohlížeč, které by podporovaly aplikace typu klient/server. V porovnání s tradičními VPN technologiemi na bázi IPsec má TLS některé principiální výhody při procházení firewally a NAT, které usnadňují správu při větším počtu vzdálených uživatelů.

TLS se také ve stále větší míře používá jako standardní metoda ochrany SIP signalizace v aplikacích. TLS dokáže poskytnout autentizaci a šifrování pro SIP signalizaci spojenou s VoIP a dalšími aplikacemi.

• Server Name Indication

•   Obrázky, zvuky či videa k tématu Transport Layer Security na Wikimedia Commons