[c++] Locale proxy server

[Verwijderd]

Gisteren heb ik deze topic al proberen te starten, maar mijn beschijving bleek niet duidelijk genoeg. Dus hier poging 2:

Ik ben bezig met het schrijven van een proxy finder die het internet afspeurt naar proxies. Als je eenmaal een lijst met gevonden proxies hebt, dan kun je een locale proxy server starten door daar dubbel op te klikken. Het zoeken en testen van proxies werkt erg goed. De proxy zelf werkt stukken minder goed. Wanneer ik het internet verkeer van Internet Explorer via deze proxy laat lopen (extra, internet opties, ...knip...) dan worden sommige pagina's niet juist weergegeven. Het uploaden van bestanden naar websites wil ook niet, en ook MSN werkt niet met deze proxy.

Ik vermoed dat alleen een proxy niet voldoende is maar dat ik bv voor het uploaden van bestanden ook een socks server nodig heb. Zeker weten doe ik het niet. Wat ik momenteel doe is alles wat de proxy binnenkrijgt rechtstreeks doorsturen naar het internet, en bij het ontvangen vica versa.

VERWIJDERD

Is er iemand die wat meer ervaring heeft over het schrijven van een (locale) proxy server en mij iets op gang kan helpen? De vraag is wat specifiek, dus mocht het niet duidelijk zijn, of heb je meer info nodig, geef het even aan.

VERWIJDERD

Dit is 1 van de sites die niet werkt (afbeeldingen zoeken via google):
http://images.google.nl/i...q=plaatjes&ie=UTF-8&hl=nl

[ Voor 29% gewijzigd door curry684 op 28-07-2004 17:59 ]

[curry684]

De hamvraag: werkt dat Proxyrama wel goed met die sites?

Verder: je bent ermee bekend dat RFC 1928 het SOCKS5 protocol compleet beschrijft zodat je de implementatie kunt controleren?

En wat werkt er niet aan die site van Google?

[Verwijderd]

Hehe, nee, dat ProxyRama werkt ook niet goed. Dat heb ik ook als basis gebruikt dus de code van het proxy deel is vrijwel identiek.

Ik weet waar ik de documentatie van een socks server kan vinden, maar heb ik dat echt nodig? Is alleen een (goede) proxy niet voldoende? Volgens mij moet het met enkel een proxy kunnen aangezien de meeste proxies prima werken...

De plaatjes worden niet weergegeven als je op afbeeldingen zoekt. Dit klinkt misschien vaag, maar ik vermoed dat google daarvoor gebruik maakt van redirects of zo. Over het algemeen worden plaatjes wel goed weergegeven.

[ Voor 21% gewijzigd door Verwijderd op 28-07-2004 10:20 ]

[curry684]

Verwijderd schreef op 28 juli 2004 @ 10:10:
Hehe, nee, dat ProxyRama werkt ook niet goed. Dat heb ik ook als basis gebruikt dus de code van het proxy deel is vrijwel identiek.

Dan was die developer niet zo geniaal wellicht

Ik weet waar ik de documentatie van een socks server kan vinden, maar heb ik dat echt nodig? Is alleen een (goede) proxy niet voldoende? Volgens mij moet het met enkel een proxy kunnen aangezien de meeste proxies prima werken...

Als je niet volgens protocol praat kun je natuurlijk problemen verwachten. Ik weet echter niet of dat hier het geval is (heb me nooit in proxies verdiept, k*tdingen )

De plaatjes worden niet weergegeven als je op afbeeldingen zoekt. Dit klinkt misschien vaag, maar ik vermoed dat google daarvoor gebruik maakt van redirects of zo. Over het algemeen worden plaatjes wel goed weergegeven.

Maareuj een plaatje is toch niets anders dan een HTML-pagina? Dwz een URL die met HTTP wordt gefetched? Waarom zou een plaatje daarmee anders zijn dan een HTML-pagina?

Zoals je het beschrijft zou je responsecode 301 niet correct afhandelen, en dat kan kloppen omdat er nog wel wat haken en ogen aan zitten (zie hier).

[justmental]

Misschien kun je een andere proxyserver als basis nemen?
bijv. http://www.privoxy.org/

[Soultaker]

Om HTTP goed werkend te krijgen heb je helemaal geen SOCKS proxy nodig. Een SOCKS-compliant proxy maken lijkt me dus overbodige moeite. File uploads en dergelijke gaan ook gewoon via HTTP (POST) requests.

De minimale vereiste voor een simpele (transparante) proxy server is dat 'ie een request line (de eerste regel van een HTTP request) kan parsen en een verbinding kan opzetten naar de HTTP server waarnaar in de URL verwezen wordt.

Een simpele webproxy werkt dus zo:

code:

Accepteer een connectie van een HTTP client.
Lees de eerste regel uit en haal daar het serveradres uit.
Maak een connectie naar de HTTP server.
Fungeer als tunnel tussen de twee connecties.

In het laatste stadium stuurt de proxy simpelweg alle data die 'ie ontvangt door (van client naar server en vice versa) totdat een van de twee de connectie sluit. Overigens is het wel prettig als zo'n proxy meerdere connecties tegelijk ondersteunt (via asynchrone I/O of met een thread per client connectie).

Inhoudelijk hoeft zo'n transparante proxy dus helemaal niets met de data te doen die de client en de server uitwisselen. Dat mag wel (RFC 2616 over HTTP/1.1 specificeert allerlei headers waarmee de proxy server zich kenbaar kan maken aan client en server) maar het is meestal niet nodig en het maakt het verwerken van requests een stuk ingewikkelder omdat nu ook HTTP headers geparsed moeten worden en content ook correct geïnterpreteerd moet worden om zaken als HTTP pipelining te ondersteunen.

Het lijkt me dus het meest verstandig om te beginnen met een zo simpel mogelijke transparante proxy en alleen features toe te voegen als je zeker weet dat je ze nodig hebt.

[Verwijderd]

Als eerst: sorry dat ik zelf zo laat reageer, het is TE mooi weer om niet naar het strand te gaan

Dus als ik het goed begrijp is het niet meer dan het doorsturen van de data, nou dat doe ik dus ook en het werkt inderdaad. De "brug" wordt met een listen en serve thread gelegd. Misschien dat wat je zei over asynchone I/O wel iets is om naar te kijken. Kan het zijn dat dit noodzakelijk is voor sommige pagina's? Dit ondersteun ik momenteel namelijk niet!

Kun je verklaren waarom het nu soms wel werkt en soms niet? Kan het zijn dat sommige ik de hostname van sommige serveradressen (bijvoorbeeld DNS addressen) eerst moet achterhalen? Beetje vaag, maar misschien begrijp je me wel... Met name dat bij de afbeeldingen-zoekpagina van google de afbeeldingen niet getoont kunnen worden. Dit moet toch iets beteken..(?)..

Wat ik bedoel, dat ik nog niet helemaal begrijp waarom het meestal wel werkt en soms niet!

Die headers ken ik verder wel, die worden geparst voor het bepalen van de anonimiteit van de proxy.

[ Voor 7% gewijzigd door Verwijderd op 28-07-2004 17:52 ]

[curry684]

Ik heb enkele links en stukken info uit de topicstart verwijderd. Laat duidelijk zijn: portscannen en zonder medeweten misbruiken van faciliteiten zonder medeweten van de eigenaar is computervredebreuk onder de Nederlandse wet en strafbaar. Alle referenties aan de proxy-scanner zijn nu dus exit.

Een discussie over hoe je een proxyserver schrijft is vanzelfsprekend wel welkom in P&W

[Soultaker]

Verwijderd schreef op 28 juli 2004 @ 17:51:
Misschien dat wat je zei over asynchone I/O wel iets is om naar te kijken. Kan het zijn dat dit noodzakelijk is voor sommige pagina's? Dit ondersteun ik momenteel namelijk niet!

In principe is het niet per se vereist dat je requests parallel vereist, maar het is voor de performance wel prettig. Een browser doet bij het laden van een pagina een heleboel concurrente requests (voor het laden van plaatjes en scripts en dergelijke) dus je moet er wel op voorbereid zijn; zelfs als je de requests een voor een afhandeld moet je er voor zorgen dat de binnenkomende connecties in de backlog blijven staan. Misschien gaat het daar op mis; wat gebeurt er als je de backlog van de server socket flink verhoogd (naar een paar honderd ofzo).

In een serieuze (zelfs simpele) HTTP proxy zorg je natuurlijk gewoon dat je concurrente requests kunt afhandelen.

Kun je verklaren waarom het nu soms wel werkt en soms niet? Kan het zijn dat sommige ik de hostname van sommige serveradressen (bijvoorbeeld DNS addressen) eerst moet achterhalen? Beetje vaag, maar misschien begrijp je me wel... Met name dat bij de afbeeldingen-zoekpagina van google de afbeeldingen niet getoont kunnen worden. Dit moet toch iets beteken..(?)..

Mja, maar ik heb weinig zin om al die bestaande code te gaan debuggen. Dat kun jij zelf beter doen (en zoniet, dan is dit een mooie gelegenheid om te leren debuggen ).

Die headers ken ik verder wel, die worden geparst voor het bepalen van de anonimiteit van de proxy.

Een simpele proxy hoeft dus helemaal niets met HTTP headers te doen.

[Soultaker]

curry684 schreef op 28 juli 2004 @ 17:58:
Ik heb enkele links en stukken info uit de topicstart verwijderd. Laat duidelijk zijn: portscannen en zonder medeweten misbruiken van faciliteiten zonder medeweten van de eigenaar is computervredebreuk onder de Nederlandse wet en strafbaar. Alle referenties aan de proxy-scanner zijn nu dus exit.

Op proxies scannen lijkt me anders gewoon toegestaan:

Wetboek van Strafrect - Artikel 138a

1. Met gevangenisstraf van ten hoogste zes maanden of geldboete van de derde categorie wordt, als schuldig aan computervredebreuk, gestraft hij die opzettelijk wederrechtelijk binnendringt in een geautomatiseerd werk voor de opslag of verwerking van gegevens, of in een deel daarvan, indien hij
a. enige beveiliging doorbreekt of
b. de toegang verwerft door een technische ingreep, met behulp van valse signalen of een valse sleutel dan wel door het aannemen van een valse hoedanigheid.

2. Met gevangenisstraf van ten hoogste vier jaren of geldboete van de vierde categorie wordt gestraft computervredebreuk, indien de dader vervolgens gegevens die zijn opgeslagen in een geautomatiseerd werk waarin hij zich wederrechtelijk bevindt, overneemt en voor zichzelf of een ander vastlegt.

3. Met gevangenisstraf van ten hoogste vier jaren of geldboete van de vierde categorie wordt gestraft computervredebreuk gepleegd door tussenkomst van een openbaar telecommunicatienetwerk, indien de dader vervolgens
a. met het oogmerk zich wederrechtelijk te bevoordelen gebruik maakt van verwerkingscapaciteit van een geautomatiseerd werk;
b. door tussenkomst van het geautomatiseerd werk waarin hij is binnengedrongen de toegang verwerft tot het geautomatiseerd werk van een derde.

Van lid 2 is zeker geen sprake. Van lid 3 kan pas sprake zijn als sprake is van het delict beschreven in lid 1, en daarvoor moet aan één van de twee voorwaarden voldaan zijn: het doorbreken van enige beveiliging (niet van toepassing) of de toegang verwerven door een technische ingreep met behulp van valse signalen, een valse sleutel of een valse identieit. Die tweede voorwaarde is nogal algemeen, maar lijkt me ook niet van toepassing.

[curry684]

Portscannen valt vziw onder 'valse signalen', in normaal dagelijks gebruik het 'telefoontje om te checken of men op vakantie is' of het 'even checken of de deur wel afdoende op slot zit'. Maar of enkel scannen wel of niet strafbaar is boeit me compleet niet, het is in de AV van iedere ISP in Nederland verboden en daarmee op GoT ongewenst. Terug naar de techniek van de proxy zelf dus

[Verwijderd]

Sorry, ik zal geen links meer posten. Ik wist niet dat dit illigaal was. Het is bij mijn weten nogal een grijs gebied. Als het maken/verspreiden via internet van zo'n programma strafbaar is, kan ik het dan misschien beter niet (of heel anoniem ) uitgeven? Misschien kan ik het op een server in Zweden zetten, daar hanteren ze heel andere wetten, zou dat voor mij verstandiger zijn? Technisch gesproken is de tool niet bedoeld als proxy scanner, omdat het niet naar "nieuwe" proxies zoekt, maar vooral bronnen op internet gebruikt (websites en zoekmachines) om al eerder gevonden proxies in een overzicht te zetten en te verifieren of de informatie klopt. (snelheid, land, anonimiteit, ...)

Soultaker: het niet parrallel kunnen verwerken van aanvragen kan het probleem zijn. Aangezien dit tot nu toe de enige optie is, ga ik hier meer informatie over zoeken. Het is niet moeilijk om meerdere threads te starten per aanvraag, dus technisch gezien leverd het geen problemen op. Ik heb hier pas vrijdag tijd voor, maar ik zal het resultaat hier neerzetten. Als iemand intussen andere ideeën/ervaringen heeft hoor ik dat natuurlijk nog graag!

[ Voor 27% gewijzigd door Verwijderd op 28-07-2004 19:20 ]

[Olaf van der Spek]

curry684 schreef op 28 juli 2004 @ 10:23:
Maareuj een plaatje is toch niets anders dan een HTML-pagina? Dwz een URL die met HTTP wordt gefetched? Waarom zou een plaatje daarmee anders zijn dan een HTML-pagina?

Binary vs text?

Soultaker schreef op 28 juli 2004 @ 18:04:
Een simpele proxy hoeft dus helemaal niets met HTTP headers te doen.

Je hebt toch minimaal de host header nodig, anders weet je niet naar welke server je het request moet forwarden.

[ Voor 34% gewijzigd door Olaf van der Spek op 28-07-2004 20:11 ]

[Petor]

Soultaker schreef op 28 juli 2004 @ 18:11:
[...]

Op proxies scannen lijkt me anders gewoon toegestaan:

[...]

Van lid 2 is zeker geen sprake. Van lid 3 kan pas sprake zijn als sprake is van het delict beschreven in lid 1, en daarvoor moet aan één van de twee voorwaarden voldaan zijn: het doorbreken van enige beveiliging (niet van toepassing) of de toegang verwerven door een technische ingreep met behulp van valse signalen, een valse sleutel of een valse identieit. Die tweede voorwaarde is nogal algemeen, maar lijkt me ook niet van toepassing.

Ik ben het met je eens tot je laatste opmerking. Juist door de ruime formulering van sub b van lid 1 krijgt de rechter de mogelijkheid veel onder deze sub te scharen, ook dit.

[Soultaker]

OlafvdSpek schreef op 28 juli 2004 @ 20:10:
Je hebt toch minimaal de host header nodig, anders weet je niet naar welke server je het request moet forwarden.

Nee, proxies forwarden requests niet op basis van de Host header. (Die is sowieso pas bij HTTP versie 1.1 geïntroduceerd). Een client die een HTTP request bij een proxy server doet moet een volledige URL in de request line zetten, dus bijvoorbeeld GET http://gathering.tweakers.net/forum/ HTTP/1.1 in plaats van GET /forum/ HTTP/1.1 wat gebruikelijk is bij directe HTTP requests. Omdat webservers verplicht zijn zowel de volledige (absolute) URI als de verkorte (relatieve) URLs te ondersteunen hoeft een proxy niets te wijzigen aan de request line (de URL hoeft dus niet per se afgekort te worden; het mag wel). De proxy hoeft dus niets met HTTP headers te doen.

edit:
Even uit de RFC quoten:

5.1.2 Request URI
The Request-URI is a Uniform Resource Identifier (section 3.2) and identifies the resource upon which to apply the request.

Request-URI = "*" | absoluteURI | abs_path | authority
[..]
The absoluteURI form is REQUIRED when the request is being made to a proxy. The proxy is requested to forward the request or service it from a valid cache, and return the response. Note that the proxy MAY forward the request on to another proxy or directly to the server specified by the absoluteURI. In order to avoid request loops, a proxy MUST be able to recognize all of its server names, including any aliases, local variations, and the numeric IP address.

Dat tweede is trouwens nog wel een belangrijk aandachtspuntje (tenzij je zelf zo slim bent om geen recursieve requests te doen).

Overigens zit er wel een subtiel betekenisverschil tussen een absolute URI en een lokaal pad; in het eerste geval mag de server zelf bedenken hoe 'ie de request afhandelt (en die mag 'ie bijvoorbeeld ook forwarden naar andere servers) maar in het tweede geval verwijst het pad echt naar een lokale resource en moet de server dus de lokale resource serven of een foutmelding genereren. Dat is allemaal nogal theoretisch geneuzel natuurlijk; er wordt zoveel gerommeld met HTTP dat zulke details nauwelijks van belang zijn. 100% officieel zou je dus in je proxy de request line moeten herschrijven, maar in de praktijk heb ik nog nooit gezien dat dat de werking van de proxy beïnvloedt.

De RFC is daar trouwens stricter in dan ik het nu stel:

The most common form of Request-URI is that used to identify a resource on an origin server or gateway. In this case the absolute path of the URI MUST be transmitted (see section 3.2.1, abs_path) as the Request-URI, and the network location of the URI (authority) MUST be transmitted in a Host header field.

[Olaf van der Spek]

Soultaker schreef op 28 juli 2004 @ 22:41:
Nee, proxies forwarden requests niet op basis van de Host header. (Die is sowieso pas bij HTTP versie 1.1 geïntroduceerd).

Ik dacht even aan transparante proxies, maar je hebt gelijk voor niet-transparante proxies.