A napokban jelentek meg hírek arról, hogy az Apple, a Cloudflare, a Fastly és a Mozilla együttműködtek a HTTPS kiszolgálónév-azonosító mechanizmusának titkosításának fejlesztésében az IETF 102 Hackathonon, amint azt a Cloudflare Nick Sullivanjának tweetje jelzi. A tweet gratulált a négy technikai óriás vegyes csapatának azzal, hogy „Félelmetes munka” -ot mondott, és ott megosztotta a linkeket a működő szerverekhez a esni.examp1e.net és cloudflare-esni.com .
Félelmetes munka az IETF 102 hackathonon a titkosított SNI csapat részéről, amelynek tagjai: @Cloudflare @gyorsan @mozilla és @alma . Most megvalósítások vannak a BoringSSL-ben, az NSS-ben és a picotls-ban.
A működő szerverek élnek https://t.co/sLI9xLRjlK és https://t.co/AoC2SIlJ7N .
- Nick Sullivan (@grittygrease) 2018. július 15
Az IETF Hackathon egy olyan platform, amely felhívja a fiatal fejlesztőket és a technikák rajongóit, hogy egyesítsék a fejüket a technikával kapcsolatos problémák megoldások kidolgozásában, amelyekkel a közös felhasználó szembesül. Az események szabadon csatlakozhatnak, mindenki számára nyitottak, és a verseny helyett a csapatmunkára ösztönzik. Az idei IETF Hackathont Montrealban rendezték 14-énthés 15thjúlius. Úgy tűnik, hogy a legkiemelkedőbb eredmény a Transport Layer Security (TLS) kiszolgálónév-jelzés (SNI) titkosítása, ez a probléma az elmúlt évtizedben sújtotta a fejlesztőket, amely az Apple, a Cloudflare, a Fastly tagjai , és a Mozilla most megoldást javasolt.
IETF Hackathon esemény. IETF
Az elmúlt másfél évtizedben egyértelmű globális váltás történt a Hyper Text Transfer Protocol (HTTP) és a Transport Layer Security Server kiszolgálónév jelzése és a Hyper Text Transfer Protocol Secure (TLS SNI HTTPS) között. A probléma ami a TLS SNI HTTPS rendszerének optimalizálásából származott, az volt a hacker azon képessége, hogy az SNI-t rendeltetésének ellenére használja az adatátvitel későbbi dekódolásához.
Az SNI fejlesztése előtt nehéz volt biztonságos kapcsolatot létesíteni több virtuális kiszolgálóval ugyanazzal az első kliens kézfogással. Amikor egy IP-cím kölcsönhatásba lépett egy szerverrel, a kettő kicserélte a „hellókat”, a szerver elküldte a tanúsítványait, a számítógép elküldte az ügyfélkulcsát, a kettő kicserélte a „ChangeCipherSpec” parancsokat, majd a kapcsolat létrejöttével befejeződött az interakció. Ez ugyanolyan egyszerűnek tűnhet, mint az imént mondták, de a folyamat többféle cserét és választ igényelt, amelyek könnyen problémássá váltak, mivel nőtt a kiszolgálók száma. Ha az összes webhely ugyanazt a tanúsítványt használta, akkor ez nem okozott nagy problémát, de sajnos ez ritkán fordult elő. Amikor több webhely küldött oda-vissza különféle tanúsítványokat, a kiszolgálónak nehéz volt meghatároznia, hogy a számítógép mely tanúsítványt keresi, és a cserék bonyolult webén nehézkessé vált annak azonosítása, hogy ki mit és mikor küldött, ezáltal megszüntette az egész tevékenységet figyelmeztető üzenettel.
A TLS SNI-t ezután 2003 júniusában vezették be az IETF csúcstalálkozóján, amelynek célja bizonyos értelemben névcímkék létrehozása volt a csere-weben részt vevő számítógépek és szolgáltatások számára. Ez sokkal egyszerűbbé tette a szerver-kliens hello cserefolyamatot, mivel a szerver képes volt a pontos tanúsítványok megadására, és mindketten saját beszélgetést folytathattak anélkül, hogy összezavarodtak volna, hogy ki mit mondott. Kicsit olyan, mintha a kapcsolattartók neve lenne a csevegésekhez, és nem lennénk összezavarodva abban, hogy honnan származnak az üzenetek, és azt is, hogy megfelelően tudunk válaszolni az egyes lekérdezésekre, megfelelő dokumentumokat nyújtva be annak, amelyiknek szüksége van rá. Pontosan ez az SNI-definíció okozta a legnagyobb problémát a cserefolyamat optimalizálásának ezen módszerével.
Sok vállalatnak a HTTPS-re való áttérés során felmerült küzdelme az volt, hogy sok tanúsítványt az SNI formátumhoz igazítottak egyedi IP címmel az egyes tanúsítványok iránti kérelmek teljesítése érdekében. Amit a TLS tett számukra, az egyszerűbbé tette a tanúsítványok létrehozását az ilyen kérések megválaszolására, és amit az SNI még tovább tett, az az volt, hogy megszüntette az egyénre szabott dedikált tanúsítvány IP-címek szükségességét azzal, hogy egy teljes azonosító rendszert dobott be az internet teljes hálózatába. Az évszázad frissítésével az a tény lépett fel, hogy ez lehetővé tette a hackerek számára, hogy a létrehozott „kapcsolattartó neveket” használják az adatátvitel figyelemmel kísérésére és árnyékolására, valamint a későbbiekben a visszafejtéshez szükséges információk kinyerésére.
Noha a TLS lehetővé tette az adatok oda-vissza küldését egy titkosított csatornán, az SNI biztosította, hogy az eljusson a megfelelő célhoz, ez utóbbi lehetőséget biztosított a hackerek számára az online tevékenységek figyelemmel kísérésére és a forráshoz való megfelelésre DNS-kérések, IP-címek követésével. és adatfolyamok. Noha szigorúbb SNI-kódolási irányelveket hajtottak végre a DNS-adatok TLS csatornán keresztül történő továbbításával, egy kis ablak marad a hackerek számára, hogy ezt azonosítási eszközként használhassák, hogy kövessék azokat az információkat, amelyekhez kivonják és elkülönítik őket. visszafejtés. A TLS titkosított adatok nagyobb forgalmával foglalkozó komplex szerverek egyszerű szöveges SNI-t használnak a kommunikáció kiszolgálóikon történő küldésére, és ez megkönnyíti a hackerek számára a követni kívánt csatornák és információfolyamok azonosítását. Miután egy hacker képes kinyerni az érdekes adatok SNI-információit, képes a parancs faux visszajátszását egy külön TLS-kapcsolaton keresztül a szerverrel beállítani, elküldve az ellopott SNI-információkat és visszakeresve azokat az információkat, amelyek társult hozzá. Korábban már többször is megpróbálták megoldani ezt az SNI-problémát, de a legtöbb ellentmondott annak az egyszerűségnek az elvével, amelyet az SNI működtet, hogy ez egy kényelmes azonosítási módszer legyen a szerverek számára.
Visszatérve a csúcstalálkozóra, amely először a módszer megalkotásán dolgozott, négy technológiai óriás résztvevői visszatértek a montreali konferenciára, hogy kifejlesszék a TLS SNI titkosítását, mert a multi-HTTPS szomszédos rendszer nagy hatékonysága ellenére a biztonság továbbra is csak aggodalomra ad okot annyit, mint azelőtt.
Az SNI elrejtéséhez a TLS-ben egy „Rejtett szolgáltatást” kell tartani a „Fronting Service” show-ja alatt, amelyet a hacker láthat. Anélkül, hogy közvetlenül meg tudná figyelni a rejtett szolgáltatást, a hackert félrevezeti a homlokzati álcázás, amelyet egyszerű szövegben rejteget, anélkül, hogy képes lenne azonosítani a titkosított szolgáltatások továbbítására használt mögöttes titkosszolgálati paramétereket. Mivel a megfigyelő a fronting szolgáltatás nyomvonalát követi, az adatok eltávolításra kerülnek a megfigyelt csatornáról, amikor átirányítják a tervezett rejtett szolgáltatásra, amikor a hacker elveszíti nyomát. Mivel a kiszolgáló is ki lesz téve a fronting szolgáltatásnak, amint az adatok odaérnek, egy második párhuzamos SNI jelet küldünk a fronting szolgáltatásnak, hogy az adatokat a rejtett szolgáltatás felé irányítsa, és ebben az irányban változó folyamatban, a hacker elvesznek a szerver webén. A kettős jegyek ezen mechanizmusát tovább fejlesztik kombinált jegyként ugyanazon SNI keretében. Amint egy adatot elküld a szerverre, az adatok létrehozzák az együttműködő SNI újrarendezőt, és a kettő együtt dolgozik annak érdekében, hogy a TLS által titkosított adatok oda kerüljenek, ahova kell. Anélkül, hogy feltörné a randomizált fronting szolgáltatást, amely mindkét SNI-sávot lefedi, a hacker nem tudja követni az adatok nyomát, de a szerver továbbra is képes összekapcsolni a kettőt, és visszafejteni a rejtett szolgáltatást, mint az adatok végső helyét. Ez lehetővé teszi a szerverek számára, hogy továbbra is használják az SNI-t az adatátvitel optimalizálásához a TLS-titkosításban, miközben biztosítják, hogy a hackerek ne tudják kihasználni az SNI-mechanizmus előnyeit.
