HTTP Pakete Auslesen

[Sn1G3]

Hallo Community,

ich habe vor einen lokalen Proxy in Java zu schreiben. Über diesen laufen alle Pakete die auf Port 80 an meinen PC gehen. Wenn ich dann letztendlich die Pakete habe, kann ich dann Header und Body dieser Pakete ganz einfach auslesen? Welchen Typ werden diese Informationen dann haben?

Viele Grüße,

Sn1g3r

 

[Kevin94]

Warum wollen eingentlich immer wieder welche ihren eigenen Proxy/Server programmieren?
Kannst du mir mal den Sinn eines echten Proxys nennen, der auf dem selben Rechner und damit mit der selben IP läuft, wie der Rechner der weitergeleitet wird? Gut du kannst sowas wie Cookies und Informationen über OS und Browser blocken, das wars dann auch, deine IP haben sie trotzdem. Auserdem lässt deine Ausdrucksweiße nicht gerade auf fundiertes Fachwissen über den Funktionsweiße von HTTP durchblicken.
Aber zur eigentlichen Frage: Die "Pakete" sind erstmal grundlegen vom Typ byte[], wenn du alles selber programmieren willst, kriegst du zwangsläufig Probleme mit Character-Encoding und Komprimierung. Deshalb ist das einfachste, das du dir irgendeine Bibliothek suchst die das Low-Level Parsing für dich erledigt, z.B. Apache HttpComponents und selbst dann wird dein Vorhaben schwierig, aufwendig und unsinnig.

 

[Sn1G3]

Hi,

mit meinem Proxy will ich nicht meine IP-Adresse verstecken sondern die Pakete der Anwendungsschicht eben die HTTP-Pakete abfangen und anschließend auslesen. Vorerst sind nur Pakete von Interesse, die im Body HTML enthalten.

Auserdem lässt deine Ausdrucksweiße nicht gerade auf fundiertes Fachwissen über den Funktionsweiße von HTTP durchblicken.

Ich weiß sehr wohl wie das Protokoll funktioniert. Ich weiss nicht ob mein Fachwissend sehr fundiert ist, aber selbiges kann ich falls benötigt durchaus noch vertiefen.

und selbst dann wird dein Vorhaben schwierig, aufwendig und unsinnig.

Das es einfach und nicht aufwendig wird, hat niemand behauptet. Zur Unsinnigkeit. Weißt du denn was ich überhaupt vorhabe? Ich denke mal nein. Sei also bitte nicht so voreingenommen. Kennst du irgendwelche Bibliotheken, die mir hierbei weiterhelfen? Hat jemand von euch sowas oder etwas ähnliches gemacht?

Grüße

 

[Kevin94]

Wenn ich dich und dein Projekt in meinem ersten Post falsch eingeschätzt hab, dann tut es mir Leid.
Allerdings habe ich immernoch nicht verstanden wozu dein Proxy eigentlich da sein soll. Soll er nur deine Gewohnheiten protokollieren, oder den Content manipulieren?
Was die Libs angeht, kann ich dich nur auf die Apache Commons verweisen, die ich auch schon in meinem ersten Post mit Link erwähnt habe. Sie enthalten alles was man für einen HTTP Server/Proxy braucht, es sind dafür sogar fertige Beispiele auf der Seite.

 

[TheDarkRose]

Ließ den traffic einfach mit wireshark aus

Gesendet von meinem GT-I9000 mit Tapatalk 2

 

[WireShark]

@Kevin94
Es geht hier nicht darum seine IP zu verstecken oder irgendwie irgendwelche Daten die rausgehen zu loggen oder zu manipulieren.
Wenn du dir den ersten Post von TO noch ein mal durchliest findest du folgende Zeile :

Über diesen laufen alle Pakete die auf Port 80 an meinen PC gehen.

TO will also NICHT loggen was aus seinem Rechner rausgeht sondern das was reinkommt. Und zwar auf TCP/80 - HTTP.
Deine Voreingenommenheit macht hier wirklich keinen Sinn da DU es bist der die Frage nicht verstanden hat. Ergo solltest du dir auch keine Bemerkungen über das Ganze an sich erlauben da du nicht einmal verstanden hat was TO überhaupt vorhat.
Denn das was TO machen will hat sehr wohl Sinn, auch wenn selbst ich persönlich hier nicht zu einem "Proxy" greifen würde sondern wie von DarkRose bereits angemerkt eher zu WireShark.

Ich denke mal der Hauptgrund warum TO einen "Proxy" schreiben will ist weil er nicht erst alle Daten loggen und sich dann durchwühlen möchte um dann nur die mit "HTML"-Body zu finden sondern schon dierekt vor dem eigentlichen loggen zu entscheiden : "Body-Content == HTML ?".
Und in diesem Fall würde mir auch spontan erstmal nichts einfacheres einfallen als ein Proxy denn in WireShark den Content-Type eines HTTP-Paketes zu bestimmen dürfte bestimmt aufwändig sein, falls überhaupt möglich.

 

[Kevin94]

@WireShark Den Content eines HTTP-Responses in WireShark auszulesen ist eine Sache von fünf Minuten. Das Programm besitzt eine hervorragende Filternfunktion, anders könnte man die Datenflut, die WireShark sammelt, auch nicht nutzten. Und da die Anzahl an HTTP-Responses sich ziehmlich überschaubar halten sollte, wenn nur er auf den Proxy zugreift, wäre das schon machbar. Das Problem könnte allerdings sein, das diese Daten niemals an seinem Rechner ankommen, wenn an Port 80 kein Server läuft, aber dafür könnte man XAMPP dann misbrauchen.
Ich denke allerdings, dass du, genauso wie ich die Absichten des TO falsch verstanden haben. Vielleicht liegt es an der unsauberen Ausdrucksweise von uns allen, aber an Port 80 gehen afaik nur HTTP-Requests ein und die enthalten, korriegiere mich wenn ich mich irre, meistens keinen body und schon gar keine HTML-Seiten.
Wenn es ausserdem um mehr als ein paar wenige Aufrufe geht, ist WireShark sowieso der falsche Ansatz, da das Programm nicht zum automatisierten Auswerten geeignet ist.
Aber bevor es noch zu weiteren gegenseitigen Angriffen kommt, sollte besser der TO sagen, was er konkret vor hat.

 

[TheDarkRose]

Aber wireshark ist sehr gut für die Vorarbeit geeignet. Mit dem richtigen Filter wird nur das protokolliert, was man möchte. Danach kann die protokolldatei mit einen Programm automatisch auswerten. Wireshark nimmt einem imho den kompletten lowlevel Kram ab

Gesendet von meinem GT-I9000 mit Tapatalk 2

 

[Sn1G3]

Hi,

nochmal danke, an alle die sich mit diesem Thread befassen. Ich versuche nun nochmal das Thema besser zu formulieren. Ich will einen Proxy schreiben, in dem eingehende Pakete gefiltert werden. Mich Interessieren nur die Pakete, die per HTTP an mich adressiert wurden. Also quasi die Antworten derjendigen Server, die ich auf Port 80 kontaktiert habe. Dementsprechend lasse ich alle Anfragen, die über Port 80 ins Netz gehen zunächst über meinen Proxy laufen, alle anderen Anfragen (mit anderen Ports) nicht. Ist die überhaupt möglich, oder gehen automatisch alle Anfragen über den Proxy?
Angenommen es funktioniert, dann müsste ich den Anfragen, die über den Proxy laufen immer dieselbe Quellportnummer anhängen (nämlich die meiner Proxyanwendung) ,oder?
Falls dem so ist, kann ich ja den eingehenden Traffic aufteilen in Proxyrelevante Pakete und Pakete die meinen Proxy nicht interessieren. (Weil die Antworten der Server, die ich mit Port 80 kontaktiert habe nun als Zielport die Portnummer meiner Proxyanwendung tragen)
Habe ich das soweit richtig verstanden?
Nun, wenn die relevanten Pakete nun über meinen Proxy laufen, möchte ich diese erneut filtern. An dieser Stelle ein kleines Beispiel: Ich gehe auf youtube und klicke ein Video an. Auf diesen einen HTTP-Request bekomme ich zahlreiche HTTP-Responses. So zum Beispiel das HTML-Dokument, in dass das Video eingebettet ist, dann zahlreiche Vorschaubildchen, dann den Stream, irgendwelchen Javascript-Code usw. Aus diesen ganzen Paketen interessiert mich eigentlich nur das HTML-Dokument und der Stream.
Wie kann ich also hier die relevanten Pakete herausfiltern? Sorry, das ich in meinen vorangehenden Posts das Problem nur rudimentär beschrieben habe. Ich hoffe jetzt ist es verständlicher!

Viele Grüße,

Sn1G3

 

[TheDarkRose]

Wie gesagt, schaue dir die Filterfunktionen von Wireshark an. Dort kannst du das Logging auch nur auf HTTP beschränken. Danach rufst du die Youtube Seite auf, siehst dir die Aufzeichnungen von Wireshark an und suchst mal die Stream-URL. Das machst du noch zwei oder dreimal um zu bestätigen, dass es immer das selbe Paket ist. Aufgrung dieser Erkenntnisse kannst du den Filter verfeinern. Wireshark richtig eingestellt, schreibt es alles in eine Logdatei. Diese kannst du mit einem einfachen Programm auslesen und deine fertige Stream-URL zurückgeben.

 

[Sn1G3]

Hi, das mit dem Whireshark ist bestimmt nen guter Ansatz, aber das ganze ist Teil einer Bachelorarbeit und ich brauche nen gewissen Programmierteil. Inwiefern bietet Whireshark Schnittstellen bezüglich Java an? Das ganze sollte für den User auch einfach zu installieren sein, ohne das er sich 1000 Sachen runterladen installieren und konfigurieren muss.
Grüße

 

[sichanzumelden]

Bin ja normalerweise nicht der Typ, der sowas unbedingt kommentieren muss, aber...

Auserdem lässt deine Ausdrucksweiße nicht gerade auf fundiertes Fachwissen über den Funktionsweiße.

WEISE, ES IST WEISE; WEIßE ist ein BIER
dafür AUßERDEM

Ließ

LIES

versteh ich nicht warum ich in jedem zweiten Thread hier Hühnerkacke in die Augen bekomme, so schwer sind die Regeln echt nicht. 'Weiße'...

 

[TheDarkRose]

Ja und? Im Forum mach ich mir nicht besonders Gedanken darüber, lesen kann man es trotzdem, also trolle hier nicht so herum.

Bzgl wireshark: zumindest um herauszufinden was du für ein Paket brauchst, musst du mal wireshark mitschneiden. Es gibt eine java pcap lib, die das selbe wie wireshark aus java heraus dann ermöglicht, ohne als Proxy fungieren zu müssen.

Gesendet von meinem GT-I9000 mit Tapatalk 2

 

[Trololol]

Ist ja schön sich mal über Rechtschreibung zu unterhalten (auch wenn ich selber immer nur wieder den Kopf schütteln kann) aber das ist genug OT.

Viel wichtiger wäre es mal wenn jemand TO hier auf seinen Denkfehler hinweisen würde anstatt über die Sinnhaftigkeit von WireShark zu diskutieren :

Hi,

nochmal danke, an alle die sich mit diesem Thread befassen. Ich versuche nun nochmal das Thema besser zu formulieren. Ich will einen Proxy schreiben, in dem eingehende Pakete gefiltert werden. Mich Interessieren nur die Pakete, die per HTTP an mich adressiert wurden. Also quasi die Antworten derjendigen Server, die ich auf Port 80 kontaktiert habe. Dementsprechend lasse ich alle Anfragen, die über Port 80 ins Netz gehen zunächst über meinen Proxy laufen, alle anderen Anfragen (mit anderen Ports) nicht. Ist die überhaupt möglich, oder gehen automatisch alle Anfragen über den Proxy?
Angenommen es funktioniert, dann müsste ich den Anfragen, die über den Proxy laufen immer dieselbe Quellportnummer anhängen (nämlich die meiner Proxyanwendung) ,oder?
Falls dem so ist, kann ich ja den eingehenden Traffic aufteilen in Proxyrelevante Pakete und Pakete die meinen Proxy nicht interessieren. (Weil die Antworten der Server, die ich mit Port 80 kontaktiert habe nun als Zielport die Portnummer meiner Proxyanwendung tragen)
Habe ich das soweit richtig verstanden?
Nun, wenn die relevanten Pakete nun über meinen Proxy laufen, möchte ich diese erneut filtern. An dieser Stelle ein kleines Beispiel: Ich gehe auf youtube und klicke ein Video an. Auf diesen einen HTTP-Request bekomme ich zahlreiche HTTP-Responses. So zum Beispiel das HTML-Dokument, in dass das Video eingebettet ist, dann zahlreiche Vorschaubildchen, dann den Stream, irgendwelchen Javascript-Code usw. Aus diesen ganzen Paketen interessiert mich eigentlich nur das HTML-Dokument und der Stream.
Wie kann ich also hier die relevanten Pakete herausfiltern? Sorry, das ich in meinen vorangehenden Posts das Problem nur rudimentär beschrieben habe. Ich hoffe jetzt ist es verständlicher!

Viele Grüße,

Sn1G3

Sorry, aber so viel Mist in einem Post der uns ganz klar zeigt das dein Wissen über TCP/IP leider ziemlich falsch ist und dann möchtest du einen komplizierten Proxy schreiben der den Content eines HTTP-Response zuverlässig erkennt (HTML) ?
Entschuldige diese sehr provokante Frage, aber wie hast du es bitte mit diesem Mangel an Wissen, oder vielmehr : diesem falschen Wissen überhaupt bis zur Prüfung geschaft ?

Vielleicht solltest du dir die Arbeitsweise von TCP/IP mal genauer ansehen; z.B auf Wikipedia.

Ein TCP/IP Paket hat zwei eindeutige Adress-Paare : Ziel-IP : -Port und Quell-IP : -Port.
Eine TCP/IP Verbindung ist demnach eindeutig durch diese beiden Paare bestimmt.

Wenn du jetzt eine Verbindung zu einem HTTP Server aufbauen willst ergeben sich die Werte : IP des Servers als Ziel-IP , 80 als Ziel-Port , deine WAN-IP als Quell-IP (also deine öffentliche IP und NICHT deine interne LAN-IP) und als Quell-Port irgendein Port oberhalb von 1024 aber NICHT der selbe Port wie der Ziel-Port (außer durch forcing oder spoofing).

Ergo macht es keinen Sinn einen Server auf TCP/80 auf HTTP-Responsea warten zu lassen da 1) dafür von außen eine neue Verbindung auf TCP/80 geöffnet werden müsste und 2) die Pakete vom Server als Ziel-Port den Quell-Port des an ihn gesendeten Paketes.

Ein Proxy arbeitet anders : der Proxy wartet auf einem bestimmten Port auf Verbindungen von z.B. deinem Browser und leitet diese an den Ziel-Server weiter. Also bestehen Verbindungen zwischen deinem Browser und dem Proxy und zwischen dem Proxy und dem Server.
Aber einfach Pakete mitloggen geht nur mit einem Paket-Sniffer wie eben WireShark.

Solltest du also dein Projekt selbst implementieren müssen setze dich unbedingt genauer mit TCP/IP und ggf HTTP aus einander. Aber ohne dieses Wissen wirst du nicht weit kommen.

 

[TheDarkRose]

Naja, darum diskutieren wir hier. Das der Eingangspost etwas unsinnig ist, war mir schon klar, hab aber verstanden was der TO will.

Da wäre eben die Möglichkeit des gewünschten Proxys. Wenn im Browser der Proxy konfiguriert ist, dann ist der Weg wie folgt: Browser -> Proxy -> Server. D.h. bekommt dann der Proxy auch alle HTTP Responses mit, da dieser die ausgehenden Verbindungen zu den Server aufbaut. Nachteil ist halt, das man das ganze HTTP Krams programmieren muss, damit der Proxy auch mit allen Verbindungen zurecht kommt.

Zweite Möglichkeit ist eben das mitschneiden mittels PCAP ( | jNetPcap OpenSource ) wie es genau Wireshark macht. Kein Proxy im Browser einzustellen, keine HTTP Verbindungen zu programmieren, nur sniffen und filtern ^^ was man machen muss, ist sowieso im Vorfeld per Wireshark zu sniffen um überhaupt zu wissen, welche Pakete man abfangen muss.

Ergo, ist es trotzdem kein Grund den TO angreifen zu müssen!

[EDIT]

Wenn du jetzt eine Verbindung zu einem HTTP Server aufbauen willst ergeben sich die Werte : IP des Servers als Ziel-IP , 80 als Ziel-Port , deine WAN-IP als Quell-IP (also deine öffentliche IP und NICHT deine interne LAN-IP) und als Quell-Port irgendein Port oberhalb von 1024 aber NICHT der selbe Port wie der Ziel-Port (außer durch forcing oder spoofing).

Sorry, aber das ist Mist. Die Quell-IP des Sockets ist IMHO die LAN-IP. Erst durch NAT im Router wird die interne IP auf die WAN-IP umgeschrieben und mglw. sogar der Quell-Port auf einen neuen Port geändert. Weiteres ist der Quell-Port meist weit über 30000, der Dynamic Range beginnt ab 49152, ab diesen werden normal die Quell-Ports vergeben.[/EDIT]

 

[Trolololol]

jNetPCap ist zwar eine Möglichkeit, erfordert aber genau wie WireShark das libPCap (unter Windows die Portierung : WinPCap) auf dem System installiert ist damit jNetPCap überhaupt greifen kann. Und ob das wirklich so im Sinne der Aufgabe ist denke ich eher weniger.

Zum Edit : das ist mir durch aus bewusst, nur davon ausgehend das heutzutage jeder hinter einem Router sitzt (zumindest sollte man das, auch wenn man nur einen Rechner hat -> Sicherheit) habe ich diesen Zwischenschritt übers NAT gleich weggelassen (Begründung lasse ich mal weg).
Auch was sog. symetric-NATs angeht die auch den Port "natten" und nicht nur die IP sind mir durchaus bekannt, wird man aber gerade bei uns in Deutland zumindest in Privathaushalten so gut wie nicht antreffen. Für sowas sind dann doch schon größere Netze bekannt die nicht nur einen simplen DSL-Router verwenden sondern gleich n ganzen 19-Zoll Rack in dem einiges an Server-Technik steckt. Nur um mal die relevanz zu verdeutlichen.
Zur dynamic-Range und Port > 30000 : meinte ich auch mal zu sagen bis dann gefühlte 20 User meinten das dies nicht immer die Regel sein muss und bei entsprechender Config sogar wirklich schon ab 1024 aufwärst genutzt wird. Aus eigener Erfahrung : wenn ich meine Firewall-Anzeige öffne sind viele Source-Ports bei mir gerade mal im Bereich 4000 - 5000 , je nach dem wie lange der Rechner läuft. Aber selbst nach 2 Wochen Dauerbetrieb war ich kaum über die 10000er Marke.

Grundsätzlich gilt ja das eigentlich jeder Port verwendet werden könnte. Nur weil halt innerhalb der ersten 1024 Ports die sog. "well-known-ports" liegen und gerade unter Unix peinlich genau drauf geachtet wird das man nur als root Ports in dieser Range öffnen kann (unter Windows ist das ganze sehr viel "lockerer") wird halt auch bei Source-Ports manchmal diese Regel angewand.

Zur persönlichen Frage gegen TO : das sollte kein Angriff sein, vielleicht könnte man es eher als "Lächerlichkeit" bezeichnen, aber wie so oft muss ich leider auch wieder hier sagen : ich kann es mir einfach nicht vorstellen das jemanden eine solche Aufgabe gestellt wird (ganz gleich ob in der ersten Woche als Hausaufgabe oder zur Prüfung) OHNE das einem vorher alle nötigen Kenntnisse vermittelt wurden. Das man sich zu Hause natürlich auch mal hinsetzen sollte und bei Aufgaben welche sich um TCP/IP drehen auch vielleicht mal von selbst auf die Idee kommt und z.B. Wikipedia nach mehr Informationen fragt ist eine Kompetenz die man bereits draufhaben sollte wenn man sich für einen solchen Studiengang anmeldet.
Dem zufolge entstand dieses "falsche Wissen" was TO hier gepostet hat scheinbar daraus das er nicht in der Lage ist diese Kompezenz umzusetzen (bzw diese besitzt). Aber dafür können wir hier nichts sondern nur TO selbst. Und vielleicht wäre er dann von selbst vorher auf die Idee gekommen das das so wie er sich das gedacht hat schon mal gar nicht so einfach möglich ist (wie gesagt : nur mit PacketCapture). Und DARÜBER habe ich mich halt "ausgelassen" und diese Frage formuliert. Gegenüber TO sollte das lediglich heißen : befasse dich selbst mit den dir gegebenen Hinweisen.

 

[Sn1G3]

Hi,

Sorry, aber so viel Mist in einem Post der uns ganz klar zeigt das dein Wissen über TCP/IP leider ziemlich falsch ist

was an meinem Post genau ist denn so der Große Mist? Und sag jetzt nicht alles...

wie hast du es bitte mit diesem Mangel an Wissen, oder vielmehr : diesem falschen Wissen überhaupt bis zur Prüfung geschaft ?

Welche Prüfung?

Vielleicht solltest du dir die Arbeitsweise von TCP/IP mal genauer ansehen

Ich weiß sehr genau wie das mit TCP und UDP abläuft. Durch Multiplexing und Demultiplexing wird Sender der Sender eindeutig identifiziert. Meine Frage in diesem Rahmen ist: Woher weiß mein Proxy, welche Pakete für ihn bestimmt sind. Das kann ja nicht über die IP laufen. Folglich über den Port. Wie werden die für meinen Proxy relevanten Responses erkannt? (Und ich dachte, wie in meinem Post erwähnt, das der Proxy bei den Requests den Port modifiziert.)

Ergo macht es keinen Sinn einen Server auf TCP/80 auf HTTP-Responsea warten zu lassen da 1) dafür von außen eine neue Verbindung auf TCP/80 geöffnet werden müsste und 2) die Pakete vom Server als Ziel-Port den Quell-Port des an ihn gesendeten Paketes.

??? Meinst du hier mit Server den lokalen Proxy? 2) ist irgendwie kein Satz...

so, nun zum nächsten Post:

Nachteil ist halt, das man das ganze HTTP Krams programmieren muss, damit der Proxy auch mit allen Verbindungen zurecht kommt.

Ja, aber das ist meine Aufgabe... Hab ja noch nen paar Monate Zeit dafür. Ich werd mir das PCAP Zeug trotzdem mal ansehen.

Wenn im Browser der Proxy konfiguriert ist, dann ist der Weg wie folgt: Browser -> Proxy -> Server. D.h. bekommt dann der Proxy auch alle HTTP Responses mit.

Richtig, Browser -> Proxy -> Server. Wie bekommt dann der Proxy die Responses mit, bzw. wie weiß der Proxy welche Responses für ihn sind? Sorry das ich so blöd frag, aber bzgl. lokalen Proxys find ich einfach kaum Material zum lesen im Internet. Funktionieren die Prinzipiell wie jeder normale externe Proxy? Kennt jemand diesbezüglich gute Quellen?

Ergo, ist es trotzdem kein Grund den TO angreifen zu müssen!

Danke! Ich finde es schade das einige hier meinen, sie hätten die Weisheit mit Löffeln gefressen. Ich selbst kenne mich diesbezüglich wirklich noch nicht so gut aus. Die Grundlagen sind weitestgehend vorhanden. Wen mein Thread nervt und wer kein Bock hat konstruktiv und zusammen eine Lösung hierfür zu finden der muss ja nicht Antworten.

Grüße, Sn1g3

 

[Kevin94]

Ja, ein lokaler Proxy arbeitet wie jeder andere (externe) Proxy auch, allerdings mit dem kleinen aber feinen Unterschied, dass du zum einen dich nicht um die Sicherheit sorgen musst (durch die Routerfirewall kommt so schnell niemand) und zum anderen dass du direkten Einfluss auf die Einstellungen/Fähigkeiten des Proxys hast. Achja, und offline gehen kann der Proxy auch nicht und die Latenz dürfte bei einem annährend effizient programmierten Proxy auch die selbe bleiben.

 

[WireShark]

Richtig, Browser -> Proxy -> Server. Wie bekommt dann der Proxy die Responses mit, bzw. wie weiß der Proxy welche Responses für ihn sind? Sorry das ich so blöd frag, aber bzgl. lokalen Proxys find ich einfach kaum Material zum lesen im Internet. Funktionieren die Prinzipiell wie jeder normale externe Proxy? Kennt jemand diesbezüglich gute Quellen?

Weil TCP/IP ein Verbindungsorientiertes Protokoll ist.
Wie bereits erwähnt :

1) Client baut Verbindung zum Proxy auf
Diese Verbindung bleibt offen und ist eindeutig identifizierbar. Darum weis der Client auch das die Daten die ihm der Proxy schickt für ihn sind eben weil es über ein und die selbe Verbindung geht.

2) Proxy analysiert Anfrage vom Client
Bei HTTP wird hierzu die URL und das Header-Field "Server" verwendet um den Ziel-Server zu erkennen.

3) Proxy baut Verbindung zum Server auf
Genau das gleiche wie Punkt 1. Und eben genau desswegen weis der Proxy eben auch das die Daten die vom Server kommen für ihn sind weil es eben eine bestehende TCP/IP-Verbindung ist.

4) Proxy schickt Anfrage zum Server
5) Server beantwortet Anfrage und trennt Verbindung
6) Proxy leitet Antwort an Client weiter und trennt Verbindung


Also ist der weg den du gehen musst das du dich vom Client an einen laufenden Proxy verbinden musst der in der Lage ist diese Verbindung zum Ziel-Server weiterzuleiten.

Einfach einen Proxy starten und hoffen das dieser irgendwelche Pakete aus irgendwelchen Kommunikationskanälen mitbekommt GEHT NICHT ! Dafür hat man sog. Packet-Sniffer entwickelt.

Ich weiß sehr genau wie das mit TCP und UDP abläuft.

Sorry ... aber das KANN und WILL ich dir nicht glauben denn deine wie du selbst sagst "blöden" Fragen zeigen uns doch das es eben nicht so ist.

Und nur weil die Proxy-Anwendung bei dir lokal läuft heißt es doch nicht das sich diese anders verhält als wenn sie remote auf irgendeinem Server im Netz laufen würde. Oder hast du schon mal gesehen das etwas anders abläuft nur weil es auf einer anderen Maschine gestartet wird ? Ich glaube nicht.

Und bezüglich deiner Frage was an deinem Post "Mist" war :
Dein falscher Irrglaube das es reichen würde einfach mal so einen Server zu starten und zu denken das dieser dann irgendwelche TCP/IP Pakete empfangen würde aus Verbindungen die überhaupt nichts mit ihm zu tun haben.


btw : das mit "Prüfung" habe ich dem hier entnommen : Bachelorarbeit
Denn "Bachelorarbeit" bedeutet EIGENTLICH das dies die Prüfung ist um eben diesen Abschluss zu erreichen. Alles andere sind höchstens "normale Arbeiten" , Klausuren oder wie auch immer man es bezeichnen will.
Andersrum kann man aber auch sagen : jede Art von "Arbeit" ist eine Prüfung.

 

[Kevin94]

@ WireShark kannst du mal aufhören hier rumzuflamen? Das der TO sich in seinem Eingangspost extrem unsauber ausgedrückt hat, haben wir alle gemerkt und nach dem wir jetzt alle verstanden haben was er will gibt es keinen Grund weiter auf ihm herumzuhacken.

Einfach einen Proxy starten und hoffen das dieser irgendwelche Pakete aus irgendwelchen Kommunikationskanälen mitbekommt GEHT NICHT ! Dafür hat man sog. Packet-Sniffer entwickelt.
...
Und bezüglich deiner Frage was an deinem Post "Mist" war :
Dein falscher Irrglaube das es reichen würde einfach mal so einen Server zu starten und zu denken das dieser dann irgendwelche TCP/IP Pakete empfangen würde aus Verbindungen die überhaupt nichts mit ihm zu tun haben.

Sorry, aber das ist auch Mist. Wenn du einen HTTP-Proxy/Server startest dann initialisert dieser ein ServerSocket, dass dauerhaft auf Port 80 des Rechners auf Requests wartet. Und somit empfängt der Proxy/Server alle Pakete die für ihn bestimmt sind. Und wenn man in seinem Browser den Proxy einträgt, dann sollten alle Request auch bei diesem landen.
Das man mit einem Proxy keine Verbindungen sniffen kann ist klar, aber der TO will ja auch die HTTP Verbindung über den Proxy umleiten, um sie sozusagen zu sniffen.

 

[sichanzumelden]

lol, Trololol/Wireshark, hast du nicht neulich noch getönt, dass du das Forum verlassen willst? Halte dich doch bitte an deine Versprechen...

 

[Sn1G3]

1) Client baut Verbindung zum Proxy auf
Diese Verbindung bleibt offen und ist eindeutig identifizierbar. Darum weis der Client auch das die Daten die ihm der Proxy schickt für ihn sind eben weil es über ein und die selbe Verbindung geht.

2) Proxy analysiert Anfrage vom Client
Bei HTTP wird hierzu die URL und das Header-Field "Server" verwendet um den Ziel-Server zu erkennen.

3) Proxy baut Verbindung zum Server auf
Genau das gleiche wie Punkt 1. Und eben genau desswegen weis der Proxy eben auch das die Daten die vom Server kommen für ihn sind weil es eben eine bestehende TCP/IP-Verbindung ist.

4) Proxy schickt Anfrage zum Server
5) Server beantwortet Anfrage und trennt Verbindung
6) Proxy leitet Antwort an Client weiter und trennt Verbindung

Also ist der weg den du gehen musst das du dich vom Client an einen laufenden Proxy verbinden musst der in der Lage ist diese Verbindung zum Ziel-Server weiterzuleiten.

Wie bereits erwähnt: Das ist mir klar. Zu diesem Vorgang findet man 1000 Bildchen im Internet. Ich will, das von allen Responses nur HTTP-Responses an den Proxy gehen. Andere Protokolle wie ftp, smtp , imap, pop3 usw. soll direkt an den Browser. Deshalb will ich auch die Ports schon beim Request manipulieren. Jede Netzwerkanwendung ist mit nem Socket (IP, Port) beim Betriebssystem angemeldet. So auch der Proxy. Daher schick ich HTTP-Responses an das Proxy-Socket und den Rest an den Browser.

Zu Kevin94:

der TO will ja auch die HTTP Verbindung über den Proxy umleiten, um sie sozusagen zu sniffen.

Genau dieses!

Wie läuft das eigentlich Browserintern ab. Sucht sich der Browser für jede Verbindung einen neuen Port aus?(Wrsl ja, denn sonst wäre das Quadrupel aus Source-IP/Port, Remote-IP/Port nicht mehr eindeutig(Zumindest bei TCP-Verbindungen). Kennt jemand zum Internen Browserablauf bei Requests gute Quellen. Ich kauf mir hierzu auch gerne Bücher, aber die Google-Suche hat mir hierbei noch nicht wirklich weiter geholfen.

Danke für eure Antworten!

Grüße, Sn1g3


Ps.:

Dein falscher Irrglaube das es reichen würde einfach mal so einen Server zu starten und zu denken das dieser dann irgendwelche TCP/IP Pakete empfangen würde aus Verbindungen die überhaupt nichts mit ihm zu tun haben.

Vielleicht hab ich mich falsch Ausgedrückt, aber das habe ich mit Sicherheit nie geglaubt...

btw : das mit "Prüfung" habe ich dem hier entnommen : Bachelorarbeit
Denn "Bachelorarbeit" bedeutet EIGENTLICH das dies die Prüfung ist um eben diesen Abschluss zu erreichen. Alles andere sind höchstens "normale Arbeiten" , Klausuren oder wie auch immer man es bezeichnen will.
Andersrum kann man aber auch sagen : jede Art von "Arbeit" ist eine Prüfung.

Ich spar mir die Arbeit und schau im Duden nach, um diese Aussage zu widerlegen...

 

[TheDarkRose]

Jede ausgehende Verbindung (auch lokal) bekommt vom Betriebssystem zufällig einen Source-Port zugewiesen. Das macht nicht das Programm (Brwoser, Proxy) selbst. Wenn du dir die Socketprogrammierung anschaust, müsste dir auffallen das du nur Ziel-Adresse und Ziel-Port angibst. Source-IP definiert sich sowieso anhand der Netzwerkadresse und Source-Port wird eben für jede Verbindung zufällig zugeteilt.

Ergo brauchst du dir nur anschauen wie eine TCP-Verbindung abläuft, das ist alles. Payload/Daten ist dann das HTTP-Protokoll.