Begin jaren 2010 presenteerde een gezamenlijk team van specialisten van Stanford University, de University of Massachusetts, The Tor Project en SRI International de resultaten van hun onderzoek manieren om censuur op internet te bestrijden.
Wetenschappers analyseerden de methoden om blokkering te omzeilen die op dat moment bestonden en stelden hun eigen methode voor, genaamd flash proxy. Vandaag zullen we het hebben over de essentie en de geschiedenis van ontwikkeling.
Introductie
Het internet begon als een netwerk dat open stond voor alle soorten gegevens, maar na verloop van tijd begonnen veel landen het verkeer te filteren. Sommige staten blokkeren specifieke sites, zoals YouTube of Facebook, terwijl andere de toegang verbieden tot inhoud die bepaald materiaal bevat. Blokkades van een of andere soort worden gebruikt in tientallen landen uit verschillende regio's, waaronder Europa.
Gebruikers in regio's waar blokkering wordt gebruikt, proberen dit te omzeilen met behulp van verschillende proxy's. Er zijn verschillende richtingen voor de ontwikkeling van dergelijke systemen; tijdens het project werd een van de technologieën, Tor, gebruikt.
Meestal worden ontwikkelaars van proxysystemen voor het omzeilen van blokkering geconfronteerd met drie taken die moeten worden opgelost:
- Rendez-vousprotocollen. Met het rendez-vous-protocol kunnen gebruikers in een geblokkeerd land kleine hoeveelheden informatie verzenden en ontvangen om een verbinding met een proxy tot stand te brengen. In het geval van Tor wordt bijvoorbeeld rendez-vous gebruikt om het IP-adres van Tor-relays (bridges) te verspreiden. Dergelijke protocollen worden gebruikt voor verkeer met een lage snelheid en zijn niet zo eenvoudig te blokkeren.
- Een proxy aanmaken. Systemen om blokkering te omzeilen, hebben proxy's buiten de regio met gefilterd internet nodig om verkeer van de client naar de doelbronnen en terug te verzenden. Blokkeerorganisatoren kunnen reageren door te voorkomen dat gebruikers de IP-adressen van proxyservers leren kennen en deze te blokkeren. Om zoiets tegen te gaan de proxyservice moet voortdurend nieuwe proxy's kunnen aanmaken. De snelle creatie van nieuwe proxy's is de belangrijkste essentie van de door de onderzoekers voorgestelde methode.
- Camouflage. Wanneer een client het adres van een niet-geblokkeerde proxy ontvangt, moet hij op de een of andere manier de communicatie daarmee verbergen, zodat de sessie niet kan worden geblokkeerd met behulp van verkeersanalysetools. Het moet gecamoufleerd worden als ‘regulier’ verkeer, zoals gegevensuitwisseling met een webwinkel, online games etc.
In hun werk stelden wetenschappers een nieuwe aanpak voor om snel proxy’s te creëren.
Hoe werkt dit
Het belangrijkste idee is om meerdere websites te gebruiken om een groot aantal proxy's te maken met een korte levensduur van niet meer dan een paar minuten.
Om dit te doen wordt een netwerk van kleine sites gecreëerd die eigendom zijn van vrijwilligers, zoals de homepages van gebruikers die buiten de regio wonen waar internet geblokkeerd is. Deze sites zijn op geen enkele manier geassocieerd met de bronnen waartoe de gebruiker toegang wil hebben.
Op zo’n site wordt een kleine badge geïnstalleerd, een eenvoudige interface die is gemaakt met JavaScript. Een voorbeeld van deze code:
<iframe src="//crypto.stanford.edu/flashproxy/embed.html" width="80" height="15" frameborder="0" scrolling="no"></iframe>Zo ziet het kenteken eruit:
Wanneer een browser vanaf een locatie buiten de geblokkeerde regio een dergelijke site met een badge bereikt, begint deze verkeer naar deze regio en terug te verzenden. Dat wil zeggen dat de browser van de websitebezoeker een tijdelijke proxy wordt. Zodra die gebruiker de site verlaat, wordt de proxy vernietigd zonder enig spoor achter te laten.
Als gevolg hiervan is het mogelijk om voldoende prestaties te verkrijgen om de Tor-tunnel te ondersteunen.
Naast Tor Relay en de client heeft de gebruiker nog drie elementen nodig. De zogenaamde facilitator, die verzoeken van de cliënt ontvangt en deze verbindt met de proxy. Communicatie vindt plaats met behulp van transportplug-ins op de client (hier ) en Tor-relay-switches van WebSockets naar puur TCP.
Een typische sessie waarbij dit schema wordt gebruikt, ziet er als volgt uit:
- De client voert Tor uit, een flash-proxyclient (browserplug-in), en stuurt een registratieverzoek naar de facilitator met behulp van het rendez-vousprotocol. De plug-in begint te luisteren naar de externe verbinding.
- De Flash-proxy verschijnt online en neemt contact op met de facilitator met het verzoek om verbinding te maken met de klant.
- De facilitator retourneert de registratie en geeft de verbindingsgegevens door aan de flash-proxy.
- De proxy maakt verbinding met de client waarvan de gegevens ernaar zijn verzonden.
- De proxy maakt verbinding met de transportplug-in en het Tor-relais en begint gegevens uit te wisselen tussen de client en het relais.
Het bijzondere van deze architectuur is dat de opdrachtgever vooraf nooit precies weet waar hij moet aansluiten. In feite accepteert de transportplug-in alleen een vals bestemmingsadres om de vereisten van transportprotocollen niet te schenden. Dit adres wordt vervolgens genegeerd en er wordt een tunnel gemaakt naar een ander eindpunt: het Tor-relais.
Conclusie
Het flash-proxyproject ontwikkelde zich gedurende meerdere jaren en in 2017 stopten de makers met de ondersteuning ervan. De projectcode is beschikbaar op . Flash-proxy's zijn vervangen door nieuwe tools om blokkering te omzeilen. Eén daarvan is het Snowflake-project, gebouwd op vergelijkbare principes.
Bron: www.habr.com