Tikko parādījās ziņas, ka Apple, Cloudflare, Fastly un Mozilla sadarbojās, uzlabojot HTTPS servera nosaukuma identifikācijas mehānisma šifrēšanu IETF 102 hakatonā, kā norādīts ar Cloudflare Nika Salivana tvītu. Čivināt apsveica jaukto komandu no četriem tehnoloģiju gigantiem, sakot “Awesome work” un daloties tur ar saitēm uz darba serveriem plkst. esni.examp1e.net un cloudflare-esni.com .
Lielisks darbs IETF 102 hakatonā, ko veic šifrētā SNI komanda, kurā ir cilvēki no @Cloudflare @ātri @mozilla un @ ābols . Tagad BoringSSL, NSS un picotls ir ieviesti.
Darba serveri darbojas tiešsaistē https://t.co/sLI9xLRjlK un https://t.co/AoC2SIlJ7N .
- Niks Salivans (@grittygrease) 2018. gada 15. jūlijs
IETF hakatons ir platforma, kas aicina jaunos izstrādātājus un tehnoloģiju entuziastus apvienoties, izstrādājot risinājumus ar tehnoloģiju saistītiem jautājumiem, ar kuriem šodien sastopas kopīgais lietotājs. Pasākumi ir brīvi pievienojami, atvērti visiem, un tie veicina komandas darbu, nevis konkurenci. Šī gada IETF hakatons notika Monreālā 14. datumāthun 15thjūlijam. Šķiet, ka visizcilākais sasniegums no tā ir transporta slāņa drošības (TLS) servera nosaukuma (SNI) šifrēšana, problēma, kas pēdējās desmitgades laikā ir nomocījusi izstrādātājus, kuru Apple, Cloudflare, Fastly dalībnieki , un Mozilla tagad ir piedāvājuši risinājumu.
IETF hakatona pasākums. IETF
Pēdējo pusotras desmitgades laikā ir notikusi skaidra globāla pāreja no hiperteksta pārsūtīšanas protokola (HTTP) uz transporta slāņa drošības servera nosaukuma norādīšanu, droša hiperteksta pārsūtīšanas protokola (TLS SNI HTTPS). The problēmu kas radās, optimizējot TLS SNI HTTPS sistēmu, bija hakera spēja izmantot SNI pret savu mērķi, lai vēlāk datu atšifrēšanai atbilstu.
Pirms SNI izstrādes bija grūti izveidot drošus savienojumus ar vairākiem virtuālajiem serveriem, izmantojot to pašu pirmo klienta rokasspiedienu. Kad viena IP adrese mijiedarbojās ar vienu serveri, abi apmainījās ar “hellos”, serveris nosūtīja savus sertifikātus, dators nosūtīja klienta atslēgu, abas apmainījās komandas “ChangeCipherSpec” un pēc tam mijiedarbība tika pabeigta, kad tika izveidots savienojums. Tas var izklausīties vienkārši tā, kā tikko teikts, taču process ietvēra vairākas apmaiņas un atbildes, kuras viegli izdevās iegūt diezgan problemātiski, jo pieauga sazināto serveru skaits. Ja visās vietnēs tika izmantoti vieni un tie paši sertifikāti, tad tā nebija liela problēma, bet diemžēl tas notika reti. Kad vairākas vietnes sūtīja dažādus sertifikātus turp un atpakaļ, serverim bija grūti noteikt, kuru sertifikātu dators meklēja, un sarežģītajā apmaiņas tīmeklī kļuva grūti noteikt, kurš ko un kad sūtīja, tādējādi pārtraucot visu darbību ar brīdinājuma ziņojumu vispār.
Tad TLS SNI tika ieviests 2003. gada jūnijā, rīkojot IETF samitu, un tā mērķis savā ziņā bija izveidot vārda atzīmes datoriem un pakalpojumiem, kas iesaistīti apmaiņas tīmeklī. Tas padarīja servera un klienta sveiciena apmaiņas procesu daudz vienkāršāku, jo serveris varēja sniegt precīzus nepieciešamos sertifikātus, un abiem bija iespēja veikt savu sarunu apmaiņu, neapjukot par to, kas ko teica. Tas ir nedaudz līdzīgi tam, ka jums ir kontaktpersonu vārdi tērzēšanai un neapjukšana par to, no kurienes nāk ziņojumi, kā arī iespēja atbilstoši atbildēt uz katru vaicājumu, nodrošinot pareizos dokumentus katram datoram, kuram tas nepieciešams. Šī SNI definīcija ir tieši tā, kas izraisīja vislielākās problēmas ar šo apmaiņas procesa optimizācijas metodi.
Cīņa, ar kuru saskārās daudzi uzņēmumi, pārejot uz HTTPS, bija daudzu sertifikātu pielāgošana SNI formātam ar individuālām IP adresēm, lai izpildītu katra sertifikāta pieprasījumus. Tas, ko TLS viņiem darīja, bija vienkāršot sertifikātu ģenerēšanu, lai atbildētu uz šādiem pieprasījumiem, un SNI vēl vairāk novērsa nepieciešamību pēc individualizētām īpašām sertifikātu IP adresēm, iemetot visu identifikācijas sistēmu visā interneta tīklā. Gadsimta jauninājums bija fakts, ka tas ļāva hakeriem izmantot izveidotos “kontaktu vārdus”, lai uzraudzītu un ēnotu datu pārsūtīšanu un vēlāk iegūtu atšifrēšanai nepieciešamo informāciju.
Lai gan TLS ļāva sūtīt datus turp un atpakaļ šifrētā kanālā, SNI nodrošinot, ka tas sasniedz pareizo galamērķi, pēdējais arī nodrošināja hakeriem līdzekļus, lai uzraudzītu tiešsaistes aktivitātes un pieskaņotu to savam avotam, sekojot DNS pieprasījumiem, IP adresēm. un datu plūsmas. Lai gan stingrākas SNI kodēšanas politikas ir ieviestas, DNS informāciju nododot arī caur TLS kanālu, hakeriem paliek neliels logs, lai varētu to izmantot kā identifikācijas līdzekli, lai sekotu informācijai, kuru viņi vēlētos to iegūt un izolēt atšifrēšana. Kompleksie serveri, kas nodarbojas ar lielāku TLS šifrētu datu plūsmu, izmanto vienkārša teksta SNI, lai nosūtītu saziņu savos serveros, un tas ļauj hakeriem vieglāk noteikt kanālus un informācijas plūsmas, kurām viņi vēlas sekot. Kad hakeris ir spējīgs iegūt SNI informāciju par interesējošajiem datiem, viņš / viņa var iestatīt komandas mākslīgo atkārtojumu atsevišķā TLS savienojumā ar serveri, nosūtot nozagto SNI informāciju un izgūstot informāciju, kas bija saistīts ar to. Iepriekš ir bijuši vairāki mēģinājumi atrisināt šo SNI problēmu, taču lielākā daļa ir pretrunā ar SNI darbības vienkāršības principu, lai padarītu to par ērtu serveru identifikācijas metodi.
Atgriežoties pie augstākā līmeņa sanāksmes, kurā vispirms tika izveidota šī metode, dalībnieki no četriem tehnoloģiju gigantiem ir atgriezušies konferencē Monreālā, lai izstrādātu TLS SNI šifrēšanu, jo, neskatoties uz lielo efektivitāti daudzās HTTPS blakus esošajā sistēmā, drošība joprojām ir problēma tikpat daudz kā agrāk.
Lai slēptu SNI TLS, ir jāsaglabā “Slēptais pakalpojums” zem “Fronting Service”, kuru var redzēt hakeris. Nespējot tieši novērot slēpto servisu, hakeris tiks maldināts ar frontinga maskējumu, ar kuru tas slēpjas vienkāršā tekstā, nespējot identificēt pamatā esošos slepenā dienesta parametrus, ko izmanto šifrēto datu pārsūtīšanai. Kad novērotājs seko frontēšanas pakalpojuma takai, dati tiks noņemti no novērotā kanāla, jo tie tiks novirzīti uz paredzēto slēpto pakalpojumu, kurā hakeris būs zaudējis savu ceļu. Tā kā serveris būs pakļauts arī frontēšanas pakalpojumam, kad dati tur nokļūs, priekšapgādes dienestam tiks nosūtīts otrais paralēlais SNI signāls, lai novirzītu datus uz slēpto pakalpojumu un šajā virzienā mainītu procesu, hakeris var pazust servera tīmeklī. Šis dubultbiļešu mehānisms tiek tālāk izstrādāts par kombinēto biļeti tajā pašā SNI. Kad viens datu gabals tiek nosūtīts uz serveri, dati izveido sadarbības SNI pārdirektoru un abi strādā kopā, lai TLS šifrētos datus nogādātu tur, kur tiem jāiet. Nespējot uzlauzt randomizēto priekšgala pakalpojumu, kas aptver abas SNI dziesmas, hakeris nevarēs sekot datu pēdām, taču serveris joprojām varēs savienot abus un atšifrēt slēpto pakalpojumu kā datu galīgo atrašanās vietu. Tas ļauj serveriem turpināt izmantot SNI, lai optimizētu datu pārsūtīšanu TLS šifrēšanā, vienlaikus nodrošinot, ka hakeri nevar izmantot SNI mehānisma priekšrocības.
