Obecné

SSL (a jeho nástupce TLS ) je protokol, který pracuje přímo nad TCP (i když existují i implementace pro protokoly založené na datagramu, jako je UDP). Takto mohou být protokoly na vyšších vrstvách (například HTTP) ponechány beze změny, zatímco s do zajištění bezpečného připojení. Pod vrstvou SSL je protokol HTTP shodný s protokolem HTTPS.

Při správném použití protokolu SSL / TLS vidí útočník na kabelu pouze to, ke které IP a portu jste připojeni, tedy zhruba to, kolik dat odesíláte a jaké šifrování a komprese se používají. Může také ukončit připojení, ale obě strany budou vědět, že připojení bylo přerušeno třetí stranou.

Při typickém použití bude útočník také schopen zjistit, ke kterému hostitelskému jménu se připojujete (ale ne zbytek adresy URL): ačkoli HTTPS sám o sobě nezveřejňuje název hostitele, váš prohlížeč bude obvykle muset nejprve vytvořit požadavek DNS, aby zjistil, na jakou adresu IP má požadavek odeslat.

Vysoká -úrovňový popis protokolu

Po navázání TCP spojení klient zahájí handshake SSL. Klient (kterým může být prohlížeč i jakýkoli jiný program jako Windows Update nebo PuTTY) odešle řada specifikací:

• která verze SSL / TLS je spuštěna,
• co ciphersuites chce použít a
• co kompresní metody , které chce použít.

Server identifikuje nejvyšší verzi SSL / TLS podporovanou serverem i klientem, vybere šifrovací sadu z jedné z možností klienta (pokud ji podporuje) a volitelně zvolí metodu komprese.

Po provedení základního nastavení server odešle svůj certifikát. Tento certifikát musí být důvěryhodný buď samotným klientem, nebo stranou, které klient důvěřuje. Například pokud klient důvěřuje GeoTrust, může klient důvěřovat certifikátu z Google.com, protože GeoTrust kryptograficky podepsaný certifikát Google.

Po ověření certifikátu a ujištění se, že tento server je skutečně tím, za koho se vydává (a nikoli mužem uprostřed), dojde k výměně klíče. Může to být veřejný klíč, “ PreMasterSecret “ nebo jednoduše nic, v závislosti na zvolené šifrovací sadě. Server i klient nyní mohou vypočítat klíč pro symetrické šifrování ^{proč ne PKE?} . Klient řekne serveru, že od nynějška bude veškerá komunikace šifrována, a odešle zašifrovanou a ověřenou zprávu na server.

Server ověří, zda je MAC (používaný pro ověřování) správný a zda lze zprávu správně dešifrovat. Poté vrátí zprávu, kterou klient ověří tak jako dobře.

Handshake je nyní hotový a oba hostitelé mohou bezpečně komunikovat. Další informace najdete v technet.microsoft.com/en-us/library/cc785811 a en.wikipedia .org / wiki / Secure_Sockets_Layer .

Chcete-li připojení ukončit, použije se výstraha close_notify. Pokud se útočník pokusí ukončit připojení dokončením připojení TCP (vložením paketu FIN), obě strany budou vědět, že připojení bylo nesprávně ukončeno. Tím však nelze narušit spojení, pouze přerušit.

Další podrobnosti

Proč můžete důvěřovat webu Google.com důvěřováním GeoTrust?

Web s vámi chce bezpečně komunikovat. Chcete-li prokázat svou totožnost a ujistit se, že nejde o útočníka, musíte mít veřejný klíč serveru . Všechny klíče však můžete uložit jen těžko ze všech webových stránek na Zemi by databáze byla obrovská a aktualizace by musely běžet každou hodinu!

Řešením jsou Certifikační autority, zkráceně CA.Když jste nainstalovali operační systém nebo prohlížeč, pravděpodobně s ním přišel seznam důvěryhodných CA. Tento seznam lze libovolně upravit; můžete odebrat, komu nedůvěřujete, přidávat další, nebo si dokonce vytvořit svůj vlastní CA (ačkoli tomuto CA důvěřujete pouze vy, takže pro veřejné webové stránky to není příliš užitečné). V tomto seznamu CA je také uložen veřejný klíč CA.

Když vám server Google pošle svůj certifikát, také uvede, že je podepsán GeoTrust. Pokud důvěřujete GeoTrust, můžete ověřit (pomocí veřejného klíče GeoTrust), že GeoTrust skutečně podepsal certifikát serveru. K podpisu certifikátu sami potřebujete soukromý klíč, který zná pouze GeoTrust. Útočník tak nemůže sám podepsat certifikát a nesprávně prohlásit, že je Google.com. Pokud byl certifikát upraven co i jen o jeden bit, znaménko bude nesprávné a klient ho odmítne.

Takže pokud znám veřejný klíč, server může prokázat svou totožnost?

Ano. Veřejný klíč obvykle šifruje a dešifruje soukromý klíč. Zašifrujte zprávu pomocí veřejného klíče serveru, odešlete ji a pokud server může opakovat původní zprávu, dokázal pouze, že dostal soukromý klíč, aniž by klíč odhalil.

Proto to je tak důležité mít důvěru ve veřejný klíč: kdokoli může vygenerovat pár soukromého / veřejného klíče, také útočník. Nechcete skončit s použitím veřejného klíče útočníka!

Pokud jeden z certifikačních úřadů, kterému důvěřujete, je napaden, může útočník pomocí ukradeného soukromého klíče podepsat certifikát pro libovolný web, který se mu líbí. Když útočník může zaslat falešný certifikát vašemu klientovi, podepsaný sám soukromým klíčem od CA, které důvěřujete, váš klient neví, že veřejný klíč je padělaný, podepsaný ukradeným soukromým klíčem.

Ale CA mě může přimět důvěřovat každému serveru, který chtějí!

Ano, a tam důvěra přichází in. Musíte důvěřovat certifikační autoritě, aby nevytvářela certifikáty, jak se jim zlíbí. Když však organizace jako Microsoft, Apple a Mozilla důvěřují certifikační autoritě, certifikační autorita musí mít audity; jiná organizace je pravidelně kontroluje, aby zajistila, že vše stále běží k pravidlům.

Vydání certifikátu se provádí pouze tehdy, pokud žadatel o registraci může prokázat, že vlastní doménu, pro kterou je certifikát vydán.

Jaký je tento MAC pro ověřování zpráv?

Každá zpráva je podepsána takzvaným ověřovacím kódem zprávy nebo MAC v krátkosti. Pokud se dohodneme na klíči a hašovací šifře, můžete ověřit, že moje zpráva pochází ode mě, a já mohu ověřit, že vaše zpráva pochází od vás.

Například pomocí klíče “ správné sešívání koňské baterie “ a zpráva “ example „, Dokážu vypočítat MAC “ 58393 „. Když vám pošlu tuto zprávu s MAC (klíč již znáte), můžete provést stejný výpočet a porovnat vypočítaný MAC s MAC, který jsem poslal.

Útočník může zprávu upravit ale nezná klíč. Nemůže vypočítat správný MAC a budete vědět, že zpráva není autentická.

Zahrnutím pořadového čísla při výpočtu MAC můžete eliminovat přehrání útoky . SSL to dělá.

Řekl jste, že klient odešle klíč, který se pak použije k nastavení symetrické šifrování. Co brání útočníkovi v jeho použití?

Veřejný klíč serveru ano. Protože jsme ověřili, že veřejný klíč skutečně patří serveru a nikomu jinému, může zašifrovat klíč pomocí veřejného klíče. Když to server přijme, může ho dešifrovat pomocí soukromého klíče. Když ho obdrží kdokoli jiný, nemůže jej dešifrovat.

Proto také záleží na velikosti klíče: Čím větší je veřejný a soukromý klíč, tím těžší je prolomit klíč, který klient odešle na server.

Jak prolomit SSL

Souhrnně :

• Zkuste, pokud uživatel ignoruje upozornění na certifikát;
• Aplikace může načíst data z nezašifrovaný kanál (např. HTTP), se kterým lze manipulovat;
• nechráněnou přihlašovací stránku, která se odesílá na HTTPS, lze upravit tak, aby se odesílala na HTTP;
• mohou být neopravené aplikace zranitelný pro exploity jako BEAST a CRIME;
• uchýlit se k jiným metodám h jako fyzický útok;
• využívat postranní kanály , jako je délka zprávy a čas vytvořen pro vytvoření zprávy;
• počkejte na kvantové útoky .

Viz také: Schéma s mnoha vektory útoku proti SSL od Ivan Ristic ^(png)

Podrobněji:

Neexistuje žádný jednoduchý a přímočarý cesta; SSL je zabezpečeno, pokud je provedeno správně. Útočník může zkusit, pokud uživatel ignoruje varování certifikátu , což by okamžitě narušilo zabezpečení. Když to uživatel udělá, útočník nepotřebuje k vytvoření certifikátu soukromý klíč od CA, musí pouze poslat svůj vlastní certifikát.

Jiným způsobem by byla chyba v aplikace (na straně serveru nebo na straně klienta). Jednoduchým příkladem jsou webové stránky: pokud je jeden ze zdrojů používaných webem (například obrázek nebo skript) načten přes HTTP, důvěrnost již nelze zaručit. I když jsou prohlížeče při požadavku na nezabezpečené zdroje ze zabezpečené stránky ( zdroj ) neodesílejte záhlaví Referer HTTP, stále je možné, aby někdo odposlouchával provoz a uhodl, kde jste „navštěvuji od; například pokud vědí, že obrázky X, Y a Z jsou použity na jedné stránce, mohou uhodnout, že tuto stránku navštěvujete, když vidí, že váš prohlížeč požaduje tyto tři obrázky najednou. Při načítání JavaScriptu může být ohrožena celá stránka. Útočník může spustit libovolný skript na stránce a upravit například, komu bude bankovní transakce směřovat.

Když k tomu dojde (prostředek načítaný přes HTTP), prohlížeč zobrazí varování se smíšeným obsahem: Chrome , Firefox , Internet Explorer 9

Dalším trikem pro protokol HTTP je situace, kdy přihlašovací stránka není zabezpečena a odešle se na stránku https. “ Skvělé, “ si vývojář pravděpodobně myslel, “ nyní ukládám zatížení serveru a heslo se stále odesílá šifrované! “ Problémem je sslstrip , nástroj, který upravuje nezabezpečenou přihlašovací stránku tak, aby odešle někde, aby si ji útočník mohl přečíst.

V posledních letech došlo také k různým útokům, například zranitelnosti TLS při opětovném vyjednávání , sslsniff , BEAST a velmi nedávno KRIMINALITA . Všechny běžné prohlížeče jsou však chráněny před všemi těmito útoky, takže tyto chyby zabezpečení nepředstavují žádné riziko, pokud používáte aktuální prohlížeč.

V neposlední řadě se můžete uchýlit k jiným metodám získání informace, které SSL odmítá získat. Pokud již vidíte a manipulujete s připojením uživatele, nemusí být tak těžké nahradit jedno z jeho stažených souborů .exe keyloggerem nebo jednoduše fyzicky zaútočit na tuto osobu. Kryptografie může být spíše bezpečná, ale lidé a lidská chyba je stále slabým faktorem. Podle tohoto příspěvku společnosti Verizon se 10% narušení dat týkalo fyzických útoků (viz strana 3), takže “ určitě je třeba mít na paměti.

Komentáře

• Zajímalo by mě trochu více vysvětlení pro “ klíč je vyměněn “ za symetrický klíč. Jak se to stane, že někdo s paketovým snifferem nemá přístup.
• @Yehosef Dobrá otázka! To jsem zapomněl vysvětlit ve své odpovědi. Když se rozhlédneme kolem sebe, ukáže se, že je tomu vlastně věnována otázka: security.stackexchange.com/q/6290/10863
• @ Iwazaru Všechny CA to dělají od prvního dne. Smyslem certifikátu je poskytnout veřejný klíč pro danou doménu a místo jeho podpisu, aby se prokázalo, že je skutečně správným klíčem pro doménu. Pojďme ‚ s Encrypt dělat přesně to, co by mělo dělat: ověřit, zda vlastníš doménu, a podepsat svůj certifikát (klíčem), pokud to můžeš prokázat. Nyní každý, kdo důvěřuje Let ‚ s Encrypt, což je prakticky každý prohlížeč, bude tomuto certifikátu důvěřovat.
• Ehm, ne. TLS je skutečně právě implementován přes TCP.
• Nalezl tento grafický proces SSL handshake , velmi jasný.

Protože obecný koncept SSL již byl zahrnut do několika dalších otázek (např. this and that one ), this time I will go for details. Podrobnosti jsou důležité. Tato odpověď bude poněkud upovídaná.

Historie

SSL je protokol s dlouhou historií a několika verzemi.První prototypy pocházely z Netscape, když vyvíjely první verze svého vlajkového prohlížeče Netscape Navigator (tento prohlížeč zabil Mosaic v raných dobách Browser Wars, které stále zuří, i když s novými konkurenty). Verze 1 nebyla nikdy zveřejněna, takže nevíme, jak vypadala. SSL verze 2 je popsána v konceptu, který lze číst tam ; má řadu slabin, některé z nich jsou poměrně závažné, takže je zastaralý a novější implementace SSL / TLS jej nepodporují (zatímco starší jsou ve výchozím nastavení deaktivovány). O SSL verze 2 už nebudu hovořit, kromě příležitostných referencí.

SSL verze 3 (kterou budu nazývat „SSLv3“) byl vylepšený protokol, který funguje dodnes a je široce podporován. I když je protokol stále vlastnictvím Netscape Communications (nebo toho, kdo jej dnes vlastní), byl protokol publikován jako „historický RFC“ ( RFC 6101 ). Mezitím byl protokol standardizován s novým názvem , aby se předešlo právním problémům; nový název je TLS .

Dosud byly vyrobeny tři verze TLS, každá s vlastní vyhrazené RFC: TLS 1.0 , TLS 1.1 a TLS 1.2 . Interně jsou si navzájem velmi podobné a s SSLv3 do té míry, že implementace může snadno podporovat SSLv3 a všechny tři verze TLS, přičemž alespoň 95% kódu je společné. Přesto jsou interně všechny verze označeny číslem verze ve formátu major.minor ; SSLv3 je pak 3,0, zatímco verze TLS jsou 3,1, 3,2 a 3,3. Není tedy divu, že se TLS 1.0 někdy nazývá SSL 3.1 (a není ani nesprávný). SSL 3.0 a TLS 1.0 se liší pouze několika minutovými detaily. Protokoly TLS 1.1 a 1.2 dosud nejsou široce podporovány, i když pro to existuje impuls kvůli možným slabinám (viz níže „BEAST útok“). SSLv3 a TLS 1.0 jsou podporovány „všude“ (dokonce i IE 6.0 je zná).

Kontext

SSL si klade za cíl poskytnout bezpečný obousměrný tunel pro libovolná data. Zvažte TCP , známý protokol pro odesílání dat přes internet. TCP funguje přes „pakety“ IP a poskytuje obousměrný tunel pro bajty; funguje pro všechny hodnoty bajtů a odesílá je do dvou proudů, které mohou pracovat současně. TCP zvládá náročnou práci s rozdělením dat do paketů, jejich potvrzením, opětovným sestavením zpět do správného pořadí, přičemž odstraňuje duplikáty a znovu využívá ztracené pakety. Z pohledu aplikace, která používá TCP, existují pouze dva streamy a pakety jsou neviditelné; streamy se zejména nerozdělují na „zprávy“ (je na aplikaci, aby přijala svá vlastní pravidla kódování, pokud si přeje mít zprávy, a to přesně odpovídá HTTP ).

TCP je spolehlivý v případě „nehod“, tj. Chyb v přenosu kvůli šupinatému hardwaru, přetížení sítě, lidem se smartphony, kteří dojdou z dosahu dané základnové stanice a další události, které nejsou škodlivé. Nezmyslená osoba („útočník“) s určitým přístupem k transportnímu médiu však může číst všechna přenášená data a / nebo je úmyslně pozměnit, a TCP proti tomu nechrání. SSL.

SSL předpokládá , že funguje přes protokol podobný protokolu TCP, který poskytuje spolehlivý proud; SSL neimplementuje zpětné vydání ztracených paketů a podobné věci. Útočník je měl být schopen zcela nevyhnutelně narušit komunikaci (například může přerušit kabely), takže SSL má za úkol:

• detekovat změny (útočník nesmí být schopen změnit data tiše );
• zajistit data důvěrnost ( útočník nesmí získat znalosti o vyměňovaných datech).

SSL tyto cíle plní ve velké (nikoli však absolutní) míře.

Záznamy

SSL je vrstvené a spodní vrstva je záznamový protokol . Jakákoli data odeslaná v tunelu SSL jsou rozdělena do záznamů . Přes drát (podkladová zásuvka TCP nebo médium podobné TCP) vypadá záznam takto:

HH V1:V2 L1:L2 data

kde:

• HH je jeden bajt, který označuje typ dat v záznamu.Jsou definovány čtyři typy: change_cipher_spec (20), alert (21), handshake (22) a application_data ( 23).
• V1: V2 je verze protokolu, přes dva bajty. U všech aktuálně definovaných verzí má V1 hodnotu 0x03, zatímco V2 má hodnotu 0x00 pro SSLv3, 0x01 pro TLS 1,0, 0x02 pro TLS 1,1 a 0x03 pro TLS 1.2.
• L1: L2 je délka data v bajtech (konvence big-endian je použité: délka je 256 * L1 + L2). Celková délka data nemůže překročit 18432 bajtů, ale v praxi této hodnoty ani nemůže dosáhnout.

Záznam má tedy pětinásobek záhlaví bajtů, následované maximálně 18 kB dat. V data je použito symetrické šifrování a kontrola integrity. Když je vydán záznam, odesílatel i příjemce se mají shodnout na tom, které kryptografické algoritmy jsou aktuálně použity a s jakými klíči; tato dohoda je získána protokolem handshake, který je popsán v následující části. V tomto bodě je také použita komprese.

Ve všech detailech funguje záznam záznamu takto:

• Zpočátku existuje několik bajtů k přenosu ; to jsou data aplikace nebo nějaký jiný druh bajtů. Toto užitečné zatížení sestává z maximálně 16384 bajtů, ale možná i méně (užitečné zatížení o délce 0 je legální, ale ukazuje se, že Internet Explorer 6.0 se vůbec nelíbí) .
• Užitečné zatížení je poté komprimováno libovolným kompresním algoritmem, na kterém se aktuálně dohodnete. Komprese je stavová a může tedy záviset na obsahu předchozích záznamů. V praxi je komprese buď „null“ (vůbec žádná komprese), nebo „Deflate“ ( RFC 3749 ), přičemž druhá je v současné době zdvořile, ale pevně zobrazena dveře v kontextu webu kvůli nedávnému CRIME útoku . Komprese si klade za cíl zkrácení dat, ale v některých nepříznivých situacích je nutně musí mírně rozšířit (kvůli principu pigeonhole ). SSL umožňuje rozšíření na maximálně 1024 bajtů. Nulová komprese se samozřejmě nikdy nerozšiřuje (ale nikdy se nezkrátí); Deflate se rozšíří o maximálně 10 bajtů, pokud je implementace dobrá.
• Komprimované užitečné zatížení je pak chráněno proti změnám a šifrováno. Pokud jsou aktuální algoritmy šifrování a integrity „null“, pak je tento krok bez operace. V opačném případě se přidá MAC , pak nějaké polstrování (v závislosti na šifrovacím algoritmu) a výsledek se zašifruje. Tyto kroky opět vyvolají určité rozšíření, které standard SSL omezuje na 1024 dalších bajtů (v kombinaci s maximálním rozšířením z kroku komprese se tak dostáváme k 18432 bajtům, ke kterým musíme přidat 5bajtové záhlaví). >

MAC je obvykle HMAC s jednou z obvyklých hash funkcí (většinou MD5, SHA-1 nebo SHA-256) (u SSLv3 nejde o „opravdový“ HMAC, ale o něco velmi podobného a podle našich nejlepších znalostí stejně bezpečného jako HMAC). Šifrování použije buď blokovou šifru v režimu CBC , nebo RC4 streamovou šifru. Teoreticky je možné použít i jiné druhy režimů nebo algoritmů, například jeden z těchto šikovných režimů, které kombinují šifrování a kontroly integrity; existuje dokonce nějaký RFC . V praxi o nich ale implementované implementace zatím nevědí, takže dělají HMAC a CBC. Klíčové je, že MAC je nejprve vypočítán a připojen k datům a výsledek je zašifrován. Toto je MAC-then-encrypt a ve skutečnosti to není příliš dobrý nápad . MAC je počítán na základě zřetězení (komprimovaného) užitečného zatížení a pořadového čísla, takže pracovitý útočník nemusí vyměňovat záznamy.

Handshake

handshake je protokol, který se přehrává v záznamovém protokolu. Jeho cílem je stanovit algoritmy a klíče, které se mají použít pro záznamy. Skládá se z zpráv . Každá handshake zpráva začíná čtyřbajtovou hlavičkou, jeden bajt, který popisuje typ zprávy, pak tři bajty pro délku zprávy (konvence big-endian). Následné handshake zprávy se poté odesílají se záznamy označenými typem „handshake“ (první bajt záhlaví každého záznamu má hodnotu 22).

Povšimněte si vrstev: handshake zprávy, doplněné čtyřmi záhlaví bajtů, jsou poté odeslány jako záznamy a každý záznam také má své vlastní záhlaví. Kromě toho lze v rámci stejného záznamu odeslat několik zpráv handshake a danou zprávu handshake lze rozdělit na několik záznamů.Z pohledu modulu, který vytváří handshake zprávy, jsou „záznamy“ jen proud, na který lze odesílat bajty; na skutečné rozdělení tohoto streamu do záznamů se vůbec nevztahuje.

Úplné handshake

Zpočátku se klient a server „shodují“ na nulovém šifrování bez MAC a nulové komprese. To znamená, že záznam, který nejprve pošlou, bude odeslán jako prostý text a nechráněný.

První zprávou handshake je ClientHello. Jedná se o zprávu, kterou klient uvádí svůj záměr udělat nějaké SSL. Všimněte si, že „klient“ je symbolická role; znamená to „strana, která hovoří první“. Stává se, že v kontextu HTTPS, kterým je HTTP-within-SSL-within-TCP, mají všechny tři vrstvy pojem „klient“ a „server“ a všechny souhlasí (klient TCP je také klientem SSL a klient HTTP), ale to je taková náhoda.

Zpráva ClientHello obsahuje:

• maximální protokol verze, kterou si klient přeje podporovat;
• „random random“ (32 bajtů, z nichž 28 má být generováno kryptograficky silným generátorem čísel);
• „ ID relace „(v případě, že klient chce obnovit relaci ve zkráceném podání ruky, viz níže);
• seznam“ šifrovacích sad „, o kterých klient ví, seřazený podle preferencí klienta;
• seznam kompresních algoritmů, o kterých klient ví, seřazený podle preferencí klienta;
• některá volitelná rozšíření.

A šifrovací sada je 16bitový symbolický identifikátor sady kryptografů c algoritmy. Například šifrovací sada TLS_RSA_WITH_AES_128_CBC_SHA má hodnotu 0x002F a znamená „záznamy používají šifrování HMAC / SHA-1 a AES se 128bitovým klíčem a výměna klíčů probíhá šifrováním náhodný klíč s veřejným klíčem RSA serveru.

Server reaguje na ClientHello pomocí ServerHello který obsahuje:

• verze protokolu, kterou klient a server použijí ;
• „server random“ (32 bajtů, 28 random bytes);
• ID relace pro toto připojení;
• šifrovací sada, která bude použita;
• kompresní algoritmus, který bude použit;
• volitelně některá rozšíření.

Úplné podání ruky vypadá takto:

 Client Server ClientHello --------> ServerHello Certificate* ServerKeyExchange* CertificateRequest* <-------- ServerHelloDone Certificate* ClientKeyExchange CertificateVerify* [ChangeCipherSpec] Finished --------> [ChangeCipherSpec] <-------- Finished Application Data <-------> Application Data 

(toto schéma byl nestydatě zkopírován z RFC.)

Vidíme ClientHello a ServerHello. Poté server odešle několik dalších zpráv, které závisí na šifrovací sadě a některých dalších parametrech rs:

• Certifikát: certifikát serveru, který obsahuje jeho veřejný klíč. Více o tom níže. Tato zpráva je odesílána téměř vždy, s výjimkou případů, kdy šifrovací sada vyžaduje handshake bez certifikátu.
• ServerKeyExchange: některé další hodnoty pro výměnu klíčů, pokud to, co je v certifikátu, nestačí. Zejména šifrovací sady „DHE“ používají dočasnou výměnu klíčů Diffie-Hellman , která tuto zprávu vyžaduje.
• CertificateRequest: zpráva požadující, aby se klient také identifikoval svým vlastním certifikátem. Tato zpráva obsahuje seznam názvů důvěryhodných kotev (aka „kořenové certifikáty“), které server použije k ověření klientského certifikátu.
• ServerHelloDone: značkovací zpráva (s nulovou délkou), která říká, že server je hotový, a klient by měl nyní mluvit.

Klient pak musí odpovědět s:

• Certifikát: certifikát klienta, pokud server si jeden vyžádal. Mezi verzemi existují jemné variace (u SSLv3 musí klient tuto zprávu vynechat, pokud nemá certifikát; u TLS 1.0+ musí ve stejné situaci odeslat Certificate zpráva s prázdným seznamem certifikátů).
• ClientKeyExchange: klientská část skutečné výměny klíčů (např. náhodná hodnota šifrovaná klíčem RSA serveru).
• CertificateVerify: a digitální podpis vypočítaný klientem přes všechny předchozí handshake zprávy. Tato zpráva se odešle, když server požádal o certifikát klienta a klient vyhověl. Takto klient prokáže serveru, že skutečně „vlastní“ veřejný klíč, který je zakódován v certifikátu, který odeslal.

Poté klient odešle ChangeCipherSpec zpráva, která není handshake zprávou: má svůj vlastní typ záznamu, takže bude odeslána v záznamu vlastním.Jeho obsah je čistě symbolický (jeden bajt s hodnotou 1). Tato zpráva označuje bod, ve kterém klient přepne na nově sjednanou šifrovací sadu a klíče. Následné záznamy od klienta budou poté zašifrovány.

Zpráva Finished je vypočítaný kryptografický kontrolní součet přes všechny předchozí handshake zprávy (od klienta i serveru). Protože je vydáván po ChangeCipherSpec, vztahuje se na něj také kontrola integrity a šifrování. Když server přijme tuto zprávu a ověří její obsah, získá důkaz, že po celou dobu skutečně mluvil se stejným klientem. Tato zpráva chrání handshake před změnami (útočník nemůže upravovat handshake zprávy a přesto získá Finished zprávu správně).

Server nakonec odpoví svými vlastními ChangeCipherSpec pak Finished. V tomto bodě je handshake dokončen a klient a server si mohou vyměňovat data aplikace (v takto označených šifrovaných záznamech).

Pamatovat: klient navrhne , ale server zvolí . Šifrovací sada je v rukou serveru. Zdvořilé servery by se měly řídit preferencemi klienta (pokud je to možné), ale mohou to dělat jinak a některé skutečně ano (např. Jako součást ochrany proti BEAST).

Zkrácené handshake

Při úplném navázání spojení server odešle klientovi „ID relace“ (tj. Skupinu až 32 bajtů). Později se klient může vrátit a odeslat stejné ID relace jako součást svého ClientHello. To znamená, že klient si stále pamatuje šifrovací sadu a klíče z předchozího handshake a rád by tyto parametry znovu použil. Pokud si server také pamatuje šifrovací sadu a klíče, zkopíruje toto konkrétní ID relace do svého ServerHello a poté následuje zkrácené podání ruky :

 Client Server ClientHello --------> ServerHello [ChangeCipherSpec] <-------- Finished [ChangeCipherSpec] Finished --------> Application Data <-------> Application Data 

Zkrácené podání ruky je kratší: méně zpráv, žádné asymetrický kryptografický obchod, a co je nejdůležitější, snížená latence . Webové prohlížeče a servery toho dělají hodně. Typický webový prohlížeč otevře připojení SSL úplným podáním ruky, poté provede zkrácená podání ruky pro všechna ostatní připojení ke stejnému serveru: ostatní připojení, která se otevírají paralelně, a také následující připojení ke stejnému serveru. Typické webové servery skutečně ukončí připojení po 15 sekundách nečinnosti, ale relace (šifrovací sada a klíče) si budou pamatovat mnohem déle (možná hodiny nebo dokonce dny).

Výměna klíčů

Existuje několik algoritmů pro výměnu klíčů, které SSL může používat. To je specifikováno šifrovací sadou; každý algoritmus výměny klíčů pracuje s některými druhy veřejných klíčů serveru. Nejběžnější algoritmy pro výměnu klíčů jsou:

• RSA: klíč serveru je typu RSA. Klient vygeneruje náhodnou hodnotu („ pre-master tajemství „48 bajtů, z toho 46 náhodných) a zašifruje jej veřejným klíčem serveru. Neexistuje žádný ServerKeyExchange.
• DHE_RSA: klíč serveru je typu RSA, ale používá se pouze pro podpis. Skutečná výměna klíčů používá Diffie-Hellman. Server odešle zprávu ServerKeyExchange obsahující parametry DH (modul, generátor) a nově vygenerovaný veřejný klíč DH; navíc server podepíše tuto zprávu. Klient odpoví zprávou ClientKeyExchange, která obsahuje také nově vygenerovaný veřejný klíč DH. DH získá „pre-master secret“ „.
• DHE_DSS: jako DHE_RSA, ale server má klíč DSS (“ DSS „je také známý jako „DSA“ ). DSS je algoritmus pouze pro podpis.

Mezi méně často používané algoritmy pro výměnu klíčů patří:

• DH: klíč serveru je typu Diffie-Hellman (mluvíme o certifikátu , který obsahuje Klíč DH). To bývalo „populární“ administrativním způsobem (americká vláda nařídila jeho použití), když byl patent RSA stále aktivní (to bylo během předchozího století). Navzdory byrokratickému tlaku nebyl nikdy tak široce nasazen jako RSA.
• DH_anon: jako DHE apartmá, ale bez podpisu ze serveru. Toto je šifrovací sada bez certifikátu. Konstrukčně je zranitelný vůči útokům typu Man-in-the-Middle , takže je povolen velmi zřídka.
• PSK: předsdílený klíč šifrovací sady. Symetrická výměna klíčů založená na předem stanoveném sdíleném tajemství.
• SRP: aplikace protokolu SRP , což je Protokol s ověřením hesla . Klient a server se navzájem ověřují, pokud jde o sdílené tajemství, kterým může být heslo s nízkou entropií (zatímco PSK vyžaduje sdílené tajemství s vysokou entropií). Velmi šikovný. Zatím není široce podporováno.
• Pomíjivý klíč RSA: jako DHE, ale s nově vygenerovaným párem klíčů RSA. Vzhledem k tomu, že generování klíčů RSA je drahé, nejde o oblíbenou možnost a bylo zadáno pouze jako součást šifrovacích balíčků „export“, které vyhovovaly exportním předpisům USA o kryptografii před rokem 2000 (tj. Klíče RSA maximálně 512 bitů). To dnes nikdo nedělá.
• Varianty DH* algoritmů s eliptickými křivkami . Velmi módní. Mělo by se v budoucnu stát běžným.

Certifikáty a ověřování

Digitální certifikáty jsou nádoby pro asymetrické klíče. Jsou určeny k řešení distribuce klíčů. Klient chce konkrétně použít veřejný klíč serveru. Útočník se pokusí přimět klienta, aby použil veřejný klíč útočníka . Klient tedy musí mít způsob, jak se ujistit, že používá správný klíč.

SSL by mělo používat X.509 . Toto je standard pro certifikáty. Každý certifikát je podepsán certifikační autoritou . Myšlenka je, že klient inherentně zná veřejné klíče hrstky CA (jedná se o „důvěryhodné kotvy“ nebo „kořenové certifikáty“). Pomocí těchto klíčů může klient ověřit podpis vypočítaný CA prostřednictvím certifikátu, který byl vydán serveru. Tento proces lze rekurzivně rozšířit: CA může vydat certifikát pro jinou CA (tj. podepsat strukturu certifikátu, která obsahuje další název a klíč CA). Řetěz certifikátů počínaje kořenovou CA a končící certifikátem serveru, s mezilehlými certifikáty CA mezi nimi, přičemž každý certifikát je podepsán relativně k veřejnému klíči, který je zakódován v předchozím certifikátu, je nazýván bez představivosti > řetězec certifikátů .

Klient by tedy měl dělat toto:

• Získat řetězec certifikátů končící certifikátem serveru. Zpráva Certificate ze serveru má přesně takový řetězec obsahovat.
• Ověření řetězce, tj. Ověření všech podpisy a jména a různé bity X.509. Klient by také měl zkontrolovat stav odvolání všech certifikátů v řetězci, což je složité a těžké (nyní to dělají webové prohlížeče, víceméně, ale to je nedávný vývoj).
• Ověřte, zda je zamýšlený název serveru skutečně napsán v certifikátu serveru. Protože klient nechce používat pouze ověřený veřejný klíč, chce také použít veřejný klíč konkrétního serveru . Podrobnosti o tom, jak se to děje v kontextu HTTPS, najdete v RFC 2818 . .

Certifikační model s certifikáty X.509 byl často kritizován, a to nikoli z technických důvodů, ale spíše z politicko-ekonomických důvodů. Koncentruje ověřovací moc do rukou několika hráčů , kteří nejsou nutně dobře mínění, nebo přinejmenším ne vždy kompetentní . Znovu a znovu jsou zveřejňovány návrhy jiných systémů (např. Konvergence nebo

Po zdlouhavé představení SSL v předchozí odpovědi , pojďme se zabavit, jmenovitě:

Útoky na SSL

Došlo k mnoha útokům na SSL, některé stavěly na chybách implementace, jiné na slabých stránkách skutečného protokolu.

Je třeba si uvědomit, že zatímco SSL je jedním z nejvíce napadených protokolů (protože se jedná o velmi vysoký profil: úspěšná aplikace na SSL vypadá velmi pěkně v abstraktu výzkumného článku), SSL je také jedním z nejvíce opravených protokolů.Je třeba jej považovat za robustní právě proto, že všechny známé způsoby útoku na transportní protokoly byly vyzkoušeny na SSL a SSL bylo případně opraveno.

Vrácení verze

V počátcích SSLv3 byl SSLv2 stále široce používán, a proto klienti běžně posílali zprávy, které pouze naznačovaly, že je podporován také SSLv3; server by pak vzal nápovědu a odpověděl v dialektu SSLv3 + (podrobnosti viz Příloha E RFC 2246 ). Protože SSLv2 měl slabosti, bylo v nejlepším zájmu útočníka zajistit, aby klient a server, oba znající SSLv3, mohli spolu komunikovat pomocí SSLv2. Tomu se říká útok odvolání verze . Koncept se formálně rozšiřuje i na pozdější verze.

Byly přidány příkrovy, které detekují pokusy o vrácení zpět. Pro vrácení zpět na SSLv2 by měl klient, který zná SSLv3 +, použít speciální výplň pro krok šifrování RSA (SSLv2 podporuje pouze výměnu klíčů založenou na RSA): v PKCS # 1 , data, která mají být zašifrována, mají být vyplněna množstvím náhodných bytů; klient s vědomím SSLv3 by pak měl nastavit každý z posledních osmi výplňových bytů na pevnou hodnotu 0x03. Server poté zkontroluje tyto bajty; pokud je nalezeno osm 0x03, pak je nejpravděpodobnější pokus o vrácení zpět a server pokus odmítne (klient pouze pro SSLv2 má pravděpodobnost pouze 255 ^-8 použít takové odsazovací bajty z naprostého nedostatku štěstí, takže falešná pozitiva se vyskytují se zanedbatelnou rychlostí).

Pro vrácení zpět ke staré verzi SSL / TLS, ale ne starší než SSLv3, byl přidán další klíč: v pre-master tajemství ze 48 bajtů, které klient zašifruje klíčem RSA serveru, první dva bajty nejsou náhodné, ale měly by se rovnat „maximální podporované verzi protokolu“, kterou klient napsal jako první ve své ClientHello zpráva. Bohužel se někteří klienti zmýlili a tato kludge funguje pouze s výměnou klíčů založenou na RSA, takže ochrana proti vrácení je zde velmi omezená. Naštěstí má SSLv3 + další, mnohem účinnější ochranu proti rollbacks, což znamená, že handshake zprávy jsou hashovány společně, když jsou vytvořeny zprávy Finished. chrání proti vrácení zpět, pokud by „stará verze“ nebyla tak důkladně slabá, že by útočník mohl úplně prolomit celé šifrování před koncem samotného podání ruky. To se zatím nestalo (SSLv3 je stále dostatečně robustní).

Slabé šifrovací sady

Některé standardní šifrovací sady jsou nějakým způsobem záměrně slabé. Existují:

• některé šifrovací sady bez šifrování, pouze kontrola integrity, např. TLS_RSA_WITH_NULL_SHA;
• některé šifrovací sady se 40bitovým šifrováním, například TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 (šifrovací sady jsou v souladu s přísná exportní pravidla USA z minulého století – tyto předpisy byly většinou zrušeny na konci éry Billa Clintona);
• některé šifrovací sady s 56bitovým šifrováním, například TLS_RSA_WITH_DES_CBC_SHA. 56bitový DES je rozbitný existující technologií , ale pro amatéra (i znuděného studenta s přístupem k několika stovkám univerzitních strojů) je to stále trochu těžké ), takže mám tendenci kvalifikovat 56bitový DES jako „střední sílu“.

Tím se otevírá cesta k variantě útoků s odvoláním verze, kdy útočník nutí klienta a server souhlasit na slabé šifrovací sadě, myšlenka je, že útočník upraví seznam šifrovacích sad oznámených klientem. To je pro útočníka proveditelné, pokud je vybraná šifrovací sada tak slabá, že ji může rozbít, aby přepočítal zjevně správnou Finished zpráva. Ve skutečnosti je MAC použitý v SSLv3 + (i když je založen na MD5) dostatečně robustní, aby tomu zabránil. Takže zde se nemusíte obávat. Také si myslím, že zde existuje nějaká skutečná slabost je, když klient nebo server souhlasí s použitím slabé šifrovací sady vůbec.

Ve výchozím nastavení moderní webové prohlížeče neumožňují použití těchto slabých šifrovacích sad.

Krádež soukromého klíče

Pokud připojení SSL používá výměnu klíčů RSA, a útočník si ponechá kopii záznamů a poté později (možná měsíce poté, případně kontrolou všech záloh na vyřazených pevných discích nebo páskách) získá kopii soukromého klíče, pak může rozluštit potřesení rukou a dešifrování dat.

Perfect Forward Secrecy je o tom, jak tomu „později“ čelit. Získáte ji pomocí DHE šifrovacích sad. U šifrovací sady DHE je skutečným soukromým klíčem, který lze použít k rozluštění handshake, pomíjivý klíč Diffie-Hellman, nikoli soukromý klíč serveru RSA (nebo DSS).Protože byl pomíjivý, existoval pouze v RAM a nikdy nebyl zapsán na pevný disk; jako takový by měl být mnohem odolnější vůči krádeži v postranní oblasti.

Takže lekce zní: zpravidla zkuste použít šifrovací sadu DHE, pokud je to možné. Měli byste stále myslet na své zálohy a nenechat uniknout váš soukromý klíč, ale přinejmenším sady DHE způsobují takový únik o něco menší problém, zvláště pokud k němu dojde po skončení životnosti klíče (tj. Odpovídající certifikát není déle platné).

Potíže s certifikátem

Celý obchod s certifikáty je bolavé místo v SSL.

Technicky je SSL zcela nezávislé na X.509. Řetězy certifikátů jsou vyměňovány jako neprůhledné objekty BLOB. V určitém okamžiku musí klient použít veřejný klíč serveru, ale klient může tento klíč „znát“ jakýmkoli způsobem, který uzná za vhodný. V některých konkrétních scénářích, kde lze použít SSL, klient již zná server „je veřejný klíč (napevno v kódu) a ignoruje pouze certifikát odeslaný serverem. V běžném případě HTTPS však klient provádí ověření řetězce certifikátů serveru, jak je popsáno v X.509 ( přečtěte si to na úkor svého rozumu; byli jste varováni).

Tím se získá řada vektorů útoku, například:

• Ověření znamená ověření, že certifikáty jsou stále platné k aktuálnímu datu. Jak klientský počítač zná aktuální datum? S jeho interními hodinami a případně rozhovorem se servery NTP (v docela nechráněný způsob!). Klient by mohl být vypnutý o několik minut, hodin, dnů, dokonce let (viděl jsem to) a do jisté míry by ho mohl silný útočník přinutit manipulovat se zprávami NTP. To by umožnilo útočník použije zastaralé certifikáty, které byly před lety zrušeny. Všimněte si zábavné skutečnosti: SSL „client random“ a „server random“ by měly obsahovat 28 náhodných bajtů a místní datum a čas (více než 4 bajtů). Toto zahrnutí času mělo být součástí řešení proti časovým útokům. Nejsem si vědom žádných implementací, které to skutečně kontrolují.

• Až do roku 2003 implementace ověřování certifikátů v Internet Exploreru / Windows nezpracovala příponu „Základní omezení“ správně. Čistým efektem bylo, že kdokoli s certifikátem 100 € mohl fungovat jako CA a vydávat „certifikáty“ s libovolně zvoleným jménem a klíči.

• X .509 obsahuje funkci omezování poškození nazvanou odvolání : jde o publikování seznamu vyřazených certifikátů, které vypadají dobře, kryptograficky vzato, ale neměly by být důvěryhodné (např. Jejich soukromý klíč byl odcizen, nebo obsahují chybné jméno). Odvolání funguje, pouze pokud zúčastněné strany (tj. Prohlížeče) přijmou stažení mamutových seznamů odvolání (které mohou mít i několik megabajtů!) Nebo kontaktování serverů OCSP . Moderní prohlížeče to nyní dělají, ale trochu neochotně, a mnoho z nich se i tak připojí, pokud nebudou moci získat informace o stavu odvolání včas (protože lidský uživatel není trpělivý). Celková situace se v průběhu let zlepšovala, ale poměrně pomalu.

• Některá kořenová CA se v minulosti dopustila nějakých omylů (např. Comodo a DigiNotar). To mělo za následek vydání falešných certifikátů (název je www.microsoft.com, ale soukromý klíč není vůbec v rukou společnosti Microsoft …). Tyto chyby byly objeveny a certifikáty zrušeny, ale stále to vyvolává nepříjemné otázky (např. Existují další CA, kteří měli takové problémy, ale neodhalili je, nebo, co je ještě horší, nikdy si je nevšimli?)

X.509 je velmi složitá sestava algoritmů, technologií, specifikací a výborů a je velmi těžké ji správně uvést. Pokus o „ruční“ dekódování certifikátů X.509 v nechráněném programovacím jazyce, jako je C, je snadný způsob, jak získat přetečení vyrovnávací paměti.

Bleichenbacher Attacks

Daniel Bleichenbacher nalezl v roce 1998 pěkný útok proti RSA. Když zašifrujete část dat pomocí protokolu RSA (jak je tomu u zprávy ClientKeyExchange v protokolu SSL), musí být data, která mají být zašifrována, vyplněna , aby vytvořit sekvenci bajtů stejné délky jako modul RSA. Výplň se skládá převážně z náhodných bajtů, ale existuje trochu struktury (zejména první dva bajty po výplni musí být 0x00 0x02).

Po dešifrování (tedy na serveru) musí být výplň být nalezen a odstraněn. Stává se tak, že v té době, kdy server dešifroval, ale získal neplatné polstrování (0x00 0x02 bajtů tam nebylo), pak to nahlásil varovnou zprávou (podle specifikace SSL), zatímco platná polstrování vyústila server pomocí zdánlivě dešifrované hodnoty a pokračováním handshake.

Tento druh věcí je znám jako padding oracle . Umožňuje útočníkovi poslat libovolnou sekvenci bajtů, jako by šlo o šifrované pre-hlavní tajemství, a vědět, zda by dešifrování této sekvence přineslo platnou výplň nebo ne. To je pouhá 1-bitová informace, ale stačí obnovit soukromý klíč s několika miliony požadavků (s rafinovaně vytvořenými „zašifrovanými“ řetězci).

Řešení: když výsledkem dešifrování je neplatný odsazení, server pokračuje v používání náhodného pre-master tajemství. Potvrzení handshake pak později selže se zprávami Finished. Všechny současné implementace SSL to dělají.

Polstrování Oracle se vrací zpět

Další oblast, kde bylo nalezeno polstrování Oracle, je v zaznamenejte sami. Zvažte šifrování CBC a HMAC. Data, která se mají šifrovat, se nejprve MACují, poté se zašifruje výsledek. U šifrování CBC musí mít data, která mají být šifrována, délku, která je násobkem velikosti bloku (8 bajtů pro 3DES, 16 bytů pro AES). Je tedy použita nějaká výplň s určitou strukturou.

V té době (útok zjistil Vaudenay v roce 2002), kdy implementace SSL zpracovávala příjem d záznam, vrátil odlišné výstražné zprávy pro tyto dvě podmínky:

• Při dešifrování nebyla nalezena žádná platná struktura výplně.
• Při dešifrování, byla nalezena platná výplň, ale pak byl MAC ověřen a neodpovídal.

Toto je výplň Oracle, kterou lze použít k obnovení některých šifrovaných dat. Vyžaduje aktivního útočníka, ale není to tak těžké. Vaudenay jej implementoval a byl rozšířen na případ, kdy upravená implementace SSL vrátila v obou případech stejnou výstražnou zprávu, ale návrat ve druhém případě trval déle, protože je potřeba čas na přepočet MAC (pěkná ukázka a načasování útoku ).

Protože se lidé nikdy nepoučí, implementace SSL od Microsoftu použitá v ASP.NET byla stále neopraveno od roku 2010 (o osm let později!), kdy Rizzo a Duong znovu provedli útok Vaudenay a vytvořili demonstraci, která obnovila soubory cookie HTTP.

Viz tato stránka pro některé ukazatele. Je třeba si uvědomit, že kdyby SSL používalo encrypt-then-MAC , bylo by se těmto problémům vyhnout (chybné záznamy by byly na úrovni MAC odmítnuty dříve, než i vzhledem k dešifrování).

BEAST

Útok BEAST je opět z Duong a Rizzo a opět jde o remake staršího útoku (od Philipa Rogawaye v roce 2002). Chcete-li získat představu, zvažte CBC . V tomto provozním režimu je každý blok dat nejprve XORován s výsledkem šifrování předchozího bloku; a to je výsledek XORu, který je šifrován. To se provádí za účelem „randomizace“ bloků a zabránění únikům, které se vyskytují v režimu ECB. Protože první blok nemá „předchozí“ blok, musí existovat Inicializační vektor (IV), který hraje roli předchozího bloku pro první blok.

Ukázalo se, že pokud útočník dokáže ovládat část dat, která mají být zašifrována, a také dokáže předpovědět použitou IV, pak může ze šifrovacího stroje udělat další dešifrování Oracle a použít jej k obnovení některých dalších zašifrovaných dat (které si útočník nevybírá). U SSLv3 a TLS 1.0 však útočník může předpovědět IV záznamu: je to poslední blok předchozí záznam! Útočník tedy musí být schopen odeslat některá data ve streamu, aby „odeslal“ cílová data, a to v okamžiku, kdy implementace vytvořila a odeslala předchozí záznam (obvykle v hodnotě 16 kB dat bylo nashromážděno), ale nezačalo se budovat další.

Protokol TLS 1.1+ je proti tomu chráněn, protože v TLS 1.1 (a následujících verzích) se používá náhodný IV na záznam. U protokolů SSLv3 a TLS 1.0 je řešením odesílat záznamy s nulovou délkou: to znamená záznamy s užitečným zatížením o délce nuly – ale s MAC a polstrováním a šifrováním a MAC se počítá z tajného klíče a přes sekvenci číslo, takže toto hraje roli generátoru náhodných čísel. Bohužel IE 6.0 tlumí záznamy nulové délky. Mezi další strategie patří rozdělení 1 / n-1 (záznam n bajtů se odesílá jako dva záznamy, jeden s jediným bajtem užitečného zatížení, druhý se zbývajícími n-1 ).

Dalším řešením je vynutit použití šifrovací sady jiné než CBC, pokud je to možné – server vybere šifrovací sadu založenou na RC4, pokud je v seznamu šifrovacích sad zasílaných klient, i když by klient preferoval šifrovací sadu založenou na CBC. Tento nástroj vám řekne, zda daný server zřejmě jedná takhle.(Poznámka: BEAST je útok na klienta , ale výběrem šifrovací sady RC4 může server chránit neopatrného klienta.)

Viz tato stránka pro některé ukazatele. Zatímco protokol TLS 1.1 pochází z roku 2006, útok BEAST může donutit dodavatele prohlížečů konečně upgradovat.

CRIME

Pokud jde o jakoukoli hollywoodskou franšízu, vydali Duong a Rizzo v roce 2012 pokračování pokračování. CRIME využívá únik, který byl teoretizován před lety, ale byl živě demonstrován na demonstraci, kterou nedávno zveřejnili. CRIME využívá kompresi ve stejném nastavení jako útok BEAST (útočník může odeslat některá vlastní data v připojení SSL, kam se také odesílají zajímavá cílová data, například cookie). Zhruba řečeno, útočník vloží do svých dat potenciální hodnotu pro cílový řetězec a pokud se shoduje, komprese zkrátí výsledné záznamy. Viz tuto otázku , kde najdete (pregognitivní) analýzu.

CRIME je zabráněno tím, že vůbec nepoužíváte kompresi na úrovni TLS, což je co teď dělají prohlížeče. Internet Explorer a IIS nikdy vůbec neimplementovaly kompresi na úrovni TLS (jednou to byla nedbalost); Firefox a Chrome jej implementovaly a deaktivovaly letos v létě (varovaly je Duong a Rizzo, kteří jsou za jejich činnost zcela odpovědní).

Zločin ukazuje, proč jsem psal, těsně před začátkem mého Vysvětlení protokolu SSL :

SSL tyto cíle plní do značné míry (nikoli však absolutně).

Šifrování skutečně propouští délku šifrovaných dat. Proti tomu není známé dobré řešení. A samotná délka může odhalit spoustu věcí. Například při pozorování připojení k síti pomocí síťového monitoru můžeme v proudu rozpoznat „další potřesení rukou“ (protože první bajt každého záznamu identifikuje typ dat v záznamu a není šifrován); s délkami záznamů je docela snadné zjistit, zda klient poskytl certifikát, či nikoli.

Pudl

( upravit: tato sekce byla přidána dne 2014-10-15)

Útok „Poodle“ využívá chybu, která je specifická pro SSL 3.0 s šifrovacími sadami založenými na CBC. Spoléhá se na často přehlíženou vlastnost protokolu SSL 3.0: většina bajtů výplně je ignorována. V TLS 1.0 je plně specifikováno odsazení (bajty přidané do záznamu, aby byla délka kompatibilní s šifrováním CBC, které zpracovává pouze celé bloky); všechny bajty musí mít konkrétní hodnotu a příjemce to zkontroluje. V protokolu SSL 3.0 je obsah polstrování bajtů ignorován, což umožňuje útočníkovi provádět změny, které zůstávají většinou bez povšimnutí. Tato změna ovlivní pouze neaplikovatelná data, ale může být použita jako dešifrovací věštec vágně podobným způsobem jako BEAST.

Více podrobností si můžete přečíst v tomto odpověď .

Budoucnost

Lidé se nikdy nepoučí. Existuje velký tlak na přidání šikovných rozšíření k SSL z mnoha důvodů, které na začátku vždy vypadají dobře, ale mohou způsobit další problémy.

Zvažte například SSL FalseStart . Jedná se hlavně o to, aby klient odesílal data své aplikace hned po odeslání své zprávy Finished (v úplném podání ruky), bez čekání na Finished zpráva ze serveru. To snižuje latenci, což je dobré a dobře míněné. Mění to však bezpečnostní situaci: před přijetím zprávy Finished ze serveru je tato pouze implicitně ověřena (klient zatím nemá žádný důkaz, že zamýšlený server byl skutečně zapojen vše; jen ví, že vše, co pošle, bude čitelné pouze pro zamýšlený server). To může mít dopady; útočník by například mohl emulovat server až do tohoto bodu a přinutit klienta, aby použil šifrovací sadu založenou na CBC nebo kompresi TLS. Pokud tedy klient implementuje FalseStart, snižuje to účinnost ochranných opatření proti BEAST a CRIME, jak by to jinak mohl server vynutit.

(Google zakázal FalseStart letos na jaře, zjevně kvůli problémům s kompatibilitou s některými servery. Mimochodem, „30% snížení latence“ vypadalo divně, protože FalseStart by měl nějaký vliv pouze na úplné handshakes, ne zkrácené handshakes, takže ne “ Nevěřím v tyto údajné výhody; alespoň v takovém rozsahu.)

Komentáře

• Množství úsilí vynaloženého na poskytování dobrých informací prostřednictvím tento web je opravdu šílený a mimořádně obdivuhodný. Velmi si toho vážím.
• Viz také tools.ietf.org / html / rfc7457