TCP Server über Proxy

[DBGTMaster]

Hallo,

ich möchte einen TCP Server + TCP Client schreiben, wobei sehr wichtig ist, dass der Client von sogut wie überall zum Server verbinden kann. Daher hab ich mir gedacht, ich lasse den Server auf Port 443 lauschen, da dieser Port fast überall offen ist.
Nun ist die Frage bei Netzwerken, welche einen Proxy Server im Einsatz haben, kann ich über den 443er Port irgendeinen Datenverkehr drüber laufen lassen oder muss dieser bestimmte Richtlinien laut den Standards entsprechen, damit der Proxy meinen Verkehr durchlässt??

Das einzige, was mir zum Thema Proxy einfällt, ist der Timeout, dass Verbindungen nach einer bestimmten Inaktivität beendet werden, aber da kann ich einfach ein reconnect durchführen..

Meine Frage ist nun, muss der Datenverkehr ein bestimmtes Format haben?

Hat jemand damit schon Erfahrungen gemacht??

danke!

[waigie]

Naja Port 443 wird ja normalerweise für SSL verschlüsselte Verbindungen genutzt. Daher kann der Inhalt schonmal nicht geprüft werden. Da dieser ja verschlüsselt ist. Somit solltest du da freie Hand haben. Sollte der Server also wirklich deine Pakete genauer unter die Lupe nehmen brauchst du dich nur an die Struktur eines HTTPS Pakets halten und kommst durch. Nähere Infos zum aufbau findest du hier: http://tools.ietf.org/html/rfc2818

Ich denke aber auch ehr nicht das ein Proxy alle Pakete seiner Clients analysiert. Zum einen ist das ein Zeitproblem und zum anderen möchte ich nicht wissen, wie die Datenschützer rumschreien wenn das rauskommt. Was dir ehr sorgen bereiten sollte, ist wenn jemand die IP des Servers einfach sperrt bzw. umleitet. Damit kann man jederzeit den Traffic zu deinem Server auf dem Proxy wirksam unterbinden.

Und wie gesagt 443 ist der Quasi Standartport für https Verbindungen. Ich weiß nicht was noch alles auf dem Server laufen soll. Aber 2 Dienste auf dem gleichen Port macht nur Probleme wenn man sie denn zum laufen bekommt.

[DBGTMaster]

Naja Port 443 wird ja normalerweise für SSL verschlüsselte Verbindungen genutzt. Daher kann der Inhalt schonmal nicht geprüft werden. Da dieser ja verschlüsselt ist. Somit solltest du da freie Hand haben. Sollte der Server also wirklich deine Pakete genauer unter die Lupe nehmen brauchst du dich nur an die Struktur eines HTTPS Pakets halten und kommst durch. Nähere Infos zum aufbau findest du hier: http://tools.ietf.org/html/rfc2818

Ich denke aber auch ehr nicht das ein Proxy alle Pakete seiner Clients analysiert. Zum einen ist das ein Zeitproblem und zum anderen möchte ich nicht wissen, wie die Datenschützer rumschreien wenn das rauskommt. Was dir ehr sorgen bereiten sollte, ist wenn jemand die IP des Servers einfach sperrt bzw. umleitet. Damit kann man jederzeit den Traffic zu deinem Server auf dem Proxy wirksam unterbinden.

Und wie gesagt 443 ist der Quasi Standartport für https Verbindungen. Ich weiß nicht was noch alles auf dem Server laufen soll. Aber 2 Dienste auf dem gleichen Port macht nur Probleme wenn man sie denn zum laufen bekommt.

Hallo,

deine Antwort klingt schon mal gut, werde die nächsten Tage mal Tests starten.

Um andere Dienste brauch ich mir auch keine sorgen machen, da diese Software auf einem eigenständigen Server laufen wird.

Eine Umleitung über einen Proxy ist eher unwahrscheinlich, aber dann ist es nicht meine Sorge, 8-)

[Chromanoid]

Sehr robust sollte das Anbieten eines Webservice über Port 80 sein.
Vielleicht ist außerdem http://msdn.microsoft.com/de-de/library ... s.80).aspx für dich interessant.

[waigie]

Naja rein theoretisch sollte es ziemlich egal sein auf welchem Port man arbeitet. Aber der Port 80 ist der Port auf dem im Normalfall die komplette HTTP Kommunikation abläuft. Würde ich als Firma den kompletten Traffic über einen Proxy jagen, dann würde ich definitiv Port 80 sperren um das Surfen während der Arbeitszeit einzudämmen. Deswegen wäre ich bei Port 80 etwas vorsichtig. Der Port ist auf häufig mal gesperrt.

Auch wenn im Moment der Dienst allein auf einem Server laufen soll, würde ich den Port 80 nicht belegen. Wer weiß was ob nicht irgendwann doch eine Website die den Dienst betrifft auf den Server soll. Auch wenn es unwahrscheinlich ist sollte man sich zumindest die Möglichkeit lassen. Wollte man beides nämlich gleichzeitig auf Port 80 betreiben, wären nur Dinge wie Apache Webservices möglich und diese sind wenn ich mich recht erinner nicht für dauerhafte Verbindungen ausgelegt und da DBGTMaster von Timeouts und neu Verbinden spricht gehe ich mal davon aus, das er persistente Verbindungen aufzubauen.

Allgemein würde ich immer davon abraten Ports mit Standartbelegung zu überschreiben. Aber gut das ist in dem Fall ja nicht meine Sache

[Chromanoid]

Wenn man ausgehende Verbindungen zu Adressen mit Port 80 verbietet, dann sollte alles andere auch verboten sein :) wer soweit geht der wird noch ganz andere Richtlinien haben.
Siehe http://de.wikipedia.org/wiki/Proxy_(Rechnernetz)
Proxys schauen durchaus in den Traffic und gerade in Universitätsnetzwerken etc. sind speziell auf HTTP ausgelegte Proxies häufig. Wenn man die Kommunikation also über das HTTP Protokoll erledigt, ist die Wahrscheinlichkeit geblockt zu werden am geringsten.

[DBGTMaster]

Hallo,

dass am Server Port 80 oder 443 belegt ist, stellt kein Problem dar, da es eine virtuelle Maschine ist und hier ganz sicher nichts anderes zu laufen kommt ;)...

Also wäre es wohl besser, über Port 80 als 443 zu kommunizieren?
Sache ist die, bei Port 80 müsste ich mein Protokoll dann auf XML Basis aufbauen :), und ob ich das so will..?

Was mir gerade so einfällt, Port 80 fällt aus, da der Verkehr verschlüsselt werden muss, da sensible Daten übertragen werden.... Somit bleibt mir eh nur mehr Port 443 durch, denn ich denk mal, verschlüsselten Verkehr über Port 80 würde jeder 2te Proxy blocken...

Danke für eure Antworten!

[Chromanoid]

Dann mach's mit HTTPS (dafür ist 443 ja eigentlich auch da). Wenn du Java benutzt, könntest du z.B. mit Jersey+Grizzly einfach nen RESTful Server programmieren. Allerdings sind die Dinger auf zustandslose Kommunikation eingestellt. Ansonsten kannst du dir dazu mal JBoss Netty oder Apache Mina anschauen - zumindest mit Netty habe ich gute Erfahrungen gemacht und einen HTTPS Server sollte sich damit leicht entwickeln lassen (habe bisher nur HTTP oder SSL gesehen, aber das sollte man ja auch kombinieren können). Siehe http://www.jboss.org/netty/documentation.html#examples
Evt. sind in Zukunft ja auch Websockets für dich nützlich. Bei http://en.wikipedia.org/wiki/WebSockets steht zumindest, dass Proxys die verschlüsselte Variante wohl am ehesten durchlassen.

Das hier könnte auch für dich interessant sein: HTTP Tunneling (HTTP Proxy Socket Client) Allerdings gibt es wohl auch Proxys die HTTPS aufbrechen und dann sollte das nicht mehr klappen...

text/xml musst du nicht als MIME Typ benutzen. JSON, Binärdaten etc. werden doch genauso über HTTP übertragen.

[Aramis]

Was mir gerade so einfällt, Port 80 fällt aus, da der Verkehr verschlüsselt werden muss, da sensible Daten übertragen werden

Du kannst deine Daten ja auch selber (OpenSSL) verschluesseln und dann z.b. Base64-kodiert ueber HTTP uebertragen. Nicht unbedingt eine Standardloesung, aber theoretisch moeglich.

Allerdings gibt es wohl auch Proxys die HTTPS aufbrechen und dann sollte das nicht mehr klappen...

Wie soll das funktionieren? Wenn ein SSL-Proxy den Man in the Middle spielt, funktioniert die Zertifikat-Chain ja nicht mehr (und der Proxy ist nutzlos). Oder verstehe ich da eben was falsch? :-)

[Chromanoid]

Der User muss sich dann mit einem Zertifikat des Proxys zufrieden geben. Bin mir nicht sicher ob das häufig vorkommt, ich glaube wir haben sowas im Firmennetzwerk, sicher bin ich aber nicht, bin vor allem über den Wikipedia-Artikel drüber gestolpert. Das nennt sich wohl SSL-Terminierung...