Soluția Apple, Cloudflare, Fastly și Mozilla creează criptarea SNI

Știri
Securitate / Soluția Apple, Cloudflare, Fastly și Mozilla creează criptarea SNI 5 minute citite

Tocmai a apărut știrea că Apple, Cloudflare, Fastly și Mozilla au colaborat la îmbunătățirea criptării mecanismului de identificare a numelui serverului HTTPS la IETF 102 Hackathon, așa cum este indicat de un tweet de la Nick Sullivan din Cloudflare. Tweetul a felicitat echipa mix din cei patru giganți tehnologici spunând „Muncă minunată” și partajând acolo sub linkuri către serverele de lucru de la esni.examp1e.net și cloudflare-esni.com .



Hacketonul IETF este o platformă care invită tinerii dezvoltatori și pasionații de tehnologie să se alăture în elaborarea soluțiilor pentru problemele legate de tehnologie cu care se confruntă astăzi utilizatorul comun. Evenimentele sunt libere să se alăture, deschise tuturor și încurajează munca în echipă, nu competiția. Hacketonul IETF din acest an a avut loc la Montreal pe 14ași 15adin iulie. Cea mai proeminentă realizare care a ieșit din ea, se pare, este criptarea indicației de nume de server (TLS) Server Name Indication (SNI), o problemă care a afectat dezvoltatorii în ultimul deceniu, una pe care membrii Apple, Cloudflare, Fastly , și Mozilla au propus acum o soluție pentru.



Eveniment IETF Hackathon. IETF

În ultimul deceniu și jumătate, a existat o schimbare globală clară de la Protocolul de transfer de text hiper (HTTP) la Indicatorul de nume al serverului de securitate a stratului de transport (Hyper Text Transfer Protocol Secure - TLS SNI HTTPS). problemă care a rezultat din optimizarea sistemului TLS SNI HTTPS a fost capacitatea hackerului de a utiliza SNI împotriva scopului său de a potrivi transferul de date pentru decriptare ulterior.

de ce telefonul meu spune numai apeluri de urgență

Înainte de dezvoltarea SNI, a fost dificil să se stabilească conexiuni sigure la mai multe servere virtuale folosind același prim handshake client. Când o adresă IP a interacționat cu un server, cei doi au schimbat „salut”, serverul și-a trimis certificatele, computerul și-a trimis cheia de client, cei doi au schimbat comenzile „ChangeCipherSpec” și apoi interacțiunea a fost finalizată pe măsură ce s-a stabilit o conexiune. Acest lucru poate suna ușor așa cum s-a spus, dar procesul a implicat mai multe schimburi și răspunsuri, care au reușit cu ușurință să devină destul de problematice, pe măsură ce numărul de servere cu care se comunică a crescut. Dacă toate site-urile foloseau aceleași certificate, atunci aceasta nu era o problemă prea mare, dar din păcate acest lucru a fost rar cazul. Când mai multe site-uri trimiteau diferite certificate înainte și înapoi, a fost dificil pentru server să determine ce certificat căuta computerul și în rețeaua complexă de schimburi, a devenit dificil să se identifice cine a trimis ce și când, terminând astfel întreaga activitate cu un mesaj de avertizare cu totul.



TLS SNI a fost apoi introdus în iunie 2003 printr-un summit IETF și scopul pe care l-a servit, într-un anumit sens, a fost să creeze etichete de nume pentru computerele și serviciile implicate în web-ul de schimb. Acest lucru a făcut ca procesul de schimb de serviciu client să fie mult mai simplu, deoarece serverul a fost capabil să furnizeze certificatele exacte necesare, iar cei doi au fost capabili să aibă propriul schimb de conversații fără a se confunda cu cine a spus ce. Este puțin ca să ai nume de contacte pentru chaturi și să nu te confunzi de unde provin mesajele și, de asemenea, să poți răspunde în mod corespunzător la fiecare interogare, oferind documentele potrivite oricărui computer care are nevoie. Această definiție SNI este exact ceea ce a determinat cea mai mare problemă cu această metodă de optimizare a procesului de schimb.

Lupta cu care s-au confruntat multe companii în trecerea la HTTPS a fost adaptarea multor certificate la formatul SNI cu adrese IP individuale pentru a efectua cereri pentru fiecare certificat. Ceea ce TLS a făcut pentru ei a fost să simplifice generarea de certificate pentru a răspunde la astfel de solicitări și ceea ce SNI a făcut și mai mult a fost să elimine necesitatea adreselor IP de certificat dedicate individualizate prin aruncarea unui întreg sistem de identificare în întreaga rețea de internet. Ceea ce a venit odată cu actualizarea secolului a fost faptul că le-a permis hackerilor să folosească „numele de contact” stabilite pentru a monitoriza și ascunde transferul de date și a extrage informațiile de care au nevoie pentru a decripta într-o etapă ulterioară.

Deși TLS a permis ca datele să fie trimise înainte și înapoi într-un canal criptat, SNI asigurându-se că ajunge la destinația corectă, acesta din urmă a oferit și mijloacelor pentru ca hackerii să monitorizeze activitatea online și să o potrivească cu sursa sa, urmând cereri DNS, adrese IP și fluxuri de date. Deși au fost implementate politici de codare SNI mai stricte prin transmiterea informațiilor DNS și prin canalul TLS, rămâne o fereastră mică pentru ca hackerii să poată utiliza acest lucru ca mijloc de identificare pentru a urmări informația pe care ar dori să o extragă și să o izoleze pentru decriptare. Serverele complexe care se ocupă de un trafic mai mare de date criptate TLS folosesc text simplu SNI pentru a trimite comunicarea în jurul serverelor lor și acest lucru face ca hackerii să identifice mai ușor canalele și fluxurile de informații pe care doresc să le urmeze. Odată ce un hacker este capabil să extragă informațiile SNI ale datelor de interes, este capabil să configureze o redare falsă a comenzii într-o conexiune TLS separată cu serverul, trimitând informațiile SNI furate și recuperând informațiile care a fost asociat cu acesta. Au existat mai multe încercări de a rezolva această problemă SNI în trecut, dar majoritatea s-au opus principiului simplității pe care SNI operează pentru a face din aceasta o metodă de identificare convenabilă pentru servere.

Înapoi la summit-ul care a lucrat pentru prima dată la stabilirea acestei metode, participanții din patru giganți tehnologici s-au întors la conferința de la Montreal pentru a dezvolta o criptare pentru TLS SNI, deoarece, în ciuda eficienței mai mari a sistemului adiacent multi HTTPS, securitatea rămâne încă o preocupare doar la fel de mult ca înainte.

Pentru a ascunde SNI în TLS, un „Serviciu ascuns” trebuie păstrat sub spectacolul unui „Serviciu de frontare” pe care hackerul îl poate vedea. Fără a putea observa în mod direct serviciul ascuns, hackerul va fi înșelat de deghizarea frontală pe care o ascunde în text simplu, fără a putea identifica parametrii subiacenți ai serviciului secret utilizați pentru transmiterea datelor criptate. Pe măsură ce observatorul urmărește urmele serviciului de fronting, datele vor fi eliminate din canalul observat pe măsură ce sunt redirecționate către serviciul ascuns intenționat, moment în care hackerul și-a pierdut urmele. Deoarece serverul va fi, de asemenea, expus serviciului de fronting, pe măsură ce datele își fac drum acolo, un al doilea semnal SNI paralel va fi trimis către serviciul de fronting pentru a redirecționa datele către serviciul ascuns și în acest proces de schimbare a direcției, hackerul va să fie pierdut pe web-ul serverului. Acest mecanism al biletelor duble este dezvoltat în continuare într-un bilet combinat sub același SNI. Pe măsură ce o bucată de date este trimisă în server, datele produc un re-director SNI care cooperează și cele două funcționează împreună pentru a obține datele criptate TLS unde trebuie să ajungă. Fără a putea sparge serviciul de fronting randomizat care acoperă ambele piste SNI, hackerul nu va putea urmări urmele datelor, dar serverul va putea totuși să le conecteze pe cele două și să decripteze serviciul ascuns ca locație finală a datelor. Acest lucru permite serverelor să continue să utilizeze SNI pentru a-și optimiza transferul de date în criptare TLS, asigurându-se în același timp că hackerii nu pot profita de mecanismul SNI.