J'ai mis security.provider.1 = org.bouncycastle.jce.provider.BouncyCastleProvider mais il n'est pas utilisé pendant la poignée de main SSL

Question

Voici la trace de la pile de l'une des connexions dans mon processus:

"ServerConnection on port 10000 Thread 27" #521 prio=5 os_prio=0 tid=0x0000000002db4800 nid=0x2d79 runnable [0x00007f0ababb1000] 
java.lang.Thread.State: RUNNABLE 
at java.net.SocketInputStream.socketRead0(Native Method) 
at java.net.SocketInputStream.socketRead(SocketInputStream.java:116) 
at java.net.SocketInputStream.read(SocketInputStream.java:171) 
at java.net.SocketInputStream.read(SocketInputStream.java:141) 
at sun.security.ssl.InputRecord.readFully(InputRecord.java:465) 
at sun.security.ssl.InputRecord.read(InputRecord.java:503) 
at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:973) 
- locked <0x00000006d63c51f0> (a java.lang.Object) 
at sun.security.ssl.SSLSocketImpl.readDataRecord(SSLSocketImpl.java:930) 
at sun.security.ssl.AppInputStream.read(AppInputStream.java:105) 
- locked <0x00000006d6405210> (a sun.security.ssl.AppInputStream) 
at org.apache.geode.internal.cache.tier.sockets.Message.fetchHeader(Message.java:691) 
at org.apache.geode.internal.cache.tier.sockets.Message.readHeaderAndPayload(Message.java:709) 
at org.apache.geode.internal.cache.tier.sockets.Message.read(Message.java:657) 
at org.apache.geode.internal.cache.tier.sockets.Message.recv(Message.java:1105) 
- locked <0x00000006d6405288> (a java.nio.HeapByteBuffer) 
at org.apache.geode.internal.cache.tier.sockets.Message.recv(Message.java:1118) 
at org.apache.geode.internal.cache.tier.sockets.BaseCommand.readRequest(BaseCommand.java:869) 
at org.apache.geode.internal.cache.tier.sockets.ServerConnection.doNormalMsg(ServerConnection.java:723) 
at org.apache.geode.internal.cache.tier.sockets.ServerConnection.doOneMessage(ServerConnection.java:914) 
at org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1171) 
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) 
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
at org.apache.geode.internal.cache.tier.sockets.AcceptorImpl$1$1.run(AcceptorImpl.java:519) 
at java.lang.Thread.run(Thread.java:745) 

Ici, je devine plutôt que sun.security.ssl je devrais voir quelque chose utilisé de la bibliothèque gonflable de château.

Answer 1

Quelques choses:

1) Quel fournisseur château gonflable vous ajoutez? Le château gonflable conditionne le fournisseur JCE et le fournisseur JSSE dans des jars distincts et doit utiliser une classe fournisseur distincte. fournisseur JSSE classe est org.bouncycastle.jsse.provider.BouncyCastleJsseProvider et le fournisseur est JCE org.bouncycastle.jce.provider.BouncyCastleProvider

2) Oui, les fournisseurs sont recherchés dans l'ordre de priorité, mais Comme mentionné dans les réponses ci-dessus, la mise en œuvre est également dépendante de la façon dont l'algorithme/protocole est demandé dans le code de l'application. Tout d'abord, un fournisseur devrait implémenter l'algorithme/protocole que vous demandez et il doit également l'enregistrer en utilisant le nom/alias que vous utilisez lors de la demande. Par exemple, si le code demande le contexte TLS comme javax.net.ssl.SSLContext.getInstance ("SSL"), BC ne renverra aucun contexte car il n'enregistre aucune implémentation avec cet alias. Cependant, SunJSSE renverra un contexte en ajoutant "SSL" comme alias à "TLS"

Oui, vous pouvez demander explicitement l'implémentation à un fournisseur spécifique. Toutes les API JCE/JSSE ont une méthode supplémentaire surchargée qui prend le nom du fournisseur. Par exemple,

javax.net.ssl.SSLContext.getInstance ("TLS", "BCJSSE");

javax.net.ssl.KeyManagerFactory ("PKIX", "BCJSSE");