2009-08-15 7 views
0

Ich versuche, von BouncyCastle bcprov-jdk14-124.jar (oooold) auf bcprov-jdk14-143.jar zu aktualisieren. Wenn ich das alte Glas durch das neue Metallglas ersetze und alles baue, wird meine Software keine SSL-Verbindung mehr aufbauen, mit einem Fehler javax.net.ssl.SSLException: Received fatal alert: illegal_parameter. Googeln nach "bouncycastle javax.net.ssl.SSLException illegal_parameter" ergibt satte 4 Ergebnisse.javax.net.ssl.SSLException illegal_parameter bouncycastle verwandt?

Haben Sie Vorschläge, wo Sie mit der Fehlersuche beginnen können?

Weitere Kontext:

  • Client ist auf WinXP
  • Server auf CentOS, mit Oracle Application Server
  • Der Client versucht, eine SSL-Verbindung für einen AXIS2 POST zu etablieren.
  • Wenn der Server verwendet bcprov-jdk14-143 und der Client verwendet bcprov-jdk14-124 gelingt es der Post, aber wenn der Client auf 143 aktualisiert wird, bekomme ich diesen Fehler

Antwort

1

Ich bin ein bisschen verwirrt über Ihre Einrichtung. Ihr Fehler stammt von JSSE, aber BC stellt JSSE nicht zur Verfügung. Ich nehme an, dass der Fehler vom Server kommt, der SunJSSE verwendet. Wahrscheinlich verwenden Sie die TLS-API von BC, um die TLS-Verbindung herzustellen (prüfen Sie, ob TlsProtocolHandler vorhanden ist).

Wenn dies der Fall ist, ist alles auf Java 1.4 bereits ein Wunder, würde ich nichts verbessern. Vor Java 5 ist Sun JSSE teilweise mit SunJCE fest verdrahtet, so dass Sie praktisch 2 JCEs gleichzeitig auf dem Server verwenden. Ich spielte mit TLS von BC vorher und ich habe es nie funktioniert, also bist du weit vor mir :)

Warum müssen Sie BC aktualisieren? Meiner Meinung nach gibt es keinen Grund, BC überhaupt zu verwenden, wenn Sie auf Java 1.4 oder höher sind. Es erfordert jedoch Codeänderungen, um es zu entfernen, wenn Sie TlsProtocolHandler verwenden.

Der spezifische Fehler wird verursacht, indem der Server eine Liste der Komprimierungsmethoden sendet. Es gibt keine Möglichkeit, das zu umgehen. Niemand unterstützt die Komprimierung, aber alle senden eine Liste mit der Null-Methode.

+0

Ich stoße auf ein anderes Problem mit AES/CTR/NoPadding in einem CipherOutputStream (nicht einen Teilblock auf .close() schreiben), die ich hoffe, dass die Aktualisierung beheben könnte. Die 124 Version von BC ist wirklich ziemlich alt, und es geht mir darum, dass ich es nicht verbessern kann. – retracile

+0

Ich habe festgestellt, dass ich den Client auf BC 1.41 aktualisieren kann, ohne SSL zu brechen (und es scheint, dass das CTR-Problem irgendwo zwischen 1.24 und 1.41 behoben wurde, was meinen Hauptgrund für das Upgrade auf die neueste BC-Version anspricht). Aber BC 1.42 und 1.43 brechen SSL mit dem beschriebenen Fehler. Ich möchte immer noch auf die neueste Version von BC aktualisieren, aber die Dringlichkeit ist jetzt niedriger. – retracile

+0

Warum entfernen Sie nicht einfach BC? JSSE ist die Standardmethode für TLS in Java. Sie müssen TlsProtocolHandler in SSLSocketFactory ändern. Wenn man davon ausgeht, wie lange der TLS-Bug in BC war, benutzen ihn nur sehr wenige Leute. –

Verwandte Themen