Metaner

Danke für den Tipp. Das hat funktioniert! Nachdem ich nun mit keytool alle VeriSign-Zertifikate entfernt habe, läuft meine Anwendung beim Zugiff auf eine Exception. Das genügt mir als Beweis dafür, dass Java zur Validierung das zentral abgelegte Zertifikat von VeriSign verwendet. Hatte vor paar Tagen noch gedacht, dass die Lösung viel komplexer und aufwendiger sein würde. Aber so ist es natürlich auch gut. @flashpixx: Vielen Dank!

Nachdem ich nun eine Nacht über das gelesene schlafen konnte und heute den ein und anderen Artikel gelesen habe konnte ich mir eine Lösung basteln, die ganz ohne Keystore bzw. importiertes Server-Zertifikat auskommt. Mit der nachfolgenden Implementierung funktioniert der Zugriff auch: TrustManagerFactory trustManagerFactory = TrustManagerFactory.getInstance(TrustManagerFactory.getDefaultAlgorithm()); trustManagerFactory.init((KeyStore)null); SSLContext customSSLContext = SSLContext.getInstance("SSL"); customSSLContext.init(null, trustManagerFactory.getTrustManagers(), new SecureRandom()); HttpsURLConnection.setDefaultSSLSocketFactory(customSSLContext.getSocketFactory()); Nur frage ich mich jetzt, ob der eingebundene TrustManager auch wirklich das Zertifikat validiert. Zieht der TrustManager jetzt zur Prüfung das Zertifikat des Root-CA (VeriSign) aus "cacerts" heran? Hat jemand eine Idee, wie man soetwas testen kann? Oder gibt es sonstige Kritik an dieser Art der Implementierung? Irgendwie sieht das zu einfach aus.

Danke für den Link ... ich lese aber jetzt erst einmal hier: JavaTM Secure Socket Extension (JSSE) Reference Guide. Ich habe nämlich das Gefühl mehr Grundlagen zu brauchen. Je mehr ich aber lese, desto mehr habe ich das Gefühl nichts mehr zu verstehen. Vielleicht liegts aber auch an der Uhrzeit ... der Kopf ist wohl schon zu voll. Und wie holt man das Zertifikat? :confused: Ich hatte nach meinem letzten Post gedacht, dass das von der SSL-Implementierung in Java gemacht wird und mir als Entwickler das Zertifikat sozusagen auf dem "goldenen Tablett" präsentiert wird. Aber so einfach ist es dann wohl doch nicht? PS: Zu meiner Entlastung vielleicht noch etwas. Bislang hatte ich lediglich mit Java Berührung, wenn es um die Einbindung von Webservices ging. Die WS die ich bislang eingebunden hatte, laufen nicht über SSL. Daher tue ich mich jetzt etwas schwerer. Für die Implementierung der WS benutze ich JAX-WS. Damit habe ich mir auch für die jetzige Aufgabe den entsprechenden WS-Stub erstellt. In der Vergangenheit brauchte ich mir bei den erstellten WS-Clients keine Gedanken um die Verbindungssteuerung machen ... das machte der Stub bzw. das Framework für mich.

Ich ging bei meinen Überlegungen immer davon aus, dass die SSL Verbindung in erster Linie der Verschlüsselung der Kommunikation zwischen beiden Rechnern dient. Aber Du hast natürlich Recht, dass diese Sicherheit nicht viel bringt, wenn die Vertrauenswürdigkeit des Zertifikates nicht geprüft wird. Wenn ich Dich richtig verstanden habe, brauche ich dann einen Keystore in dem das (Root-)Zertifikat ... in meinem Fall wurde das Zertifikat von VeriSign ausgestellt .... import ist. Ich gehe einmal davon aus, dass diese Root-Zertifikate nicht ablaufen bzw. sehr lange gültig sind. Erfolgt die Prüfung des Zertifikates des Webservers dann durch die Implementierung der entsprechenden Prüfmethoden im TrustManager? Wie Du anhand meines Codeschnipsels erkennen kannst, habe ich damit nämlich noch nicht gearbeitet. Das öffentliche Zertifikat des Webservers ist demnach für mich als Entwickler insofern nur von Bedeutung, dass dieses von den Kommunikationskomponenten ermittelt werden und zur Prüfung dem TrustManager übergeben werden kann. Ob "ich" (bzw. die Anwendung) dann diesem Zertifikat vertraut hängt allein und ausschließlich von der Implementierung "meiner" Prüfungen ab? Habe ich das richtig verstanden?

Hallo flashpixx, vielen Dank für den Link. Ich will aber meine Frage vielleicht noch mal etwas anders stellen. Ich bin mir nicht sicher ob ich auf dem Holzweg bin ... aber vielleicht kann mir das jemand sagen. Ich hatte an einen Mechanismus gedacht der dem bei Webservices ähnelt. Dort gibt es doch die Möglichkeit, vom Webserver die Beschreibung (WSDL) zum Webservice abzufragen. Gibt es nicht auch soetwas für öffentliche Zertifikate? Ich kenne doch den Server mit dem ich kommunizieren will ... kann ich von dem nicht "online" das aktuell gültige öffentliche Zertifikat abfragen um meine aktuelle Verbindung damit zu sichern/zu verschlüsseln? In diesem Fall bräuchte es nämlich idealerweise keinen Keystore. Oder habe ich damit zu kurz gedacht? :floet: Gruß Jan PS: Bislang habe ich das öffentliche Zertifikat nur über den Webbrowser und dessen Funktion zum Export des Zertifikates bekommen.

Hallo, ich möchte einen SSL-gesicherten Webservice in eine bestehende Anwendung einbinden. Da ich bislang keine Erfahrung mit SSL hatte, habe ich mir mit diversen Codeschnipseln eine lauffähige Lösung "gebastelt". Dazu habe ich mir das öffentliche Zertifikat vom SSL gesicherten Server besorgt, mir einen Keystore mit dem Keytool erstellt und dort das öffentliche Zertifikat importiert. Soweit so gut. Das Zertifikat des Servers wird jährlich geändert, so dass ich dieses Prozedere jährlich durchführen muss (neues öffentliches Zertifikat besorgen und in Keystore einlesen). Das bekomme ich hin ... aber wie ist es, wenn man die Funktion des Webservice an andere Anwender weitergeben möchte? Ich möchte nicht dem Anwender zumuten, dass dieser sich um die Aktualität des öffentlichen Zertifikates Gedanken machen muss oder gar sich mit Dingen wie Keystore (Keytool) beschäftigen muss. So sieht meine derzeitige SSL-Implementierung für den Client aus: ... KeyStore ks = KeyStore.getInstance("JKS"); char[] keypassword = "...mein Passwort ...".toCharArray(); ks.load(new FileInputStream("...Pfad zu meinem Keystore..."), keypassword); KeyManagerFactory kmf = KeyManagerFactory.getInstance("SunX509"); kmf.init(ks, keypassword); TrustManager[] myTrustManagerTrustAll = new TrustManager[] { new X509TrustManager() { public java.security.cert.X509Certificate[] getAcceptedIssuers() { return null; } public void checkClientTrusted( java.security.cert.X509Certificate[] certs, String authType) { } public void checkServerTrusted( java.security.cert.X509Certificate[] certs, String authType) { } } }; SSLContext customSSLContext = SSLContext.getInstance("SSL"); customSSLContext.init(kmf.getKeyManagers(), myTrustManagerTrustAll, new SecureRandom()); HttpsURLConnection.setDefaultSSLSocketFactory(customSSLContext.getSocketFactory()); ... Kann mir jemand sagen, ob a) es auch einen anderen Weg gibt, mit dem man dynamisch zur Laufzeit (d. h. ohne manuell das öffentliche Zertifikat zu besorgen und ohne einen Keystore mittels Keytool zu administrieren) den SSL-Zugriff eines Clients realisieren kann und wie dies dann aussehen könnte/müsste? Ich erwarte hier keine vollständige Implementierung (wenn es sowas gibt dann nehme ich die natürlich gerne ) ... es wäre aber schön, wenn man mich mit den richtigen "Zauberwörtern" auf den richtigen Weg bringen könnte. Ich habe schon das Internet durchwühlt und die Java-Api durchschaut. Bin aber selbst auf keinen Lösungsansatz gekommen. Gruß Jan PS: Ich würde mich noch als "Java"-Frischling bezeichnen. Daher verzeiht mir bitte, falls ich hier eine unqualifizierte Frage gestellt haben sollte. :floet:

Ich wollte nur kurz die Info los werden, dass es mit einem eigenen Handler und HandlerResolver funktioniert hat. Vielen Dank für den nützlichen Hinweis!

Danke für den Denkanstoss. Ich werde morgen mal versuchen, damit den Zugriff auf den SOAP-Header hinzubekommen. Falls ich selbst nicht zum Erfolg komme oder irgendwo hängen bleibe ... darf ich Dich dann noch einmal "nerven"? Ich benutze einen Web-Service für den ein Benutzerkonto erforderlich ist. Bei jedem WS-Zugriff müssen die Benutzerdaten mitgegeben werden. Nun ist es so, dass das Passwort zum Benutzerkonto nach spätestens x Tagen verfällt und damit der Zugang gesperrt ist. Bislang hatte ich bei jedem WS-Zugriff einen weiteren zusätzlichen WS-Aufruf durchgeführt um eine Information zur Gültigkeitsdauer des Passwortes zu bekommen. Nun hat der Anbieter des Web-Service eine Änderung durchgeführt, bei der nun im Response ein Soap-Header implementiert wurde, in dem genau diese Info steckt. Wenn ich an diese Info komme, würde ich mir für die Zukunft einen 2ten WS-Aufruf sparen und somit Performance gewinnen.

Hallo, vorweg ... ich habe mich bislang nur sporadisch mit Web-Services beschäftigt. Daher verzeiht mir bitte, wenn ich bei meiner Beschreibung evtl. nicht die korrekten Begrifflichkeiten verwende. Ich habe folgendes Problem. Ich benutze einen Web-Service und habe mir mittels wsimport einen entsprechenden Client (Stub) erzeugt. Ich benutze JAX-WS in Version 2.1.X. Der Zugriff funktioniert auch soweit. Nun wurde der Web-Service dahingehend erweitert, dass in der Soap-Nachricht ein <soap:header> mitgeliefert wird. In diesem Soap-Header stehen Informationen, die ich gerne auslesen möchte. Der Web-Service bzw. der erzeugte Stub bietet mir aber keinerlei neue Funktionen um an diese Information zu kommen. Bei meinen Recherchen habe ich schon diverse Lösungsansätze probiert. Allerdings ohne Erfolg. Das einzige was mir bislang gelungen ist, war den HTTP-Header auszulesen ... aber diese Infos brauche ich nicht. :beagolisc Was muss man also tun, um an die Informationen im Soap-Header zu kommen? Gruß Jan

Ein Code-Fragment hatte ich im neuen Posting eingefügt. Das Problem habe ich inzwischen beheben können (siehe neues Posting). Somit kann dieses Thema geschlossen werden.

:valen @ Klotzkopp : 1.000 Dank für Deinen Hinweis mit dem Timing und der daraus abgeleiteten Ursache für mein Problem. Das war der goldene Hinweis um das Problem zu lösen. Ich habe nun das Nachrichtenformat so geändert, dass jetzt (wie Du auch schon empfohlen hattest) die Nachrichtenlänge mitgegeben wird. Der Empfänger puzzelt nun die Nachricht wieder solange zusammen, bis das erwartete Ende erreicht ist. Die Kommunikation zwischen SmallTalk und Java funktioniert nun auch auf den "Problem"-Rechnern zu 100%. Habe dabei auch gleich das mit dem überlesenen 1. Byte korrigiert. Damit wäre auch dieses Mysterium geklärt. :upps @ardcore Danke auch Dir für die Aufklärung in Bezug auf die Data-Frames. Das habe sogar ich verstanden.

Ja, dass hatte ich eigentlich erwartet. :beagolisc Klingt plausibel. Würde tatsächlich erklären, warum es manchmal klappt aber meistens nicht. Soetwas in diese Richtung hatte ich schon vermutet (Timing) aber eher im Hinblick auf die Threads, die die Verarbeitung in SmallTalk und Java übernehmen. Dann werde ich mal versuchen, die Kommunikation um eine Längenprüfung zu erweitern. Bin mal gespannt, ob das zum Erfolg führt. :beagolisc ::floet: Ähm, ja ... kann nicht nur. Ist sogar der Fall. Ich hatte das garnicht mehr auf dem Bildschirm. Als ich damals die SmallTalk-Erweiterung vorgenommen hatte, habe ich mich schon gewundert, warum in Java immer das erste Zeichen der XML-Nachricht "verschluckt" wurde. Weil SmallTalk zu diesem Zeitpunkt eh schon andere merkwürdige Sachen machte, hatte ich das als weitere Eigenheit von SmallTalk hingenommen und seither schicke ich jeder XML-Nachricht ein vorangestelltes (Char(32) -> Leerzeichen) mit. :upps Zu meiner Rechtfertigung (warum ich das so gemacht hatte) war, dass ich bei der Programmierung in Java festgestellt hatte, dass beim ersten Aufruf von #read die Verarbeitung in Java an der Stelle angehalten wurde. Das fand ich ganz toll, da ich so sicherstellen kann, dass Java solange wartet, bis SmallTalk die Verarbeitung des Requests abgeschlossen hat und mit dem Senden der Antwort beginnt. Erst einmal vielen Dank für Deine Unterstützung. Ich werde nun meine Sourcen überarbeiten und prüfen, ob dass den Fehler behebt. Sobald ich neue Erkenntnisses habe werde ich die hier posten. Ich melde mich in jedem Fall noch einmal. Danke und Gruß Jan

Richtig! Auf der einen Seite wird (aus Sicht des Softwareentwicklers) ein SocketWrite-Stream mit Bytes gefüttert und anschließend (wenn die Nachricht komplett "befüllt" wurde) von SmallTalk abgeschickt. Dabei bediene ich mich eine TCP/IP Erweiterung in unserer Entwicklungsumgebung (Object Studio der Firma Cincom) die lt. Manual direkt auf die TCP/IP-API aufsetzt. In Java wird, nachdem der Request abgeschickt wurde, auf die Rückmeldung "gewartet". Wird mit der Rückmeldung begonnen, wird der erzeugte InputStream solange Byte-weise ausgelesen, bis kein Zeichen mehr ankommt. Zum Test hatte ich einmal in dieser Schleife eine Systemprotokollierung eingebaut. Die hat mir gezeigt, dass nur 4380 Bytes gelesen wurden. Das auf dem Transportweg die Nachricht in mehrere Paket aufgeteilt wird/werden muss ist mir klar. Aber das übernimmt für mich doch die Hardware bzw. eine andere (OSI-)-Schicht. Oder etwa nicht? Zum besseren Verständnis poste ich einmal die Java-Methode, die den Request startet und den Response entgegen nimmt. Vielleicht habe ich ja doch eine fehlerhafte Implementierung? public MethodResponse execute(MethodRequest methodRequest) throws Exception { MethodResponse methodResponse = new MethodResponse(methodRequest); Socket socket = this.getSocket(); try { ByteArrayOutputStream outputStream = Adapter.encode(methodRequest); socket.connect(this.getSocketAddress()); OutputStream out = socket.getOutputStream(); out.write(outputStream.toByteArray()); InputStream in = socket.getInputStream(); in.read(); ByteArrayOutputStream aDecStream = new ByteArrayOutputStream(); while (in.available() > 0) { aDecStream.write(in.read()); } Object result = ((MethodResponse)Adapter.decode(aDecStream)).getMethodResult(); methodResponse.setMethodResult(result); if(result instanceof SmalltalkException){ throw ((SmalltalkException)result); } } finally { if(socket != null) socket.close(); } return methodResponse; } Danke und Gruß Jan

Leider besteht das Problem doch noch immer. An der Windows-Registry hats nicht gelegen. Auch nach Neuinstallation tritt das Problem nach wie vor auf. Da ich das Problem weiter analysiert und neue Erkenntnisse gewinnen konnte,habe ich eine neue Meldung zu diesem Problem in Netzwerk-Forum eröffnet. Link: http://forum.fachinformatiker.de/networking-technologies/110331-unvollstaendige-tcp-nachrichten-max-4380-byte.html

Hallo, hierbei handelt es sich um eine Fortsetzung meines Postings Unvollständige Socket-Nachrichten (max. 4379 Byte) aus dem Java-Forum. Da das Problem nun doch nicht gelöst werden konnte und ich davon ausgehe, dass es kein Software/Java Problem ist, suche ich hier bei Euch Netzwerk-Experten nach Rat. Problembeschreibung: Wir haben eine in SmallTalk geschriebene Anwendung die auf Port 8081 einen TCP/IP Listener erzeugt und auf eingehende Verbindungen wartet. Eine in Java geschrieben Programmerweiterung soll sich nun mit diesem TCP/IP Listener verbinden, einen Request senden (reine XML-Daten / ohne HTTP-Header o. ä.) und den Response entgegennehmen. Im Rahmen eines Integrationstestes haben wir nun festgestellt das auf einigen Rechnern der Response (Antwort von SmallTalk an Java) exakt nach 4380 Byte abgeschnitten wird. Wir haben mit 6 Rechnern getestet wobei auf 3 Rechnern dieser Fehler (reproduzierbar) auftritt. Das merkwürdige ist, dass auch auf diesen 3 Rechnern es ab und zu dazu kommt, dass auch Nachrichten über 4380 Byte erfolgreich ankommen. Die Erfolgsquote schwankt zwischen den Rechnern aber erheblich (von ca. 5% -20% erfolgreiche Meldungen > 4380 Byte). Was noch verwirrender ist, ist die Tatsache, dass wir 2 Rechner mit identischer Hard- und Software getestet haben. Auf einem Rechner funktioniert die Kommunikation problemlos wobei der andere Rechner das Problem mit den unvollständigen Nachrichten hat. :eek: Achja, dass die Nachrichten unvollständig ankommen, betrifft auch wirklich nur die Rückmeldung von SmallTalk an Java. Schickt der Java-Client einen Request mit einer Länge über 4380 Byte kommt dieser immer vollständig an. Nur die Rückmeldungen sind von diesem Problem betroffen. Alle Rechner befinden sich im gleichen Netz (wobei das beim Test mit dem Loopback nicht entscheiden dürfte ... aber trotzdem der Hinweis). Außerdem haben wir keine Gemeinsamkeiten unter den 3 fehlerhaften Rechnern entdecken können (sowohl AMD als auch Intel, unterschiedliche Chipsätze etc.). Wir haben auch schon einen der Rechner, auf dem das Problem reproduziert werden kann, neu aufgesetzt. Doch auch das brachte keine Besserung. Alle Rechner laufen mit Windows XP (SP2). Was wir jetzt festgestellt haben ist, dass das Problem nur dann auftritt, wenn beide Anwendungen auf dem selben Rechner laufen und über die Loopback-Adresse kommunizieren (z. B. 127.0.0.1:8081 ). Nur dann tritt das Problem auf den 3 Rechnern reproduzierbar auf. Wir haben auch schon die IP-Adresse 127.0.0.1 durch die IP-Adresse der Netzwerkkarte 10.xxx.xx.xxx ersetzt. Doch auch das brachte keine Besserung. Werden allerdings SmallTalk-Anwendung und Java-Anwendung auf unterschiedliche Rechner gelegt z. B. SmallTalk startet TCP/IP-Listener auf der lokalen IP mit Port 8081 und der Java-Client wird von einem anderen Rechner im Netz gestartet und mit dem Listener verbunden, funktioniert die Kommunikation problemlos.D er Fehler tritt dann garnicht mehr auf. Wir haben auch schon TCP/IP Listener und Java-Client jeweils auf einen der 3 betroffenen Rechnern in diesen Test eingebunden. Der Fehler tritt dann ebenfalls nicht mehr auf. Das Fazit bis dahin: Der Fehler tritt nur bei Verwendung der Loopback-Adresse auf wenn Server-Socket und Client-Socket auf dem gleichen System ausgeführt werden. Der Fehler tritt auch nur mit Nachrichten auf, die von SmallTalk an Java gesendet werden. Der Fehler tritt aber auch dann nicht in 100% der Fällen auf! Weil wir uns das Problem nicht erklären können, haben wir dann Unterstützung aus unserer IT-Abteilung zugezogen. Mit unserer Analyse und den bisher durchgeführten Tests wurde dann eine Protokollierung des Netzwerkverkehrs durchgeführt (Software: Wireshark). Das Problem ist nur, dass sich die Kommunikation auf dem Loopback unter Windows nicht protokollieren läßt (haben auch schon einen Loopback-Adapter als Netzwerk-Device installiert). Wir haben dann als Gegenprobe (dass die Protokollierung grundsätzlich funktioniert) die Protokollierung der Nachrichten durchgeführt, wenn Client-Socket und Server-Socket auf getrennten System ausgeführt werden. Das klappte auch super. Dabei habe ich gesehen, dass die Gesamtnachricht in Paket mit je 1460 Byte aufgeteilt wird. Merkwürdig ist nun, dass die max. Länge der empfangenen Nachricht auf dem Problemrechnern genau 3 dieser Paketgrößen entspricht (3 x 1460 => 4380)? Steckt da ein System hinter? :confused: In den letzten Tagen haben wir nun vergeblich versucht, die Kommunikation auf dem MS-Loopback protokolliert zu bekommen. Haben u. a. auch TCP-Monitor von Apache verwendet und diesen als "Software-Bridge" zwischen Client und Server-Socket eingebunden. Doch TCP-Monitor protokolliert nur HTTP Nachrichten. Da wir keinen HTTP Header in der Kommunikation verwenden, klappte auch dieser Versuch nicht. Daher meine Frage/mein Hilferuf an Euch Experten: Kennt jemand dieses Problem bzw. hat damit einmal zu tun gehabt? Vielleicht kennt jemand von Euch eine Lösung, wie man den Loopback unter Windows XP protokollieren kann. Dass der Loopback unter Linux ohne Probleme "gesnifft" werden kann, wurde mir schon von unseren Admins gesagt. Nur leider sind der SmallTalk-Server als auch "Java-Client" nicht lauffähig unter Linux. Zumindest danke ich Euch schon einmal für das Lesen dieser Problembeschreibung. Gruß Jan