1

There's a CXF (2.7.11) webservice published via JaxWsServerFactoryBean to an embedded Jetty (8.1.15.v20140411) in a standalone application on Linux with JDK 8, 64 bit.

I set SSL parameters via JettyHTTPServerEngineFactory's setTLSServerParametersForPort.

The webservice does work, but there's a strange behaviour: when I start the server application the first SOAP request goes throw, but on the second request the client side CXF fails with a:

SocketTimeoutException: Read timed out

This is reproducible. It happens at CXF's default of 1 minute. When I look a jstack output of the server process (see below) org.bouncycastle.jce.provider.JDKKeyPairGenerator is running in that situation, doing some Diffie-Hellman calculations. On the current machine the server thread ends after almost 2 minutes runtime.

I can rule out entropy shortage. Installing the haveged daemon to fill up Linux' entropy pool did not make a difference.

Turning on full SSL debug output on the server side one can see differing behaviour at this point:

*** ClientHello, TLSv1.2
[remark: followed by session, cookie info]
%% Initialized:  [Session-1, SSL_NULL_WITH_NULL_NULL]      
matching alias: mykey    
%% Negotiating:  [Session-1, TLS_DHE_DSS_WITH_AES_128_CBC_SHA256]
*** ServerHello, TLSv1.2   
...

While this shows the working flow of the first request, the second one goes like this after the ClientHello:

%% Initialized:  [Session-2, SSL_NULL_WITH_NULL_NULL]
Using SSLEngineImpl.
Ignoring unavailable cipher suite XXX [remark: vast amount of ignored ciphers]

When the second request's thread is finished I can send hundreds of SOAP requests without problems.

Any hints why this is failing or why the second SSL session behaves differently?

jstack of server thread:

"qtp18669233-24" #24 prio=5 os_prio=0 tid=0x61344800 nid=0x5e3b runnable [0x60568000]

   java.lang.Thread.State: RUNNABLE

        at java.math.BigInteger.oddModPow(BigInteger.java:2701)

        at java.math.BigInteger.modPow(BigInteger.java:2443)

        at java.math.BigInteger.passesMillerRabin(BigInteger.java:1019)

        at java.math.BigInteger.primeToCertainty(BigInteger.java:875)

        at java.math.BitSieve.retrieve(BitSieve.java:203)

        at java.math.BigInteger.largePrime(BigInteger.java:744)

        at java.math.BigInteger.<init>(BigInteger.java:650)

        at org.bouncycastle.crypto.generators.DHParametersHelper.generateSafePrimes(Unknown Source)

        at org.bouncycastle.crypto.generators.DHParametersGenerator.generateParameters(Unknown Source)

    at org.bouncycastle.jce.provider.JDKKeyPairGenerator$DH.generateKeyPair(Unknown Source)

    at sun.security.ssl.DHCrypt.generateDHPublicKeySpec(DHCrypt.java:225)

    at sun.security.ssl.DHCrypt.<init>(DHCrypt.java:101)

    at sun.security.ssl.ServerHandshaker.setupEphemeralDHKeys(ServerHandshaker.java:1350)

    at sun.security.ssl.ServerHandshaker.trySetCipherSuite(ServerHandshaker.java:1194)

    at sun.security.ssl.ServerHandshaker.chooseCipherSuite(ServerHandshaker.java:1002)

    at sun.security.ssl.ServerHandshaker.clientHello(ServerHandshaker.java:724)

    at sun.security.ssl.ServerHandshaker.processMessage(ServerHandshaker.java:213)

    at sun.security.ssl.Handshaker.processLoop(Handshaker.java:925)

    at sun.security.ssl.Handshaker$1.run(Handshaker.java:865)

    at sun.security.ssl.Handshaker$1.run(Handshaker.java:862)

    at java.security.AccessController.doPrivileged(Native Method)

    at sun.security.ssl.Handshaker$DelegatedTask.run(Handshaker.java:1302)

    - locked <0x9c69baf0> (a sun.security.ssl.SSLEngineImpl)

    at org.eclipse.jetty.io.nio.SslConnection.process(SslConnection.java:375)

    - locked <0x9c69baa8> (a org.eclipse.jetty.io.nio.SslConnection)

    at org.eclipse.jetty.io.nio.SslConnection.access$900(SslConnection.java:48)

    at org.eclipse.jetty.io.nio.SslConnection$SslEndPoint.fill(SslConnection.java:678)

    at org.eclipse.jetty.http.HttpParser.fill(HttpParser.java:1044)

    at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:280)

    at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235)

    at org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:82)

    at org.eclipse.jetty.io.nio.SslConnection.handle(SslConnection.java:196)

    at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:696)

    at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:53)

    at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)

    at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)

    at java.lang.Thread.run(Thread.java:745)

UPDATE: The certificate used for SSL was created with JDK8's keytool using default settings. The result was a certificate with signature algorithm SHA1withDSA. I created a new certificate with SHA256withRSA and the problems obviously disappeared, no software change necessary.

4

0 回答 0