La esenco de kio okazis
En majo 2020, grupo de elirnodoj estis malkovrita enmiksiĝi kun eksiĝintaj ligoj. Aparte, ili lasis preskaŭ ĉiujn ligojn nerompitaj, sed kaptis ligojn al malgranda nombro da kriptaj interŝanĝoj. Se uzantoj vizitis la HTTP-version de la retejo (t.e., neĉifrita kaj neaŭtentikigita), malicaj gastigantoj estis malhelpitaj redirekti al la HTTPS-versio (t.e., ĉifrita kaj aŭtentikigita). Se la uzanto ne rimarkis la anstataŭigon (ekzemple, la foresto de seruro-ikono en la retumilo) kaj komencis plusendi gravajn informojn, ĉi tiun informon povus esti kaptita de la atakanto.
La projekto Tor ekskludis ĉi tiujn nodojn de la reto en majo 2020. En julio 2020, alia grupo de relajsoj estis malkovrita farante similan atakon, post kiu ili ankaŭ estis ekskluditaj. Ankoraŭ ne klaras, ĉu iuj uzantoj estis sukcese atakitaj, sed surbaze de la skalo de la atako kaj la fakto, ke la atakanto denove provis (la unua atako influis 23% de la totala trafluo de la eligo-nodoj, la dua proksimume 19%), estas akcepteble supozi ke ke la atakanto konsideris la koston de la atako pravigita.
Ĉi tiu okazaĵo estas bona memorigilo, ke HTTP-petoj estas neĉifritaj kaj neaŭtentikigitaj kaj tial daŭre estas vundeblaj. Tor Browser venas kun HTTPS-Everywhere etendo specife desegnita por malhelpi tiajn atakojn, sed ĝia efikeco estas limigita de listo, kiu ne kovras ĉiun retejon en la mondo. Uzantoj ĉiam riskos vizitante la HTTP-version de retejoj.
Malhelpi similajn atakojn en la estonteco
Metodoj por malhelpi atakojn estas dividitaj en du partojn: la unua inkluzivas mezurojn, kiujn uzantoj kaj administrantoj de retejoj povas preni por plifortigi sian sekurecon, dum la dua koncernas la identigon kaj ĝustatempan detekton de malicaj retaj nodoj.
Rekomenditaj agoj flanke de retejoj:
1. Ebligu HTTPS (senpagaj atestiloj estas provizitaj de Lasita-a Kryri)
2. Aldonu alidirektajn regulojn al la listo HTTPS-Everywhere por ke uzantoj povu iniciateme establi sekuran konekton prefere ol fidi je alidirekto post establi nesekuran konekton. Krome, se la administrado de retservoj volas tute eviti interagadon kun elirnodoj, ĝi povas provizi cepo-version de la retejo.
La Tor Projekto nuntempe pripensas tute malŝalti nesekuran HTTP en la Tor-Retumilo. Antaŭ kelkaj jaroj, tia mezuro estus nepensebla (tro multaj rimedoj havis nur nesekurigitan HTTP), sed HTTPS-Everywhere kaj la venonta versio de Fajrovulpo havas eksperimentan opcion uzi HTTPS defaŭlte por la unua konekto, kun la kapablo por reiru al HTTP se necese. Ankoraŭ ne klaras, kiel ĉi tiu aliro influos uzantojn de Tor-Retumilo, do ĝi unue estos provita ĉe pli altaj sekurecaj niveloj de la retumilo (ŝildikono).
La Tor-reto havas volontulojn monitorantajn relajsan konduton kaj raportantajn okazaĵojn por ke malicaj nodoj estu ekskluditaj de radikaj dosierserviloj. Kvankam tiaj raportoj estas kutime traktitaj rapide kaj malicaj nodoj estas prenitaj eksterrete tuj post detekto, ekzistas nesufiĉaj rimedoj por konstante monitori la reton. Se vi sukcesas detekti malican relajson, vi povas raporti ĝin al la projekto, instrukcioj disponebla ĉe ĉi tiu ligilo.
La nuna aliro havas du fundamentajn problemojn:
1. Konsiderante nekonatan stafetadon, estas malfacile pruvi ĝian malicecon. Se ne estus atakoj de li, ĉu li estu lasita surloke? Amasaj atakoj, kiuj influas multajn uzantojn, estas pli facile detekteblaj, sed se atakoj influas nur malgrandan nombron da retejoj kaj uzantoj, la atakanto povas agi proaktive. La reto Tor mem konsistas el miloj da relajsoj situantaj tra la mondo, kaj ĉi tiu diverseco (kaj la rezulta malcentralizo) estas unu el ĝiaj fortoj.
2. Konsiderante grupon de nekonataj ripetiloj, estas malfacile pruvi ilian interkonekton (t.e., ĉu ili kondukas La atako de Sibyl). Multaj libervolaj stafet-funkciigistoj elektas la samajn malmultekostajn retojn por gastigi, kiel Hetzner, OVH, Online, Frantech, Leaseweb, ktp., kaj se oni malkovros plurajn novajn relajsojn, ne estos facile definitive diveni ĉu ekzistas pluraj novaj. funkciigistoj aŭ nur unu, kontrolante ĉiujn novajn ripetilojn.
fonto: linux.org.ru