javax.net.ssl.SSLException illegal_parameter bouncycastle related?

J'essaie de passer de BouncyCastle bcprov-jdk14-124.jar (oooold) à bcprov-jdk14-143.jar. Quand je remplace le vieux pot avec le nouveau pot et construis tout, mon logiciel n'établit plus une connexion SSL, échouant avec un javax.net.ssl.SSLException: Received fatal alert: illegal_parameter. Recherche Google pour "bouncycastle javax.net.ssl.SSLException illegal_parameter" a un total de 4 résultats.javax.net.ssl.SSLException illegal_parameter bouncycastle related?

Des suggestions sur où débuter le débogage?

contexte supplémentaires:

client sur Windows XP
serveur sur CentOS, en utilisant Oracle Application Server
Le client tente d'établir une connexion SSL pour un POST AXIS2.
Lorsque le serveur utilise bcprov-jdk14-143 et le client utilise bcprov-jdk14-124, le POST réussit, mais lorsque le client est mis à niveau à 143, je reçois cette erreur

Source

2009-08-15 retracile

Je suis un peu confus au sujet de votre configuration. Votre erreur provient de JSSE mais BC ne fournit pas JSSE. Je suppose que l'erreur provient du serveur, qui utilise SunJSSE. Vous utilisez probablement l'API TLS de BC du client pour établir la connexion TLS (vérifiez si vous avez TlsProtocolHandler).

Si tel est le cas, faire fonctionner tout cela est déjà un miracle sur Java 1.4, je ne ferais rien. Avant Java 5, JSSE de Sun est partiellement câblé à SunJCE de sorte que vous utilisez pratiquement 2 JCE en même temps sur le serveur. J'ai déjà joué avec TLS en Colombie-Britannique et je n'ai jamais réussi à le faire, alors vous avez une longueur d'avance sur moi :)

Pourquoi avez-vous besoin de mettre à niveau BC? À mon avis, il n'y a aucune raison d'utiliser BC du tout si vous utilisez Java 1.4 ou plus tard. Toutefois, il nécessite des modifications de code pour le supprimer si vous utilisez TlsProtocolHandler.

L'erreur spécifique est provoquée par l'envoi par le serveur d'une liste de méthodes de compression. Il n'y a aucun moyen de contourner cela. Personne ne supporte la compression mais tous envoient une liste avec seulement la méthode Null.

Source

2009-08-16 00:12:03

Je rencontre un autre problème en utilisant AES/CTR/NoPadding dans un CipherOutputStream (ne pas écrire un bloc partiel sur .close()) que j'espérais que la mise à jour pourrait corriger. La version 124 de BC est vraiment ancienne, et cela me préoccupe que je ne puisse pas l'améliorer. – retracile

J'ai déterminé que je peux mettre à jour le client à BC 1.41 sans casser SSL (et il semble que le problème de CTR a été fixé quelque part entre 1.24 et 1.41, qui répond à ma raison principale pour mettre à jour vers la dernière version BC). Mais BC 1.42 et 1.43 cassent SSL avec l'erreur décrite. Je veux toujours passer à la dernière version de la Colombie-Britannique, mais l'urgence est plus faible maintenant. – retracile

Pourquoi ne supprimes-tu pas BC? JSSE est la manière standard de faire du TLS en Java. Vous devez remplacer TlsProtocolHandler par SSLSocketFactory. À en juger par la durée du bogue du TLS en Colombie-Britannique, très peu de gens l'utilisent. –

javax.net.ssl.SSLException illegal_parameter bouncycastle related?

Répondre

Questions connexes