Uutiset ovat juuri ilmestyneet, että Apple, Cloudflare, Fastly ja Mozilla ovat tehneet yhteistyötä HTTPS: n palvelimen nimen tunnistamismekanismin salauksen parantamiseksi IETF 102 Hackathonissa, kuten Cloudflaren Nick Sullivanin twiitti osoittaa. Twitter twiitti onnitteli neljän teknisen jättiläisen sekoitusryhmää sanomalla ”Mahtavaa työtä” ja jakamalla siellä linkkejä toimiville palvelimille osoitteessa esni.examp1e.net ja cloudflare-esni.com .
Mahtavaa työtä salatun SNI-tiimin IETF 102 -hackathonilla @Cloudflare @ nopeasti @mozilla ja @omena . BoringSSL: ssä, NSS: ssä ja picotlsissa on nyt toteutuksia.
Toimivat palvelimet ovat käytössä osoitteessa https://t.co/sLI9xLRjlK ja https://t.co/AoC2SIlJ7N .
- Nick Sullivan (@grittygrease) 15. heinäkuuta 2018
IETF Hackathon on foorumi, joka kutsuu nuoria kehittäjiä ja tekniikan harrastajia yhdistämään päätään laatimaan ratkaisuja tekniikkaan liittyviin ongelmiin, joita tavallinen käyttäjä on tänään kohdannut. Tapahtumat ovat vapaita liittymään, avoimia kaikille, ja ne kannustavat ryhmätyöhön kilpailun sijaan. Tämän vuoden IETF Hackathon pidettiin Montrealissa 14. päiväthja 15thheinäkuussa. Näyttää siltä, että merkittävin saavutus siitä on Transport Layer Security (TLS) -palvelimen nimen indikaation (SNI) salaus, ongelma, joka on vaivannut kehittäjiä viimeisen vuosikymmenen aikana. Apple, Cloudflare, Fastly , ja Mozilla ovat nyt ehdottaneet ratkaisua.
IETF Hackathon -tapahtuma. IETF
Hyper Text Transfer Protocol (HTTP) -palvelusta Transport Layer Security Server -palvelimen nimen indikaatioon Hyper Text Transfer Protocol Secure (TLS SNI HTTPS) on ollut selkeä maailmanlaajuinen siirtyminen viimeisen puolentoista vuosikymmenen aikana. ongelma TLS SNI: n optimoinnista HTTPS-järjestelmän myötä hakkerin kyky käyttää SNI: tä tarkoitukseensa vastaamaan tiedonsiirtoa salauksen purkamiseksi myöhemmin.
Ennen SNI: n kehittämistä oli vaikea luoda suojattuja yhteyksiä useisiin virtuaalipalvelimiin samalla asiakkaan kädenpuristuksella. Kun yksi IP-osoite oli vuorovaikutuksessa yhden palvelimen kanssa, molemmat vaihtivat 'helloja', palvelin lähetti varmenteensa, tietokone lähetti asiakasavaimensa, kaksi vaihdettua 'ChangeCipherSpec' -komentoa ja sitten vuorovaikutus valmistui, kun yhteys muodostettiin. Tämä saattaa kuulostaa helposti samalla tavalla kuin juuri sanottiin, mutta prosessiin liittyi useita vaihtoja ja vastauksia, jotka onnistuivat helposti muodostamaan melko ongelmallisiksi, kun palvelimien, joihin kommunikoidaan, määrä kasvoi. Jos kaikki sivustot käyttivät samoja varmenteita, tämä ei ollut suuri ongelma, mutta valitettavasti näin oli harvoin. Kun useat sivustot lähettivät erilaisia varmenteita edestakaisin, palvelimen oli vaikea määrittää, mitä varmenteita tietokone etsii, ja monimutkaisessa vaihto-verkossa oli vaikeaa tunnistaa kuka mitä lähetti ja milloin, mikä lopetti koko toiminnan varoitusviestillä.
TLS SNI esiteltiin sitten kesäkuussa 2003 IETF-huippukokouksessa, ja sen tarkoitus oli tavallaan luoda nimilappuja vaihto-verkkoon kuuluville tietokoneille ja palveluille. Tämä teki palvelimen ja asiakkaan tervehdysprosessista paljon suoraviivaisemman, kun palvelin pystyi toimittamaan tarvittavat varmenteet ja molemmat pystyivät käymään oman keskustelunsa ilman sekaannusta siitä, kuka mitä sanoi. Se on vähän kuin yhteystietojen nimet keskusteluille ja sekaannukset siitä, mistä viestit tulevat, ja myös mahdollisuus vastata kuhunkin kyselyyn asianmukaisesti, toimittamalla oikeat asiakirjat mihin tahansa tietokoneeseen sitä tarvitaan. Tämä SNI-määritelmä on juuri se, mikä aiheutti suurimman ongelman tällä menetelmällä optimoida vaihto-prosessi.
Monien yritysten taistelu siirtyessään HTTPS: ään oli monien varmenteiden mukauttaminen SNI-muotoon yksittäisten IP-osoitteiden kanssa kunkin sertifikaatin pyyntöjen suorittamiseksi. Se, mitä TLS teki heidän hyväkseen, oli helpottaa sertifikaattien luomista vastaamaan tällaisiin pyyntöihin, ja SNI teki vielä enemmän poistamalla yksilöllisten erillisten varmenteiden IP-osoitteiden tarpeen heittämällä kokonaisen tunnistusjärjestelmän koko Internet-verkon läpi. Vuosisadan päivityksen mukana oli se, että se antoi hakkereille mahdollisuuden käyttää vakiintuneita 'yhteyshenkilöiden nimiä' seuratakseen ja varjostamaan tiedonsiirtoa ja purkamaan salauksen purkamiseen tarvitsemiaan tietoja myöhemmin.
Vaikka TLS sallii tietojen lähettämisen edestakaisin salatulla kanavalla, SNI: n varmistamalla, että se saavuttaa oikean määränpään, jälkimmäinen tarjosi myös hakkereille keinot seurata verkkotoimintaa ja sovittaa sen lähteeseensä seuraamalla DNS-pyyntöjä, IP-osoitteita ja tietovirrat. Vaikka tiukempia SNI-koodauskäytäntöjä on toteutettu välittämällä DNS-tietoja myös TLS-kanavan kautta, hakkereille jää pieni ikkuna, jotta he voivat käyttää tätä tunnistustapana seuraamaan tietoja, joita he haluavat purkaa ja eristää salauksen purku. Monimutkaiset palvelimet, jotka käsittelevät suurempaa TLS-salattujen tietojen liikennettä, käyttävät yksinkertaisen tekstin SNI: tä lähettämään viestintää palvelimillaan, ja tämä helpottaa hakkereiden tunnistamista haluamansa kanavat ja tietovirrat. Kun hakkeri pystyy poimimaan kiinnostavien tietojen SNI-tiedot, hän pystyy asettamaan komennon faux-toiston erilliseen TLS-yhteyteen palvelimen kanssa, lähettämään varastetut SNI-tiedot ja noutamaan tiedot, jotka liittyi siihen. Tätä SNI-ongelmaa on yritetty ratkaista aikaisemmin useita kertoja, mutta suurin osa niistä on vastoin SNI: n yksinkertaisuusperiaatetta tehdäkseen siitä kätevän tunnistusmenetelmän palvelimille.
Takaisin huippukokoukseen, joka työskenteli ensimmäisen kerran tämän menetelmän luomiseksi, neljän teknisen jättiläisen osallistujat ovat palanneet Montrealissa pidettyyn konferenssiin kehittääkseen salauksen TLS SNI: lle, koska huolimatta HTTPS-vierekkäisen järjestelmän suuresta tehokkuudesta, turvallisuus on edelleen huolestuttavaa yhtä paljon kuin ennen.
SNI: n piilottamiseksi TLS: ssä 'piilotettu palvelu' on pidettävä 'Fronting Service' -alueen alla, jonka hakkeri voi nähdä. Hakkeria ei voida tarkkailla piilotettua palvelua suoraan, ja sen piilotettu peitelevy peittää pelkkää tekstiä ilman, että hän pystyy tunnistamaan salattujen tietojen välittämiseen käytettyjä salaisen palvelun parametreja. Kun tarkkailija seuraa etupalvelun reittiä, data poistetaan havaitulta kanavalta, kun se ohjataan aiottuun piilotettuun palveluun, jolloin hakkeri on menettänyt polunsa. Koska palvelin altistuu myös etupalvelulle, kun data kulkee sinne, lähetetään toinen rinnakkainen SNI-signaali etupalvelulle tietojen uudelleenohjaamiseksi piilotettuun palveluun ja tässä suunnassa muuttuvassa prosessissa kadota palvelimen verkkoon. Tätä kaksinkertaisten lippujen mekanismia kehitetään edelleen yhdistetyksi lipuksi saman SNI: n alla. Kun yksi tieto lähetetään palvelimelle, data tuottaa yhteistyössä toimivan SNI-uudelleenohjaajan ja molemmat toimivat yhdessä saadakseen TLS-salatut tiedot sinne, missä niiden on mentävä. Hakkerit eivät pysty murtamaan satunnaistettua etupalvelua, joka kattaa molemmat SNI-raidat, mutta eivät pysty seuraamaan tietojen jälkiä, mutta palvelin pystyy silti yhdistämään nämä kaksi ja purkamaan piilotetun palvelun tietojen lopulliseksi sijainniksi. Tämä antaa palvelimille mahdollisuuden jatkaa SNI: n käyttöä tiedonsiirron optimoimiseksi TLS-salauksessa varmistaen, että hakkerit eivät pysty hyödyntämään SNI-mekanismia.
