SSL ( anglicky Secure Sockets Layer - úroveň zabezpečených soketů ) je kryptografický protokol , který předpokládá bezpečnější připojení. Využívá asymetrickou kryptografii k autentizaci výměnných klíčů, symetrické šifrování pro zachování důvěrnosti, autentizační kódy zpráv pro integritu zpráv. Protokol byl široce používán pro instant messaging a voice over IP ( Voice over IP - VoIP ) v aplikacích, jako je e-mail , internetový fax atd. V roce 2014 americká vláda oznámila zranitelnost v aktuální verzi protokolu [1] . SSL by mělo být ukončeno ve prospěch TLS (viz CVE-2014-3566).
SSL byl původně vyvinut společností Netscape Communications pro přidání protokolu HTTPS do webového prohlížeče Netscape Navigator . Následně byl na základě protokolu SSL 3.0 vyvinut a přijat standard RFC , který dostal název TLS .
Protokol SSL zajišťuje bezpečnou komunikaci prostřednictvím následujících dvou prvků:
SSL používá asymetrickou kryptografii k ověření výměnných klíčů, symetrickou šifru k zachování důvěrnosti a ověřovací kódy zpráv pro integritu zpráv.
Protokol SSL poskytuje „zabezpečený kanál“, který má tři hlavní vlastnosti:
Výhodou SSL je, že je nezávislý na aplikačním protokolu. Aplikační protokoly ( HTTP , FTP , TELNET atd.) mohou pracovat nad protokolem SSL zcela transparentním způsobem, to znamená, že SSL může vyjednat šifrovací algoritmus a klíč relace a ověřit server předtím, než aplikace přijme nebo odešle první bajt zprávy.
Protokol SSL byl původně vyvinut společností Netscape Communications . Verze 1.0 nebyla nikdy vydána veřejnosti. Verze 2.0 byla vydána v únoru 1995, ale obsahovala mnoho bezpečnostních chyb, které vedly k vývoji SSL verze 3.0 [2] . SSL verze 3.0, vydaná v roce 1996, byla základem pro vytvoření TLS 1.0, standardu protokolu IETF (Internet Engineering Task Force ), který byl poprvé definován v RFC 2246 v lednu 1999. Společnosti Visa , Master Card , American Express a mnoho dalších organizací mají licenci k používání protokolu SSL pro komerční účely na internetu. Proto je SSL rozšiřitelné v souladu s projektem na podporu dopředné a zpětné kompatibility a vyjednávání mezi připojeními v síti peer-to-peer. Od března 2011 podle RFC 6176 klienti TLS nesmějí při požadavku na připojení k serveru používat protokol SSL 2.0 a servery musí takové požadavky odmítat.
TLS 1.0 byl poprvé definován v RFC 2246 v lednu 1999 jako aktualizace SSL 3.0. Jak je uvedeno v RFC, "rozdíly mezi tímto protokolem a SSL 3.0 nejsou kritické, ale jsou významné pro výskyt nekompatibility mezi TLS 1.0 a SSL 3.0." TLS 1.0 obsahuje prostředky, kterými by implementace připojení TLS k SSL 3.0 oslabila zabezpečení.
TLS 1.1 byl představen v RFC 4346 v dubnu 2006 [3] . Jednalo se o aktualizaci TLS verze 1.0. Mezi významné změny v této verzi patří:
TLS 1.2 byl oznámen v RFC 5246 v srpnu 2008. Je založen na dříve navrhované verzi TLS 1.1.
TLS 1.3 byl uznán jako standard v RFC 8446 v srpnu 2018.
SSL využívá vícevrstvé prostředí k zajištění bezpečnosti výměny informací. Důvěrnost komunikace je přítomna díky skutečnosti, že zabezpečené připojení je otevřené pouze pro cílené uživatele.
Protokol SSL se nachází mezi dvěma protokoly: protokolem, který klientský program používá (HTTP, FTP, LDAP, TELNET atd.) a přenosovým protokolem TCP/IP. SSL chrání data tím, že funguje jako filtr pro obě strany a předává je transportní vrstvě [4] [5] .
Činnost protokolu lze rozdělit do dvou úrovní:
První vrstva se skládá ze tří podprotokolů:
Protokol připojení handshake se používá k vyjednávání dat relace mezi klientem a serverem. Údaje o relacích zahrnují:
Spojovací protokol handshake vytváří řetězec výměny dat, který zase zahajuje autentizaci stran a schvaluje šifrování, hashování a kompresi. Další fází je autentizace účastníků, která se rovněž provádí protokolem potvrzení připojení.
Protokol změny parametrů šifry se používá ke změně dat klíče (keyingmaterial) – informací, které se používají k vytvoření šifrovacích klíčů. Protokol se skládá pouze z jedné zprávy, ve které server říká, že odesílatel chce změnit sadu klíčů.
Varovný protokol obsahuje zprávu, která stranám signalizuje změnu stavu nebo možnou chybu. Upozornění se obvykle odešle, když je spojení uzavřeno a je přijata neplatná zpráva, zprávu nelze dešifrovat nebo uživatel zruší operaci.
Protokol SSL používá certifikáty k ověření, že veřejný klíč patří jeho skutečnému vlastníkovi. Způsoby, jak získat certifikát SSL:
Self-signed certifikát – certifikát vytvořený samotným uživatelem – v tomto případě je vydavatel certifikátu stejný jako vlastník certifikátu. "Prázdný" certifikát je certifikát, který obsahuje fiktivní informace sloužící jako dočasný pro nastavení SSL a ověření jeho funkčnosti v daném prostředí.
Mezi certifikáty SSL jsou certifikáty ověřené doménou a certifikáty rozšířeného ověření . Ten spojuje doménové jméno se skutečnou osobou nebo entitou.
Existují 4 hlavní algoritmy generování klíčů: RSA , Fixed Diffie-Hellman, Ephemeral Diffie-Hellman, Anonymous Diffie-Hellman
rsaKdyž se soukromý klíč RSA „ztratí“, kryptoanalytik, který jej obdrží, dostane příležitost dešifrovat všechny zaznamenané minulé zprávy a budoucí zprávy. Implementace výměny klíčů v RSA je jednosměrná: všechny potřebné informace k vytvoření symetrického klíče, který je vytvořen během fáze handshake, jsou odeslány na server a zašifrovány veřejným klíčem serveru. Zveřejněním soukromého klíče je možné zjistit symetrický klíč této relace.
Diffie-HellmanMechanismus Fixed Diffie-Hellman používá trvalý veřejný klíč, který je registrován v certifikátu serveru. To také znamená, že při každém novém připojení klient poskytuje svou část klíče. Po výměně klíče se vytvoří nový symetrický klíč pro výměnu informací pro aktuální relaci. Zveřejněním soukromého klíče serveru může kryptoanalytik dešifrovat dříve zaznamenané zprávy i všechny budoucí zprávy. To je umožněno samotným mechanismem. Protože kryptoanalytik zná soukromý klíč serveru, bude schopen zjistit symetrický klíč každé relace a nepomůže ani fakt, že mechanismus generování klíče je obousměrný.
Mechanismus Anonymous Diffie-Hellman neposkytuje žádné záruky soukromí, protože data jsou přenášena nešifrovaně.
Jedinou možností, která zaručuje bezpečnost minulých i budoucích zpráv, je Ephemeral Diffie-Hellman . Rozdíl oproti dříve diskutovaným metodám spočívá v tom, že s každým novým připojením je serverem a klientem vygenerován jednorázový klíč. I když tedy kryptoanalytik získá aktuální soukromý klíč, bude moci dešifrovat pouze aktuální relaci, ale ne předchozí ani budoucí relace.
Existují dva hlavní způsoby šifrování dat: symetrické šifrování (sdílený tajný klíč) a asymetrické šifrování (pár veřejného/soukromého klíče).
SSL využívá asymetrickou i symetrickou kryptografii.
Podstatou asymetrického šifrování je použití dvojice klíčů. Jeden z klíčů se nazývá veřejný (zpravidla je zveřejněn v samotném certifikátu vlastníka) a druhý klíč se nazývá soukromý - je uchováván v tajnosti. Oba klíče se používají ve dvojicích: veřejný klíč se používá k šifrování dat a soukromý klíč k jejich dešifrování. Tento vztah vám umožňuje dělat dvě důležité věci.
RSA je jedním z nejpoužívanějších asymetrických šifrovacích algoritmů.
U symetrického šifrování se k šifrování i dešifrování dat používá stejný klíč. Pokud si strany chtějí vyměňovat šifrované zprávy bezpečným způsobem, musí mít obě strany stejné symetrické klíče. Tento typ šifrování se používá pro velké množství dat (protože symetrické šifrování je rychlejší). Běžně používané algoritmy jsou DES , 3-DES , RC2 , RC4 a AES .
Protokol SSL využívá šifrování veřejným klíčem pro vzájemnou autentizaci klienta a serveru (pomocí technologie digitálního podpisu) a také pro generování klíče relace, který je zase využíván rychlejšími symetrickými kryptografickými algoritmy k šifrování velkého množství dat. .
Hodnota hash je identifikátor zprávy, její velikost je menší než velikost původní zprávy. Nejznámějšími hashovacími algoritmy jsou MD5 (Message Digest 5), který vytváří 128bitovou hodnotu hash, SHA-1 (Secure Hash Algorithm), který vytváří 160bitovou hodnotu hash, SHA-2 a SHA-3 . Výsledkem hashovacího algoritmu je hodnota, která se používá ke kontrole integrity přenosu dat.
Protokol na úrovni záznamové vrstvy přijímá zašifrovaná data z klientského programu a přenáší je do transportní vrstvy. Záznamový protokol vezme data, rozdělí je do bloků a provede šifrování (dešifrování) dat. Zároveň jsou aktivně využívány informace, které byly dohodnuty při potvrzování údajů.
Protokol SSL umožňuje šifrování symetrickým klíčem pomocí blokových šifer nebo proudových šifer . V praxi se běžně používají blokové šifry. Princip fungování blokové šifry je mapovat blok otevřeného textu do stejného bloku šifrovaného textu. Tato šifra může být reprezentována jako tabulka obsahující 2 128 řádků, přičemž každý řádek obsahuje blok otevřeného textu M a jeho odpovídající blok šifrovaného textu C. Pro každý klíč existuje podobná tabulka.
Šifrování může být reprezentováno jako funkce
C = E ( Klíč , M ), kde M jsou původní data, Klíč je šifrovací klíč, C jsou šifrovaná data.
Bloky jsou zpravidla malé (obvykle 16 bajtů), takže vyvstává otázka: jak zašifrovat dlouhou zprávu?
První režim pro takové šifrování se nazývá ECB (Electronic Codebook) nebo jednoduchý režim nahrazení. Jeho podstatou je, že původní zprávu rozdělíme na bloky (pro stejných 16 bajtů) a zašifrujeme každý blok zvlášť. Tento režim se však používá jen zřídka kvůli problému se zachováním statistických vlastností zdrojového textu: 2 stejné bloky otevřeného textu se po zašifrování změní na dva stejné bloky šifrovaného textu.
K vyřešení tohoto problému byl vyvinut druhý režim – CBC (Cipher-block chaining). V tomto případě je každý nový blok šifrovaného textu XORed s předchozím výsledkem šifrování. První blok je XORed s nějakým inicializačním vektorem (Initialization Vector, IV). Všechna výše uvedená teorie je však vyvinuta pro jeden velký objekt, zatímco SSL, protože je kryptografickým protokolem, musí šifrovat řadu paketů. V takové situaci existují dva způsoby, jak použít CBC:
Při navrhování aplikací je SSL implementováno „pod“ jakýmkoli jiným protokolem aplikační vrstvy, jako je HTTP , FTP , SMTP , NNTP a XMPP , čímž poskytuje „transparentnost“ jeho použití. Historicky se SSL používalo především se spolehlivými transportními protokoly, jako je Transmission Control Protocol (TCP). Byl však také implementován s protokoly přenosu datagramů, jako je User Datagram Protocol (UDP) a Datagram Control Protocol (DCCP), jejichž použití bylo standardizováno, což dalo vzniknout termínu Datagram Transport Layer Security (DTLS).
Časté používání protokolu SSL vedlo k vytvoření protokolu HTTPS (Hypertext Transfer Protocol Secure), který podporuje šifrování. Data přenášená přes protokol HTTPS jsou „zabalena“ do kryptografického protokolu SSL nebo TLS , čímž je zajištěna ochrana těchto dat. Tento způsob ochrany je široce používán ve světě webu pro aplikace, kde je důležitá bezpečnost připojení, jako jsou platební systémy. Na rozdíl od HTTP má HTTPS výchozí port TCP 443.
Webová podpora protokolu [6]| Verze protokolu | Bezpečnost | Podpora webových stránek |
|---|---|---|
| SSL 2.0 | Ne | 4,9 % |
| SSL 3.0 | Ne | 16,6 % |
| TLS 1.0 | Možná | 94,7 % |
| TLS 1.1 | Ano | 82,6 % |
| TLS 1.2 | 85,5 % |
Na začátku roku 2017 jsou všechny hlavní webové prohlížeče, které podporují SSL/TLS:
Prohlížeče, které podporují SSL/TLS| Prohlížeč | Platformy | TLS 1.0 | TLS 1.1 | TLS 1.2 | TLS 1.3 |
|---|---|---|---|---|---|
| Chrome 1-21 | Android, iOS, Linux, Mac OS X, Windows (XP, Vista, 7, 8) | Ano | Ne | Ne | Ne |
| Chrome 29-53 | Android, iOS, Linux, Mac OS X, Windows (XP, Vista, 7, 8,10) | ano [7] | ano [7] | ano [8] | Ne |
| Chrome 58+ | Android, iOS, Linux, Mac OS X, Windows (XP, Vista, 7, 8,10) | Ano | Ano | Ano | Ano |
| Firefox 1-27 | Linux, Mac OS X, Windows (XP, Vista, 7, 8) | ano [9] | ne [10] | Ne [11] | Ne |
| Firefox 27-53 | Linux, Mac OS X, Windows (XP, Vista, 7, 8) | Ano | Ano | Ano | Ne |
| Firefox 54+ | Linux, Mac OS X, Windows (XP, Vista, 7, 8) | Ano | Ano | Ano | Ano |
| IE6 | Windows (XP) | Ano | Ne | Ne | Ne |
| IE 7–8 _ | Windows (XP, Vista) | Ano | Ne | Ne | Ne |
| IE 8–9 _ | Windows 7 | Ano | Ano | Ano | Ne |
| IE9 | Windows Vista | Ano | Ne | Ne | Ne |
| IE 10+ | Windows (7, 8) | Ano | Ano | Ano | Ne |
| Hrana 12-15 | Windows 10 | Ano | Ano | Ano | Ne |
| Opera 5-7 | Linux, Mac OS X, Windows | ano [12] | Ne | Ne | Ne |
| Opera 8-9 | Linux, Mac OS X, Windows | Ano | ano [13] | Ne | Ne |
| Opera 10+ | Linux, Mac OS X, Windows | Ano | Ano | Ano | Ne |
| Opera 44+ | Linux, Mac OS X, Windows | Ano | Ano | Ano | Ano |
| Safari 4 | Mac OS X, Windows (XP, Vista, 7), iOS 4.0 | Ano | Ne | Ne | Ne |
| Safari 5 | Mac OS X, Windows (XP, Vista, 7) | Ano | Ne | Ne | Ne |
| Safari 7-10 | iOS 5.0- | Ano | Ano | Ano | Ne |
Specifikace:
Zpočátku byly virtuální privátní sítě ( VPN ) založené na SSL vyvinuty jako doplňková a alternativní technologie vzdáleného přístupu založená na IPsec VPN. Faktory, jako je dostatečná spolehlivost a nízké náklady, však učinily tuto technologii atraktivní pro organizace VPN. SSL je také široce používán v e-mailu.
Nejběžnější implementací SSL je open source kryptografický balíček OpenSSL , založený na SSLeay napsaném Ericem Youngem. Nejnovější verze OpenSSL podporuje SSLv3. Balíček je určen k vytváření a správě různých druhů certifikátů . Obsahuje také knihovnu pro podporu SSL různými programy. Knihovnu využívá např. SSL modul v běžném Apache HTTP serveru .
Všechna data v SSL jsou odesílána ve formě záznamů (záznamů) - objektů, které se skládají z hlavičky a určitého množství dat. Každá hlavička záznamu obsahuje 2 nebo 3 bajty kódu délky. Pokud je nejvýznamnější bit v prvním bajtu kódu délky záznamu 1, pak záznam nemá žádnou výplň a celková délka záhlaví je 2 bajty, jinak záznam obsahuje výplň a celková délka záhlaví je 3 bajty. V případě dlouhé hlavičky (3 bajty) má druhý nejvýznamnější bit prvního bajtu zvláštní význam. Pokud je roven 0 - záznam je informační, pokud je roven 1 - záznam je bezpečnostní únik. Kód délky záznamu nezahrnuje počet bajtů záhlaví. U 2bajtového záhlaví se jeho délka vypočítá takto:
DÉLKA ZÁZNAMU = ((bajt[0] & 0x7F) << 8) | byte[1];
Zde byte[0] je první přijatý bajt a byte[1] je druhý přijatý bajt.
Pro 3bajtové záhlaví se délka záznamu vypočítá takto:
DÉLKA ZÁZNAMU = ((bajt[0] & 0x3F) <<8) | byte[1];
IS-ESCAPE = (byte[0] & 0x40) !=0;
PADDING = byte[2];
Hodnota PADDING udává počet bajtů přidaných odesílatelem k původnímu záznamu. Vyplňovací data se používají k tomu, aby délka záznamu byla násobkem velikosti bloku šifry. Odesílatel za daná data přidá PADDING a poté vše zašifruje, protože délka tohoto pole je násobkem velikosti bloku použité šifry. Protože je známo množství přenášených dat, může být hlavička zprávy vytvořena s ohledem na množství PADDING . Příjemce zprávy dešifruje celé datové pole a získá původní informace, poté vypočítá skutečnou hodnotu RECORD-LENGTH , zatímco PADDING je z pole „data“ odstraněn.
Datová část záznamu SSL se skládá ze 3 komponent:
MAC-DATA - autentizační kód zprávy
MAC-SIZE - funkce algoritmu pro výpočet hash součtu
ACTUAL-DATA - aktuálně přenášená data nebo datové pole zprávy
PADDING-DATA - PADDING data (s blokovým šifrováním)
MAC-DATA = HASH [ SECRET , AKTUÁLNÍ-DATA , PADDING-DATA , SEQUENCE-NUMBER ]
Zde se nejprve do hašovací funkce předá SECRET , následuje ACTUAL-DATA a PADDING-DATA , následuje SEQUENCE-NUMBER , pořadové číslo.
Hodnota SECRET závisí na tom, kdo zprávu posílá. Pokud klient ano, pak SECRET se rovná CLIENT-WRITE-KEY . Pokud klient zprávu obdrží, SECRET se rovná KLIENT-READ-KEY .
Pořadové číslo je 32bitový kód, který je předán hashovací funkci jako 4 bajty pomocí síťového pořadí od vysoké po nízkou. Pořadové číslo je čítač serveru nebo klienta. Pro každý směr přenosu se používá dvojice čítačů - pro odesílatele a pro příjemce; při každém odeslání zprávy se počítadlo zvýší o 1.
Příjemce zprávy použije očekávanou hodnotu pořadového čísla k odeslání MAC (typ hash je určen parametrem CIPHER-CHOICE ). Vypočítaná hodnota MAC-DATA se musí shodovat s přenášenou hodnotou. Pokud se porovnání nezdaří, je zpráva považována za poškozenou a výsledkem je chyba, která způsobí ukončení připojení.
Konečná kontrola shody se provádí při použití blokové šifry. Množství dat ve zprávě ( RECORD-LENGTH ) musí být násobkem velikosti bloku šifry. Pokud tato podmínka není splněna, je zpráva považována za poškozenou, což má za následek odpojení.
U 2bajtové hlavičky je maximální délka zprávy 32767 bajtů, u 3bajtové hlavičky je to 16383 bajtů. Zprávy konverzačního protokolu SSL musí odpovídat jednomu záznamu protokolu SSL a zprávy aplikačního protokolu mohou zabírat více záznamů SSL.
Protokol konverzace SSL obsahuje 2 hlavní fáze.
Fáze 1První fáze se používá k vytvoření důvěrného komunikačního kanálu.
Tato fáze inicializuje připojení, když si oba partneři vyměňují „ahoj“ zprávy. Klient odešle zprávu KLIENT-HELLO . Server tuto zprávu přijme, zpracuje a odešle zpět zprávu SERVER-HELLO .
V tomto okamžiku mají server i klient dostatek informací, aby věděli, zda je potřeba nový hlavní klíč. Pokud klíč není potřeba, server a klient přejdou do fáze 2.
Když je potřeba vytvořit nový hlavní klíč , zpráva serveru SERVER-HELLO již obsahuje dostatek dat, aby klient vygeneroval hlavní klíč . Tato data zahrnují podepsaný certifikát serveru, seznam základních šifer a ID připojení (náhodné číslo generované serverem, které se používá během relace). Poté, co klient vygeneruje hlavní klíč , odešle serveru zprávu KLIENT-MASTER-KEY nebo chybovou zprávu, když se klient a server nemohou dohodnout na základní šifře.
Po určení hlavního klíče server odešle zprávu SERVER-VERIFY klientovi , která server ověří.
Fáze 2 se nazývá fáze ověřování. Protože server je již autentizován v první fázi, klient je autentizován ve druhé fázi. Server odešle klientovi požadavek, a pokud má klient potřebné informace, odešle kladnou odpověď, pokud ne, chybovou zprávu. Když jeden peer ověří druhého peer, odešle hotovou zprávu . V případě klienta obsahuje zpráva CLIENT-FINISHED zašifrovanou formu CONNECTION-ID , kterou musí server ověřit. Pokud bylo ověření neúspěšné, server odešle zprávu ERROR .
Když jeden z protějšků odeslal hotovou zprávu , musí přijímat zprávy, dokud neobdrží hotovou zprávu od druhého účastníka, a teprve když oba účastníci odeslali a přijali hotové zprávy , protokol konverzace SSL se ukončí. Od tohoto okamžiku začne fungovat aplikační protokol.
Níže je několik možností pro výměnu zpráv v rámci konverzačního protokolu SSL. Klient je C , server je S. "{smth}key" znamená, že "co" je zašifrováno klíčem.
Při absenci ID relace| klient-ahoj | C®S: | výzva, specifikace_šifry |
| server-ahoj | S® C: | connection-id,server_certificate,cipher_specs |
| klient-master-key | C®S: | {master_key}server_public_key |
| klient-dokončení | C®S: | {connection-id}client_write_key |
| server-ověřit | S® C: | {challenge}server_write_key |
| server-dokončení | S® C: | {new_session_id}server_write_key |
| klient-ahoj | C®S: | výzva, session_id, cipher_specs |
| server-ahoj | S® C: | connection-id, session_id_hit |
| klient-dokončení | C®S: | {connection-id}client_write_key |
| server-ověřit | S® C: | {challenge}server_write_key |
| server-dokončení | S® C: | {session_id}server_write_key |
| klient-ahoj | C®S: | výzva, session_id, cipher_specs |
| server-ahoj | S® C: | connection-id, session_id_hit |
| klient-dokončení | C®S: | {connection-id}client_write_key |
| server-ověřit | S® C: | {challenge}server_write_key |
| Žádost-certifikát | S® C: | {auth_type ,challenge'}klíč_zápisu_serveru |
| klientský certifikát | C®S: | {cert_type,client_cert,response_data}client_write_key |
| server-dokončení | S® C: | {new_session_id}server_write_key |
SSL podporuje 3 typy ověřování:
Pokud je server ověřen, musí jeho certifikační zpráva poskytovat správný certifikační řetězec vedoucí k přijatelnému CA. Jednoduše řečeno, ověřený server musí klientovi poskytnout platný certifikát. Každá strana je odpovědná za ověření, že certifikát druhé strany ještě nevypršel nebo nebyl zrušen. Kdykoli se server ověřuje, kanál je odolný (zabezpečený) vůči pokusu o zachycení dat mezi webovým serverem a prohlížečem, ale zcela anonymní relace je ze své podstaty vůči takovému útoku zranitelná. Anonymní server nemůže ověřit klienta. Hlavním účelem procesu výměny klíčů je vytvořit tajný klíč klienta (pre_master_secret), který zná pouze klient a server. Tajný klíč (pre_master_secret) se používá k vytvoření sdíleného tajemství (master_secret). Sdílený tajný klíč je potřeba k vytvoření zprávy pro ověření certifikátu, šifrovacích klíčů, tajného klíče MAC (kód pro ověření zprávy) a hotové zprávy. Odesláním hotové zprávy strany dávají najevo, že znají správné tajemství (pre_master_secret).
Zcela anonymní relaci lze vytvořit pomocí algoritmu RSA nebo Diffie-Hellman pro generování výměnných klíčů. V případě použití RSA klient zašifruje tajný klíč (pre_master_secret) pomocí veřejného klíče necertifikovaného serveru. Klient se dozví veřejný klíč ze zprávy výměny klíčů ze serveru. Výsledek je odeslán ve zprávě pro výměnu klíčů od klienta. Protože interceptor nezná soukromý klíč serveru, nebude pro něj možné dešifrovat tajemství (pre_master_secret). Při použití algoritmu Diffie-Hellman jsou veřejné parametry serveru obsaženy ve zprávě o výměně klíčů ze serveru a jsou odeslány klientovi ve zprávě o výměně klíčů. Interceptor, který nezná soukromé hodnoty, nebude schopen najít tajemství (pre_master_secret).
V tomto případě lze zkombinovat výměnu klíčů a autentizaci serveru. Veřejný klíč může být také obsažen v certifikátu serveru nebo může být použit dočasný RSA klíč , který je odeslán ve zprávě o výměně klíčů ze serveru. Při použití dočasného klíče RSA jsou výměnné zprávy podepsány certifikátem RSA nebo DSS serveru (???). Podpis obsahuje aktuální hodnotu zprávy Client_Hello.random, takže staré podpisy a staré dočasné klíče nelze opakovat. Server může použít dočasný klíč RSA pouze jednou k vytvoření relace. Po ověření certifikátu serveru klient zašifruje tajný klíč (pre_master_secret) pomocí veřejného klíče serveru. Po úspěšném dekódování tajného klíče (pre_master_secret) se vygeneruje zpráva "dokončeno", čímž se serveru prokáže, že zná soukromý klíč odpovídající certifikátu serveru.
Když se pro výměnu klíčů používá RSA, k ověření klienta se použije zpráva o ověření klientského certifikátu. Klient podepíše hodnotu vypočítanou z master_secret a všech předchozích zpráv protokolu handshake. Tyto zprávy handshake obsahují certifikát serveru, který odpovídá podpisu serveru se zprávou Server_Hello.random, která odpovídá podpisu aktuální zprávy handshake (???).
V tomto případě může server také podporovat parametricky specifický algoritmus Diffie-Hellman nebo může používat zprávy o výměně klíčů ze serveru k odeslání sady dočasných parametrů podepsaných certifikáty DSS nebo RSA. Dočasné parametry jsou před podpisem hašovány zprávou hello.random, aby se zabránilo útočníkovi opakovat staré parametry. V obou případech může klient zkontrolovat certifikát nebo podpis, aby se ujistil, že parametry patří serveru.
Pokud má klient certifikát, který obsahuje parametry algoritmu Diffie-Hellman , pak certifikát obsahuje také informace potřebné k dokončení výměny klíčů. V tomto případě budou muset klient a server generovat stejné výsledky Diffie-Hellman (pre_master_secret) pokaždé, když navazují spojení. Aby tajemství (pre_master_secret) nebylo uloženo v paměti počítače déle, než je nutné, mělo by být tajemství co nejrychleji převedeno na sdílené tajemství (master_secret). Aby výměna klíčů fungovala, musí být nastavení klienta kompatibilní s nastavením podporovaným serverem.
Protokol Record Layer je vrstvený protokol. Na každé úrovni zprávy obsahují pole pro délku, popis a ověření. Protokol zápisu přijímá zprávy, které mají být přenášeny, fragmentuje data do spravovatelných bloků, inteligentně komprimuje data pomocí MAC (kód pro ověření zprávy), šifruje a přenáší výsledek. Přijatá data dešifruje, kontroluje, rozbaluje, shromažďuje a doručuje vyšším úrovním klienta.
Existují čtyři protokoly nahrávání:
Pokud implementace SSL obdrží typ záznamu, který nezná, bude tento záznam jednoduše ignorován. Jakýkoli protokol vytvořený pro použití ve spojení s SSL musí být dobře promyšlen, protože se bude muset vypořádat s útoky na něj. Všimněte si, že vzhledem k typu a délce záznamu není protokol chráněn šifrováním. Je třeba dbát na minimalizaci provozu.
Klient SSL a server souhlasí s navázáním spojení pomocí procedury handshake. Během handshake se klient a server dohodnou na různých parametrech, které budou použity k zabezpečení připojení:
Tím je handshake dokončen a zahájeno zabezpečené připojení, které je zašifrováno a dešifrováno pomocí klíčových dat. Pokud cokoli z výše uvedeného selže, navázání spojení SSL se nezdařilo a připojení se nevytvoří.
Existuje protokol změny parametrů šifrování, který signalizuje přechod do režimu šifrování. Protokol obsahuje jednu zprávu, která je zašifrována a komprimována na aktuálně vytvořeném připojení. Zpráva se skládá pouze z jednoho bitu s hodnotou 1.
struktura { enum { change_cipher_spec ( 1 ), ( 255 ) } type ; } ChangeCipherSpec ;Klient a server odešlou zprávu o změně šifry, aby přijímající straně oznámili, že následné zápisy budou chráněny podle nově sjednané specifikace CipherSpec a klíčů. Přijetí této zprávy způsobí, že přijímač dá pokyn zapisovací vrstvě, aby okamžitě zkopírovala stav čekajícího čtení do aktuálního stavu čtení. Ihned po odeslání této zprávy musí odesílatel instruovat zapisovací vrstvu, aby změnila režim zpětného zápisu na aktuální režim zápisu. Zpráva o změně šifry je odeslána během handshake, po přenosu bezpečnostních parametrů, ale před odesláním zprávy „dokončeno“.
Jedním z typů ověřování podporovaných protokolem SSL pro zápis je protokol alarmu. Alarmová zpráva sděluje potíže, se kterými se zpráva setkala, a popis alarmu. Alarmová zpráva kritické úrovně okamžitě ukončí spojení. V tomto případě mohou pokračovat další připojení odpovídající relaci, ale identifikátor relace musí být zneplatněn. Stejně jako ostatní zprávy je poplachová zpráva zašifrována a zkomprimována, jakmile je indikován aktuální stav připojení.
Zpráva datové aplikace funguje na úrovni záznamu. Je fragmentovaný, komprimovaný a šifrovaný na základě aktuálního stavu připojení. Zprávy jsou považovány za transparentní pro záznamovou vrstvu.
Proti protokolu SSL lze provést řadu útoků. SSL je však vůči těmto útokům odolný za předpokladu, že uživatel používá ke zpracování informací pouze důvěryhodné servery. SSL 2.0 je v některých situacích zranitelný [23] :
SSL 2.0 je ve výchozím nastavení zakázáno v prohlížečích počínaje Internet Explorer 7 [24] , Mozilla Firefox 2 [25] , Opera 9.5 [26] a Safari .
14. října 2014 byla identifikována zranitelnost CVE-2014-3566 s názvem POODLE (Padding Oracle On Downgraded Legacy Encryption). Tato chyba zabezpečení umožňuje útočníkovi provést útok typu Man-in-the-Middle na připojení šifrované pomocí SSL 3.0. Chyba zabezpečení POODLE je zranitelnost v protokolu a ne v žádné z jeho implementací, takže jsou jí ovlivněna všechna připojení šifrovaná pomocí SSL v3.
SSL 3.0 má další slabiny. Například polovina hlavního klíče, který se nastavuje, zcela závisí na hashovací funkci MD5, která není odolná proti kolizi, a proto není považována za bezpečnou [27] .
Tento typ útoku se provádí, když má útočník představu o tom, jaký typ zpráv je odesílán.
Kryptanalytik může vytvořit databázi, kde klíče jsou zašifrované řetězce prostého textu. Na základě vytvořené databáze můžete určit klíč relace odpovídající konkrétnímu bloku dat.
Obecně jsou takové útoky možné pro SSL. SSL se však snaží těmto útokům čelit pomocí velkých klíčů relace – klient vygeneruje klíč, který je delší, než povolují omezení exportu, jehož část je odeslána na server jako prostý text a zbytek je zkombinován s tajnou částí, aby získal dostatečně dlouhý klíč (například 128 bitů, jak vyžaduje RC4). Způsob, jak blokovat útoky ve formátu prostého textu, je vytvořit nepřijatelně velké množství požadovaného textu. Každý bit přidaný k délce klíče relace zdvojnásobuje velikost slovníku. Použití klíče relace 128 bitů činí velikost slovníku daleko za moderními technickými možnostmi (řešení by vyžadovalo množství atomů, které se nenacházejí v celém vesmíru). Dalším způsobem, jak může SSL čelit tomuto útoku, je použití maximálních možných délek klíče (v případě neexportu). Důsledkem toho je, že nejjednodušší a nejlevnější metodou útoku je čelní útok na klíč, ale u 128bitového klíče lze náklady na jeho zveřejnění považovat za nekonečné.
Reflection AttackÚtočník zaznamenává komunikační relaci mezi serverem a klientem. Později se pokusí navázat spojení se serverem přehráním zaznamenaných zpráv klienta. SSL však tento útok odpuzuje pomocí speciálního jedinečného identifikátoru připojení (IC). Teoreticky samozřejmě třetí strana nemůže IS předvídat, protože je založena na souboru náhodných událostí. Útočník s velkými prostředky by však mohl zaprotokolovat velký počet relací a pokusit se získat „správnou“ relaci na základě nonce , kterou server odeslal ve zprávě Server_Hello . Ale nonce SSL jsou dlouhé alespoň 128 bitů, což znamená, že útočník potřebuje napsat 264 nonces , aby získal 50% šanci uhodnout. Ale 2 64 je dostatečně velké číslo, aby tyto útoky ztratily smysl.
Handshake protocol attackÚtočník se může pokusit ovlivnit výměnu handshake tak, že si strany zvolí jiné šifrovací algoritmy, a ne ty, které si obvykle vybírají. Protože mnoho implementací podporuje exportované šifrování a některé dokonce podporují šifrování 0 nebo MAC, jsou tyto útoky velmi zajímavé.
Pro takový útok musí útočník rychle zfalšovat jednu nebo více handshake zpráv. Pokud k tomu dojde, klient a server vypočítají různé hodnoty hash pro zprávu handshake. V důsledku toho od sebe strany nebudou přijímat „ hotové “ zprávy . Bez znalosti tajemství nebude útočník schopen opravit hotovou zprávu , takže útok může být detekován.
Hackování připojení SSL uvnitř datového centraNejznámější incident hromadného hackování informací chráněných protokoly SSL provedli agenti FBI pomocí systémů Carnivore a NarusInsight , což vedlo k soudnímu sporu jménem organizace pro lidská práva Electronic Frontier Foundation proti AT&T, která tyto komplexy instalovala za účelem šifrování. chráněné informace.
Navzdory velkému veřejnému pobouření tohoto případu ve Spojených státech a vyšetřování na úrovni Ústavního výboru Sněmovny reprezentantů nedošlo k žádnému technologickému hacknutí protokolu SSL agenty FBI . Carnivore a NarusInsight byly nainstalovány v samotném datovém centru , kde byly servery provádějící SSL spojení se vzdálenými klienty. NarusInsight kompletně obnovil zašifrované informace tím, že nenaslouchal SSL připojení, ale internímu provozu mezi aplikačními servery v rámci samotného datového centra poté, co byla data přijatá přes SSL dešifrována samotným serverem, který je obdržel od externích uživatelů.
Tento incident však ukázal, že SSL nemůže být spolehlivým prostředkem kryptografické ochrany serverových dat na internetu, protože speciální služby mohou do datového centra instalovat naslouchací systémy, jako je NarusInsight nebo SORM-2 [28] . Jakýkoli typ kryptografie, který znamená, že klíče k šifrám jsou na přijímajícím serveru v datovém centru, je automaticky hacknut sniffery zpravodajských služeb tím, že je vloží do samotného příjemce. Dále jsou data kompletně rekonstruována podle postupů, které jsou v současnosti upraveny a legislativními zákony, jako je např. „ Vlastenecký zákon “. Tyto legislativní akty navíc zakazují až do trestního stíhání vlastníků datových center odstraňovat sniffery zpravodajských služeb z vnitřní části přijímacích serverů. S těmito systémy může SSL zabezpečit pouze připojení mezi dvěma uživateli na internetu, nikoli SSL připojení k externí webové stránce.
Útok BEASTDne 23. září 2011 thajští výzkumníci Duong a Giuliano Rizzo pomocí Java appletu prokázali „důkaz konceptu“ nazvaný Beast („Browser Exploit Against SSL/TLS“) indikující zranitelnost v TLS 1.0 [29] [30] . Dříve tuto zranitelnost, kterou původně objevil Phillip Rogaway [31] v roce 2002, prakticky nikdo nedokázal předvést. Chyba zabezpečení TLS 1.1 byla hlášena v roce 2006.
Útok je založen na několika předpokladech, ale jak se ukázalo, je docela možné je realizovat. Za prvé, kryptoanalytik musí být schopen zachytit provoz přenášený prohlížečem . Zadruhé je potřeba nějak donutit uživatele, aby přenášel data stejným bezpečným komunikačním kanálem . Nechť je navázáno bezpečné spojení mezi počítači Boba ( B ) a Alice ( A ). Předpokládejme, že i-tý blok zprávy, která k nám přišla, obsahuje tajné informace (například heslo).
C i = E ( klíč , Mi x nebo C i - 1 ), kde C i je zašifrovaný blok, Mi je tajný text
Předpokládejme, že heslo A je P . Můžeme zkontrolovat, zda je náš předpoklad správný:
Podařilo se nám tedy zachytit inicializační vektor, který se používá k zašifrování prvního bloku následující zprávy, ale zároveň je to poslední blok předchozí zprávy (v zašifrované podobě) - IV . Také jsme zachytili C i-1 . Pomocí těchto dat vytvoříme zprávu tak, aby se první blok rovnal následujícímu:
M1 = Ci - i x nebo IV x nebo P
Pokud může kryptoanalytik přenést zprávu přes stejný zabezpečený kanál, bude první blok nové zprávy vypadat takto:
C 1 = E ( Key , M 1 xor IV ) = E ( Key , ( C i-1 xor IV xor P ) xor P ) xor IV ) = E ( Key , ( C i-1 xor P )) = C i
Ukazuje se, že pokud P = M , pak se první zašifrovaný blok nové zprávy C1 bude rovnat dříve zachycenému C i .
V praxi nastává problém: blok M je dlouhý 16 bajtů, i když známe všechny bajty kromě dvou, potřebujeme 2 15 pokusů na uhodnutí zbytku. Co když nic nevíme?
Z toho vyplývá závěr, že tato praxe může fungovat, pokud má kryptoanalytik omezený počet předpokladů o hodnotě M , nebo spíše o většině obsahu tohoto bloku. Dalším předpokladem je, že kryptoanalytik může kontrolovat umístění dat v bloku, například s vědomím, že heslo má n znaků. S vědomím toho kryptoanalytik uspořádá heslo tak, že pouze 1 znak se dostane do prvního bloku a zbývajících (n-1) do dalšího - tedy prvních 15 bajtů obsahuje známá data. A k uhádnutí 1 postavy bude útočník potřebovat v nejhorším případě 256 pokusů.
O zranitelnosti se vědělo mnohem dříve, ale vývojáři utility jsou první, komu se podařilo implementovat všechny podmínky pro tento útok. A to:
Zde je seznam různých technologií a pluginů prohlížeče, které mohou provádět vložení agenta do prohlížeče oběti: Javascript XMLHttpRequest API, HTML5 WebSocket API, Flash URLRequest API, Java Applet URLConnection API a Silverlight WebClient API.
RC4 útokV roce 2013 se v Singapuru konala konference, kde profesor Dan Bernstein představil novou techniku prolomení protokolů SSL/TLS pomocí šifry RC4, která byla v roce 2011 navržena jako obrana proti BEAST. Chyba zabezpečení nalezená v RC4 souvisí s nedostatkem náhodnosti v bitovém toku, který zprávu zakódoval. Poté, co se v něm mnohokrát prohnala stejná zpráva, bylo odhaleno dostatečné množství opakujících se vzorů k obnovení původního textu. Pro útok bude muset šifrou projít obrovské množství dat. V prezentované implementaci trvalo hackování až 32 hodin, ale nebyla vyloučena možnost optimalizace procesu. Tento útok je ale v praxi těžko realizovatelný. Tvůrci tvrdí, že k obnovení 80 bajtů z 256 je potřeba 256 šifrových textů .
Odhalování šiferJak víte, SSL závisí na různých kryptografických parametrech. Pro přenos klíče a autentizaci serveru/klienta je vyžadováno šifrování veřejného klíče RSA. Jako šifra se však používají různé kryptografické algoritmy. Pokud je tedy proveden úspěšný útok na tyto algoritmy, pak již nelze SSL považovat za bezpečný. Útok na určité komunikační relace je proveden záznamem relace a poté je v průběhu času vybrán klíč relace nebo klíč RSA.
Man-in-the-middle attackTaké známý jako útok MitM (Man-in-the-Middle). Zahrnuje účast tří stran: serveru, klienta a útočníka mezi nimi. V této situaci může útočník zachytit všechny zprávy, které následují v obou směrech, a nahradit je. Zdá se, že útočník je server pro klienta a klient pro server. V případě výměny klíčů Diffie-Hellman je tento útok účinný, protože integritu přijatých informací a jejich zdroj nelze ověřit. Takový útok však není možný pomocí protokolu SSL [32] , protože k ověření zdroje (obvykle serveru) se používají certifikáty ověřené certifikační autoritou [33] .
Útok bude úspěšný, pokud:
Tento typ útoku lze nalézt ve velkých organizacích používajících firewall Microsoft Forefront TMG nebo proxy server Blue Coat Proxy SG . V tomto případě se „narušitel“ nachází na okraji sítě organizace a nahradí původní certifikát svým vlastním. Tento útok je možný díky možnosti specifikovat samotný proxy server jako důvěryhodnou certifikační autoritu (buď jako root nebo jako potomka firemního rootu). Obvykle je takový postup implementace pro uživatele transparentní díky práci podnikových uživatelů v prostředí Active Directory. Tento nástroj lze použít jak ke kontrole přenášených informací, tak ke krádeži osobních údajů přenášených pomocí zabezpečeného připojení HTTPS.
Nejkontroverznějším problémem je informovanost uživatele o možnosti zachycení dat, protože v případě náhrady kořenového certifikátu se nebudou zobrazovat žádné bezpečnostní zprávy a uživatel bude očekávat důvěrnost přenášených dat.
Kromě toho při použití Forefront TMG jako SSL proxy existuje možnost druhého útoku MitM na internetové straně, protože původní certifikát nebude převeden na uživatele a Forefront TMG lze nakonfigurovat tak, aby přijal a poté nahradil vlastní -podepsané nebo odvolané certifikáty. Pro ochranu před takovým útokem je nutné zcela zakázat práci s webovými servery, jejichž certifikáty obsahují nějaké chyby, což jistě povede k nemožnosti pracovat s protokolem HTTPS s mnoha weby.
Blue Coat Proxy SG je chráněn před druhým útokem MitM: systém umožňuje nakonfigurovat politiku tak, aby v případě nedůvěryhodného certifikátu webového serveru systém vydal také certifikát podepsaný nikoli důvěryhodným řetězcem, ale dočasným vlastním -podepsaný jeden.
THC-SSL-DOSDne 24. října 2011 vydala The Hacker's Choice (THC) nástroj THC-SSL-DOS, který lze použít k provádění útoků DoS na servery SSL. Tento nástroj využívá zranitelnost ve funkci SSL Renegotiation, která byla původně navržena tak, aby byla SSL bezpečnější. Revalidace umožňuje serveru vytvořit nový soukromý klíč přes existující připojení SSL. Tato funkce je na většině serverů ve výchozím nastavení povolena. Navázání zabezpečeného připojení, stejně jako provedení revalidace SSL, vyžaduje několikrát více zdrojů na straně serveru než na straně klienta, to znamená, že pokud klient odešle mnoho požadavků na revalidaci SSL, vyčerpá se tím systémové prostředky serveru.
Podle jednoho účastníka THC vyžaduje úspěšný útok notebook s nainstalovaným nástrojem a přístup k internetu. Program byl zveřejněn ve veřejné doméně, protože jeho protějšek se na síti objevil před několika měsíci. Podle vývojářů lze útok provést i v případě, že server nepodporuje funkci revalidace, i když to bude vyžadovat úpravu metody útoku. V tomto případě je vytvořeno mnoho TCP spojení pro nový SSL handshake, ale pro efektivní útok je potřeba více robotů.
Někteří vývojáři softwaru jako obranu doporučují nastavit specifická pravidla pro ukončení připojení s klientem, který provádí operaci opětovného ověření více než stanovený počet opakování za sekundu.
V roce 2009 na konferenci Black Hat ve Washingtonu DC Moxie Marlinspike, nezávislý hacker, předvedl nový nástroj , SSLstrip, který dokáže extrahovat důležité informace tím, že přiměje uživatele, aby uvěřili, že jsou na zabezpečené stránce, i když tomu tak není. Toho lze dosáhnout převedením normálně zabezpečených stránek SSL na jejich nezabezpečené protějšky, čímž oklamete server i klienta. Nástroj funguje, protože mnoho webů, které používají ochranu SSL, má nezabezpečenou domovskou stránku. Šifrují pouze ty úseky, kde se přenášejí důležité informace. A když uživatel klikne na autorizační stránku, nástroj nahradí odpověď webu změnou https na http. SSLstrip používá následující techniky: za prvé je v místní síti nasazen proxy server, který má platný certifikát – odtud uživatel nadále vidí v adresním řádku https, za druhé se používá technika k vytváření dlouhých URL obsahujících falešné '/ ' v adresním řádku – je to nutné, aby se zabránilo konverzi znaků v prohlížečích. Aby Moxxi dokázal, že systém funguje, spustil SSLstrip na serveru obsluhující síť Tor a za 24 hodin vylovil 254 hesel od uživatelů Yahoo , Gmail , Ticketmaster, PayPal a LinkedIn .
V protokolu SSL je zpracování chyb velmi jednoduché. Když je zjištěna chyba, ten, kdo ji objevil, o ní pošle zprávu svému partnerovi. Závažné chyby vyžadují, aby server a klient ukončili spojení [35] . Protokol SSL definuje následující chyby:
| Základní protokoly TCP /IP podle vrstev modelu OSI | |
|---|---|
| Fyzický | |
| odvedeny | |
| síť | |
| Doprava | |
| zasedání | |
| Zastoupení | |
| Aplikovaný | |
| Uplatněno jiné | |
| Seznam portů TCP a UDP | |
| Internetové bezpečnostní mechanismy | |||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Šifrování a filtrování provozu |
| ||||||||||||||
| Autentizace | |||||||||||||||
| Ochrana počítače |
| ||||||||||||||
| Zabezpečení IP telefonie |
| ||||||||||||||
| Anonymizace provozu | |||||||||||||||
| Bezdrátové zabezpečení | |||||||||||||||