Práve sa objavili správy, že spoločnosti Apple, Cloudflare, Fastly a Mozilla spolupracujú na zdokonalení šifrovania mechanizmu identifikácie serverových mien HTTPS na IETF 102 Hackathon, ako naznačuje tweet Nicka Sullivana z Cloudflare. Tento tweet zagratuloval mixovému tímu štyroch technologických gigantov slovami „Úžasná práca“ a zdieľaním pod odkazmi na pracovné servery na esni.examp1e.net a cloudflare-esni.com .
Úžasná práca na hackathon IETF 102 šifrovaným tímom SNI pozostávajúcim z ľudí z @Cloudflare @rýchlo @mozilla a @jablko . Teraz existujú implementácie v programoch BoringSSL, NSS a picotls.
Pracovné servery sú aktívne https://t.co/sLI9xLRjlK a https://t.co/AoC2SIlJ7N .
- Nick Sullivan (@grittygrease) 15. júla 2018
IETF Hackathon je platforma, ktorá pozýva mladých vývojárov a technologických nadšencov, aby sa pripojili k hlavám pri navrhovaní riešení problémov týkajúcich sa technológií, ktorým dnes čelí bežný používateľ. Podujatia sa môžu bezplatne pripojiť, sú otvorené pre všetkých a na rozdiel od konkurencie povzbudzujú tímovú prácu. Tohtoročný IETF Hackathon sa konal v Montreale 14. dňatha 15thjúla. Najvýznamnejším úspechom, ktorý z toho vzišiel, je, zdá sa, šifrovanie protokolu Transport Layer Security (TLS) Server Name Indication (SNI), čo je problém, ktorý sužuje vývojárov za posledné desaťročie a ktorý je členmi spoločností Apple, Cloudflare, Fastly a Mozilla teraz navrhli riešenie pre.
Udalosť IETF Hackathon. IETF
V poslednom desaťročí došlo k jasnému globálnemu posunu od protokolu Hyper Text Transfer Protocol (HTTP) k označeniu názvu transportného bezpečnostného servera Hyper Text Transfer Protocol Secure (TLS SNI HTTPS). The problém z optimalizácie systému TLS SNI HTTPS vyplynula schopnosť hackera použiť SNI proti jeho účelu na porovnanie prenosu dát s cieľom neskoršieho dešifrovania.
Pred vývojom SNI bolo ťažké nadviazať bezpečné spojenia s viacerými virtuálnymi servermi pomocou rovnakého prvého spojenia klientov. Keď jedna IP adresa interagovala s jedným serverom, dvaja si vymenili „ahoj“, server poslal svoje certifikáty, počítač poslal svoj klientský kľúč, dva si vymenili príkazy „ChangeCipherSpec“ a potom sa interakcia skončila, keď sa nadviazalo spojenie. Môže to znieť ľahko, ako sa to práve hovorilo, ale tento proces zahŕňal viac výmen a odpovedí, ktoré sa pri zvyšovaní počtu serverov, s ktorými sa ľahko komunikuje, ľahko dostali do problémov. Ak všetky weby používali rovnaké certifikáty, nebol to veľký problém, ale bohužiaľ to tak bolo zriedka. Keď viaceré weby posielali rôzne certifikáty tam a späť, pre server bolo ťažké určiť, ktorý certifikát počítač hľadal, a v zložitej sieti výmen bolo ťažké určiť, kto čo a kedy poslal, čím sa ukončila celá činnosť. s varovnou správou úplne.
TLS SNI bol potom predstavený v júni 2003 prostredníctvom samitu IETF a účelom, ktorý v istom zmysle slúžil, bolo vytvárať menovky pre počítače a služby zapojené do výmenného webu. Vďaka tomu bol proces výmeny servera a klienta oveľa jednoduchší, pretože server bol schopný poskytnúť potrebné presné certifikáty a títo dvaja boli schopní viesť vlastnú konverzáciu bez toho, aby sa nechali zmiasť tým, kto čo povedal. Je to trochu ako mať kontaktné mená pre chaty, nenechať sa zmiasť, odkiaľ správy pochádzajú, a tiež vedieť odpovedať na každý dotaz primerane a poskytnúť správne dokumenty podľa toho, čo počítač potrebuje. Táto definícia SNI je presne to, čo spôsobilo najväčší problém s touto metódou optimalizácie procesu výmeny.
Bojom mnohých firiem pri prechode na HTTPS bolo prispôsobenie mnohých certifikátov do formátu SNI s individuálnymi IP adresami na vykonávanie požiadaviek na každý certifikát. To, čo pre nich TLS urobil, bolo jednoduchšie generovanie certifikátov, ktoré by odpovedali na tieto žiadosti, a to, čo SNI urobilo ešte viac, bolo odstránenie potreby individualizovaných vyhradených IP adries certifikátov zavedením celého identifikačného systému do celej siete internetu. S upgradom storočia prišla skutočnosť, že hackerom umožnila používať zavedené „mená kontaktov“ na sledovanie a tieňovanie dátových prenosov a na extrahovanie informácií, ktoré potrebujú na dešifrovanie v neskoršej fáze.
Aj keď protokol TLS umožňoval odosielanie údajov tam a späť v šifrovanom kanáli, pričom SNI zabezpečoval, že sa dostanú do správneho cieľového miesta, tento server tiež poskytoval hackerom prostriedky na sledovanie online aktivity a jej priradenie k jej zdroju na základe požiadaviek DNS, adries IP a dátové toky. Aj keď boli zavedené prísnejšie pravidlá kódovania SNI aj pri prechode informácií DNS cez kanál TLS, hackerom zostáva malé okno, aby ich mohli použiť ako prostriedok identifikácie na sledovanie informácií, ktoré by chceli extrahovať a izolovať pre dešifrovanie. Komplexné servery, ktoré sa zaoberajú vyššou prevádzkou dát šifrovaných TLS, používajú na odosielanie komunikácie okolo na svojich serveroch prostý textový protokol SNI, čo hackerom uľahčuje identifikáciu kanálov a tokov informácií, ktoré chcú sledovať. Keď je hacker schopný získať informácie SNI z požadovaných údajov, je schopný nastaviť fauxové prehratie príkazu v samostatnom spojení TLS so serverom, odoslať ukradnuté informácie SNI a vyhľadať informácie, ktoré bol s tým spojený. V minulosti sa vyskytlo niekoľko pokusov o vyriešenie tohto problému so SNI, ale väčšina išla proti princípu jednoduchosti, na ktorom SNI pracuje, aby sa stal pohodlnou metódou identifikácie pre servery.
Späť na samit, ktorý ako prvý pracoval na zavedení tejto metódy, sa účastníci zo štyroch technologických gigantov vrátili na konferenciu v Montreale, aby vyvinuli šifrovanie pre TLS SNI, pretože aj napriek vyššej efektivite v susednom systéme s viacerými HTTPS zostáva bezpečnosť stále problémom rovnako ako predtým.
Aby ste skryli SNI v TLS, musí byť „Skrytá služba“ udržiavaná pod prehliadkou „Prednej služby“, ktorú môže hacker vidieť. Bez možnosti priameho sledovania skrytej služby bude hacker pomýlený frontovým maskovaním, pod ktoré sa skrýva v obyčajnom texte, bez toho, aby dokázal identifikovať základné parametre tajnej služby použité na prenos šifrovaných údajov. Keď pozorovateľ sleduje stopu frontingovej služby, údaje budú odstránené zo sledovaného kanálu, pretože sú presmerované na zamýšľanú skrytú službu, v ktorej však hacker stratí stopu. Pretože server bude vystavený aj frontingovej službe, keď sa tam dáta dostanú, bude do frontingovej služby zaslaný druhý paralelný signál SNI, ktorý ich presmeruje na skrytú službu a v tomto smere zmení proces hacker stratí na webe servera. Tento mechanizmus dvojitých lístkov sa ďalej rozvíja do kombinovaného lístka pod rovnakým SNI. Keď sa na server odošle jeden údaj, tieto údaje vytvoria spolupracujúceho redaktora SNI a tieto dva pracujú spoločne, aby dostali šifrované údaje TLS tam, kam treba. Bez toho, aby bol schopný prelomiť službu náhodného frontu, ktorá pokrýva obe stopy SNI, hacker nebude schopný sledovať stopu dát, ale server bude stále schopný tieto dva spojiť a dešifrovať skrytú službu ako konečné miesto údajov. To umožňuje serverom pokračovať v používaní SNI na optimalizáciu ich prenosu dát v šifrovaní TLS a zároveň zaistiť, že hackeri nebudú môcť využívať výhody mechanizmu SNI.
