Proxy oder Forwarding?

[Guest]

Hallo zusammen!

Ich starte mal direkt mit meinem Problem.

Auf einem Server benutzen wird das Framework (jars) eines Drittanbieters, die in der jetzigen (und einzigen ) Version nicht SSL fähig sind, aber dafür dienen Nachrichten in einem bestimmten Format an ein Netzwerk zu übergeben. Also ohne SSL (reines TCP) funktioniert es.

Da ich das eigentliche Netz allerdings nur per SSL erreichen kann, habe ich bereits die Zertifikate in meine Stores eingebunden und habe führe auch schon einen erfolgreichen Handshake durch. Ich lasse mir momentan alles mit javax.net.debug protokollieren.

Was mir jetzt noch fehlt ist eine Art Port Forwarding oder Proxy, bin mir nicht sicher, was dafür richtig ist.

Konkret also:

Programm (3rd Party) schickt Daten an localhost Port xy, ich will sie dort abgreifen und über den SSL Port rausschicken.

Leider fehlt mir bis jetzt die letzte zündende Idee.

Danke im voraus.

MFG,

 

[tuxedo]

Läuft auf dem Zielserver ein SSH-Daemon/Dienst? Wenn ja: Du kannst TCP Verbindungen durch eine SSH-Verbindung tunneln und hast somit eine verschlüsselte Kommunikation ala SSL.

- Alex

 

[Guest]

Hi!

Danke für die rasche Antwort.

So, ich geh jetzt mal von "ja" aus. Nur wie!? Die Idee ist halt noch nicht gezündet

Okay, was ist, wenn "nein" die Antwort ist?

Danke für die Mühe im voraus.

 

[tuxedo]

Wenn ein Linux-System auf dem Server läuft, dann läuft mit 99,999999999%iger Sicherheit auch SSH.

Ein Tool mit dem man solche Tunnels aufbauen kann ist der "SSH Tunnel Client" -> http://download.freenet.de/archiv_s/ssh_tunnel_client_4969.html

Generell geht's aber auch mit "putty", oder ganz einfach auch "plink". Es gibt jedoch auch SSH-Libraries für Java mit denen du den Tunnel programmatisch aufbauen kannst, und somit keine Zweit-Anwendung brauchst. Einfach mal googeln. Anleitungen und Howtos gibt's wie Sand am Meer.

Wenn es kein Linux-Server ist: Dann sieht's schlechter aus mit SSH (geht zwar, ist aber AFAIK ziemlich umständlich).

Dann kannst du immernoch selbst einen SSL-Tunnel bauen wenn du keinen extra Proxy oder dergleiche installieren willst. Ist ja kein wirklicher Aufwand eine kleinen "Socket-Redirect-Server für SSL-Verbindungen" zu basteln.

Den lässt du dann einmal am Client laufen und einmal am Server:

[Client] ----verbindungsaufbau zum Redirect-Programmteil via localhost (noch kein SSL)---> [Redirect-Server] ---verbindungsaufbau zum zweiten Redirect-Server, Kommunikation bidirektional via SSL---> [Redirect-Server] ----verbindungsaufbau zum eigentlichen Server (nicht mehr SSL)---> [eigentlicher Server]

- Alex

 

[Gelöschtes Mitglied 5909]

http://www.jcraft.com/jsch/

 

[ms]

Geht mit Linux Boradmitteln alleine auch.
http://www.openssh.org

ms

 

[tuxedo]

@ms
Da hat mal wieder jemand nur die letzten 3 Zeilen gelesen ... ;-)
"Dummerweise" waren die für den "ist leider Windows und kein Linux" Fall gedacht.

- Alex

 

[Guest]

Hallo!

Danke für die Hilfe.

Zur genaueren Erklärung:

Ich kann nur Einfluß nehmen auf den Client. Der Server, mit dem ich mich verbinden will / muss, kann nur per ssl / https erreicht werden.

Und das Messagingframework ist halt für SSL nicht ausgelegt. Daher meine ursprüngliche Frage.

Auf JSCH bin ich schon gestoßen.

Ich würde den ganzen "Verbindungskram" gerne zentral über meine Javaimplementation machen. Reicht dafür nicht auch das Paket HTTPComponents? Oder doch noch zusätzlich JSCH?

*GRÜBEL* :autsch:

MFG,

 

[tuxedo]

Und noch immer stehen wir (oder nur ich?) im dunkeln was der server überhaupt anbietet...

"SSL" allein kann man ja nicht anbieten. Sondern nur in Form von HTTPS oder irgend einem Socketserver der eine SSL-verschlüsselte SOcketverbindung anbietet.

So. Ich sag jetzt einfach mal: Mit HTTPS kommst du nicht wirklich weiter wenn deine Serveranwendung weder HTTP nocht HTTPS spricht.

Gesetz dem Fall, die Kiste auf der der Server läuft IST ein Linux-Server: Dann kommst du mit http://www.ganymed.ethz.ch/ssh2/ oder auch JSCH ans Ziel, und das mit nur wenigen Zeilen Code in deiner Client-Anwendung.

Und wenns hier um eine "Webanwendung" geht, die eben nut HTTP aber kein HTTPS anbietet, dann kommst du mit dem Tunnel-Client (im Linux-Fall) auch zurecht.

Also bitte, etwas mehr Klartext.

- Alex

 

[Guest]

Hallo!

Ging leider nicht zeitlich früher!

Okay, habe mich vielleicht noch nicht ganz so klar ausgedrückt

Also, der Server, von dem ich nicht weiß, auf welchem Betriebssystem er läuft, wird von der T-Com gehostet. Die Kommunikation mit dem Server kann nur über TLS/SSL geschehen, daher hab ich den Port und IP von denen bereits inklusive Zertifikate etc. eingebaut. Handshake etc. läuft und wird mir momentan auf der Konsole alles schön mitprotokolliert.

Die Software (die Fremdjars) können in einer NICHT-SSL Umgebung Nachrichten an einen Server verschicken, auf dem auch das gleiche Protokoll (eine Art Mailprotokoll) wie auf dem Client läuft. Der Server an sich verteilt die dann weiter an und ist somit quasi ein Hub.

 

[tuxedo]

Okay, habe mich vielleicht noch nicht ganz so klar ausgedrückt

Vielleicht stell ich mich auch blöd an, aber mit meinem KnowHow aus den letzten 18 Jahren steh ich trotzdem noch etwas im dunkeln ...

Also, der Server, von dem ich nicht weiß, auf welchem Betriebssystem er läuft, wird von der T-Com gehostet. Die Kommunikation mit dem Server kann nur über TLS/SSL geschehen, daher hab ich den Port und IP von denen bereits inklusive Zertifikate etc. eingebaut. Handshake etc. läuft und wird mir momentan auf der Konsole alles schön mitprotokolliert.

Wie gesagt: Verschlüsselung ist die eine Sache. Aber dazu gehört auch immer ein entsprechender Dienst. Beispiel HTTP... Das ist von Haus aus "unverschlüsselt", gibts aber auch in der Ausprägung HTTPS, welches dann die Sache mit dem Zertifikat benötigt.

Ohne dazu zu sagen, um welchen Dienst es sich handelt, ist die Aussage "Die Kommunikation mit dem Server kann nur über TLS/SSL geschehen" quasi wertlos.

Sieht so aus als ob wir doch zum Frage/Antwort-Spiel übergehen müssen:

1) Welchen Port verwendest du da? (Anhand des Ports lässt sich vermutlich der zugehörige Dienst identifizieren).
2) Welches Protokoll (http, smtp, pop3, ftp, ssh, snmp, <weiß der Geier was>) wird zwischen Client und Server gesprochen? (hilft beim identifizieren des Dienstes...)
3) Hat deine Client-Anwendung einen namen? Gibts andere Konkurrenzanwendungen die das gleiche können? Wenn ja: Wie heißen die ( der letzte verzweifelte versuch rauszufinden um welchen dienst es sich handelt)

[/quote]

Die Software (die Fremdjars) können in einer NICHT-SSL Umgebung Nachrichten an einen Server verschicken, auf dem auch das gleiche Protokoll (eine Art Mailprotokoll) wie auf dem Client läuft. Der Server an sich verteilt die dann weiter an und ist somit quasi ein Hub.[/quote]

Also, da du ja immer von SSL/Nicht-SSL-Umgebung sprichst, gehe ich mal davon aus, dass der T-Com Server nur einen einzigen Dienst anbietet. Bis jetzt ist nicht klar, ob die Software, also deine Fremd-JARs, den identischen Dienst der auf dem T-Com-Server läuft, nur eben in der Ausprägung "Nicht-SSL" nutzen oder nicht.

Wenn der vom Server angebotene Dienst ein anderes Protokoll spricht, wie das, was deine Fremd-JARs sprechen, dann sieht's etwas recht schlecht aus (in abhängig keit davon, was der Server denn nun wirklich spricht/kann).

Ich denke so langsam wird's verwirrend. Also sei doch bitte so gut und leg die Karten auf den Tisch.. sonst reden wir nächste Woche noch aneinander vorbei ;-)

Gruß
Alex

 

[Guest]

Hallo!

Vorab erstmal vielen Dank für Deine Bemühungen.

So, nun "in medias res".

Grundsätzlich sollen Nachrichten im X.400 BusinessMail Link Format von meinem Client an den T-Com Server geschickt werden.

Bis jetzt existiert für sowas eine Einzelapplikationslösung, die direkt von der T-Com bezogen werden kann. Ziel ist nun, die Funktionalität des Clients (die bisherige Applikation) in ein Java-Umfeld zu integrieren.

Hierfür kann man sich
hier das Framework, die angesprochenene Fremdjars, besorgen, was die reine Mailkommunikation übernimmt. Allerdings kann es nativ so nicht Nachrichten über eine gesicherte HTTPS-Verbindung (und nur die bietet die Telekom an) rausschicken. Benutzt man unverschlüsselten Nachrichtentransport, so ist es mir gelungen, Nachrichten von meinem Client an einen anderen Client zu schicken. Die Ports sind frei wählbar für dieses Framework.

Empfohlen wird unter anderem die Nutzung von Stunnel, ich würde dessen Funktionalität jedoch gerne in meinem Programm abdecken.

Der T-Com Server (dessen OS ich nicht weiß und sich ja auch ohne weiteres mal ändern könnte) erwartete eine SSL/TLS Verbindung auf einem gewissen Port, speziell hier 5432 (T-COM IPort).

Deren Testzertifikate hab ich in meinem Keystore eingebaut. Ein Handshake ist möglich.

Was ich nun möchte (chronologischer Ablauf):

1) Verbindungsaufbau von meinem Rechner (Client) zum T-Com Server mittels HTTPS zum oben genannten Server
2) Dann springt das Messaging-Framework an und schickt den Mailinhalt an einen vorher definierten Port auf dem localhost (jedoch nicht der Port von 1))
3) Anschließend wird die Nachricht von Port 2 mittels Port 3 an die T-Com geschickt.

Liegt in der Architekturüberlegung irgendwo ein Fehler? Bin für Tipps dankbar.

Danke im voraus.

 

[Gast2]

Moin,

wie Du schon erfolgreich festgestellt hast, kannst Du am Server nichts ändern ... Du kannst auch an den JAR's der Drittanbieters nichts ändern ... und beides zusammen kommuniziert nicht ... da Server Port X verwendet und Client Port Y ... wenn beide das gleiche Protokoll sprechen hast Du Glück -> Server-Umleitung auf Client Seite basteln ... ansonsten ... schmeiß die JAR's weg -> es funktioniert einfach nicht

hand, mogel

 

[tuxedo]

Na also. X.400 ... Das ist doch schonmal was.

Du könntest die Sache immernoch über einen lokalen X.400 Proxy abdecken:

Deine Clientanwendung verbindet sich "zu sich selbst" (also zum internen Proxy) OHNE ssl zu benutzen. Der Proxy weiß dann wohin er sich verbinden muss und gibt die eingehenden, unverschlüsselten Daten über die mit SSL aufgebaut X.400 verbindung weiter.

Wichtig ist nur, dass es die ganze Zeit X.400 ist. Sonst hast du ein Problem und bräuchtest ein "<irgendwas> zu X.400 und Umgekehrt" Wandler.

Würde mal googeln ob nicht shcon jemand ein HTTP->HTTPS Gateway gebaut hat. Wenn nicht, würde ich folgendes vorgehen versuchen:

1) Im Client läuft eine Socketserver-Anwendung, welche ohne SSL arbeitet.
2) Deine Fremd-Jars welche kein SSL können, bauen ihre HTTP-Verbindung zu dem lokalen Socketserver auf.
3) Nimmt der Socketserver die verbindung entgegen, baut er eine SSL unterstütze Socketverbindung zum T-Com Server auf.
4) Jetzt müssten 2 Threads laufen:
4a) Thread 1 überwacht am Socketserver die unverschlüsselte Verbindung auf eingehende Daten. Gehen Daten ein, werden diese 1:1 in die SSL-Verschlüsselte Verbindung zum T-Com Server geschoben.
4b) Thread 2 überwacht dir SSL-verschlüsselte Verbindung zum T-COm Server auf eingehende Daten (also die Daten, die der T-Com Server zurückschickt). Gehen Daten ein, werden diese 1:1 in die unverschlüsselte Verbindung zum Client der am lokalen Socketserver hängt weitergegeben.

Prinzipiell sollte das funktionieren. Hab sowas schonmal gebaut um einen Port "umzuleiten" auf einen anderen Port. Der einzigste Unterschied zu deiner Anwendung müsste jetzt sein, dass der "Zielport" eben nur SSL beherrscht.

Beispielcode hab ich leider keinen für dich. Aber das sollte sich in unter 100 Zeilen Code deckeln lassen. Würde mal das Forum und auch google mit "SSL socket java" füttern. Das sollte weiterhelfen in Bezug auf die Socketprogrammierung mit SSL.

- Alex

P.S. Ach ja: Da das ganze HTML ist: Du kannst auch einen primitiven, lokalen Webserver implementieren (google mal nach nanohttp) und die eingehenden GET und POST Anfragen einfach in eine HTTPS-URL umverpacken und weiterleiten. Dann sparst du dir die Socket-Sache. Weiß allerdings nicht wie gut das geht.

 

[Guest]

Hi!

Erstmal danke für die weiteren Erklärungen. Bin momentan noch unterwegs, werde wohl auch erst später oder morgen weiter daran sitzen.

3) Nimmt der Socketserver die verbindung entgegen, baut er eine SSL unterstütze Socketverbindung zum T-Com Server auf.

Genau so war das gedacht, nur an dieser Realisierung wird es wohl hängen, da ich da noch nichts habe, außer diesem hier Netcallback, also mir der explizite Einfall fehlt, wie ich was vom Port xy lokal entgegenehme und es an den SSL Port übergebe

Bzgl. Sockets hab ich etwas rudimentäres (funktioniert hier vom unterwegs Lappi schon) gefunden. Link: Sockets. Bei einer Anfrage super, bei der nächsten Exception, daher schaue ich mir auch folgendes an...

Das hier sieht bzgl. mehrere Clients (also dein a) und b) also) gut aus. Java Sun Training

 

[tuxedo]

>> nur an dieser Realisierung wird es wohl hängen, da ich da noch nichts habe, außer diesem hier Netcallback, also mir der explizite Einfall fehlt, wie ich was vom Port xy lokal entgegenehme und es an den SSL Port übergebe

Du stellst dich an z z z z ;-) Ne, im ernst. Wenn du zwei bestehende Socketverbindungen hast, dann hast du auch die dazugehörigen Input und OutputStream. Die InputStreams musst du jeweils mit einem Thread "pollen", also in einer Schleife die Daten byte[]-weise rauslesen, und diese dann im selben Rhythmus in den entsprechenden OutputStream der anderen Socketverbindung mit write() reinschreiben. Mehr ist es nicht.

- Alex

 

[Gast]

Schonmal damit experimentiert??

Ich nutze das um (aus einer Java-Appl) mit hilfe von ua-fi (für Linux) Daten per SSL an Businessmail zu übergeben bzw. abzuholen!!

http://www.stunnel.org/