[JBoss JIRA] (WFLY-3252) First HTTPS / SSL request after startup of Wildfly 8.0.0.Final is blocked for many seconds
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-3252?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar commented on WFLY-3252:
-----------------------------------
I send PR to update bouncycastle version to latest https://github.com/wildfly/wildfly/pull/6196
Which should address the ssl engine creation problem, but that is not proper fix.
> First HTTPS / SSL request after startup of Wildfly 8.0.0.Final is blocked for many seconds
> ------------------------------------------------------------------------------------------
>
> Key: WFLY-3252
> URL: https://issues.jboss.org/browse/WFLY-3252
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 8.0.0.Final
> Environment: Win7, Java 1.7.0_51 and 1.8.0
> Reporter: bene.net
> Assignee: Tomaz Cerar
> Priority: Critical
> Labels: Blocked, HTTPS, JAX-RS, Performance, SSL, Start-Up, bouncycastle
> Attachments: server_keystore.jks, standalone-full.xml
>
>
> The first HTTPS / SSL request after startup of Wildfly 8.0.0.Final is blocked for many seconds.
> Please note that subsequent requests perform normally. HTTP requests also perform fine.
> We use curl to call a JAX-RS service (just in case this matters).
> My first thought was, that we had hit the following bug:
> https://issues.jboss.org/browse/XNIO-226?jql=
> However, I can also reproduce the problem with xnio-3.2.2.Final (which contains a fix for bug XNIO-226).
> So I inserted some logging statements in
> {code:title=AbstractAcceptingSslChannel.java}
> System.out.println("calling createSSLEngine...");
> long t1 = System.currentTimeMillis();
> final SSLEngine engine = sslContext.createSSLEngine(JsseSslUtils.getHostNameNoResolve(peerAddress), peerAddress.getPort());
> long t2 = System.currentTimeMillis();
> long duration = t2 - t1;
> System.out.println("createSSLEngine took "+duration+" ms. ");
> {code}
> and in
> {code:title=JsseSslConduitEngine.java}
> case NEED_TASK: {
> Runnable task;
> synchronized (engine) {
> // run the tasks needed for handshaking
> while ((task = engine.getDelegatedTask()) != null) {
> try {
> System.out.println("calling task.run() in handleHandshake...");
> long t1 = System.currentTimeMillis();
> task.run();
> long t2 = System.currentTimeMillis();
> long duration = t2 - t1;
> System.out.println("task.run() in handleHandshake took "+duration+" ms. ");
> } catch (Exception e) {
> throw new IOException(e);
> }
> }
> }
> // caller should try to wrap/unwrap again
> return true;
> }
> {code}
> I found out, that sslContext.createSSLEngine in AbstractAcceptingSslChannel.java is quite slow (468ms) but it is not the cause
> for the blocking request. Instead org.xnio.ssl.JsseSslConduitEngine.handleHandshake(JsseSslConduitEngine.java:512) needs
> 95 seconds to return!!!
> Here is the relevant part from my log file:
> {noformat}
> INFO ; 2014-04-11 18:29:52,115; [Controller Boot Thread ]; JBAS015874: WildFly 8.0.0.Final "WildFly" started in 6477ms - Started 334 of 386 services (107 services are lazy, passive or on-demand); [org.jboss.as.server.BootstrapListener.done(BootstrapListener.java:93)]; ;
> INFO ; 2014-04-11 18:30:05,566; [default I/O-3 ]; calling createSSLEngine...
> ; [org.jboss.stdio.AbstractLoggingWriter.write(AbstractLoggingWriter.java:71)]; ;
> INFO ; 2014-04-11 18:30:06,035; [default I/O-3 ]; createSSLEngine took 468 ms.
> ; [org.jboss.stdio.AbstractLoggingWriter.write(AbstractLoggingWriter.java:71)]; ;
> INFO ; 2014-04-11 18:30:06,066; [default I/O-3 ]; calling task.run() in handleHandshake...
> ; [org.jboss.stdio.AbstractLoggingWriter.write(AbstractLoggingWriter.java:71)]; ;
> INFO ; 2014-04-11 18:31:41,128; [default I/O-3 ]; task.run() in handleHandshake took 95061 ms.
> ; [org.jboss.stdio.AbstractLoggingWriter.write(AbstractLoggingWriter.java:71)]; ;
> INFO ; 2014-04-11 18:31:41,133; [default I/O-3 ]; calling task.run() in handleHandshake...
> ; [org.jboss.stdio.AbstractLoggingWriter.write(AbstractLoggingWriter.java:71)]; ;
> INFO ; 2014-04-11 18:31:41,145; [default I/O-3 ]; task.run() in handleHandshake took 10 ms.
> ; [org.jboss.stdio.AbstractLoggingWriter.write(AbstractLoggingWriter.java:71)]; ;
> INFO ; 2014-04-11 18:31:41,573; [default task-1 ]; SecurityFilter received request. ; [de.head.vetsone.rest_ifc.SecurityFilter.filter(SecurityFilter.java:62)]; ;
> {noformat}
> Using JConsole I could extract the full stacktrace:
> Name: default I/O-2
> State: RUNNABLE
> Total blocked: 0 Total waited: 2
> Stack trace:
> {noformat}
> java.math.BigInteger.oddModPow(BigInteger.java:2700)
> java.math.BigInteger.modPow(BigInteger.java:2443)
> java.math.BigInteger.passesMillerRabin(BigInteger.java:1019)
> java.math.BigInteger.primeToCertainty(BigInteger.java:875)
> java.math.BitSieve.retrieve(BitSieve.java:203)
> java.math.BigInteger.largePrime(BigInteger.java:744)
> java.math.BigInteger.<init>(BigInteger.java:650)
> org.bouncycastle.crypto.generators.DHParametersHelper.generateSafePrimes(Unknown Source)
> org.bouncycastle.crypto.generators.DHParametersGenerator.generateParameters(Unknown Source)
> org.bouncycastle.jce.provider.JDKKeyPairGenerator$DH.generateKeyPair(Unknown Source)
> sun.security.ssl.DHCrypt.generateDHPublicKeySpec(DHCrypt.java:225)
> sun.security.ssl.DHCrypt.<init>(DHCrypt.java:101)
> sun.security.ssl.ServerHandshaker.setupEphemeralDHKeys(ServerHandshaker.java:1350)
> sun.security.ssl.ServerHandshaker.trySetCipherSuite(ServerHandshaker.java:1194)
> sun.security.ssl.ServerHandshaker.chooseCipherSuite(ServerHandshaker.java:1002)
> sun.security.ssl.ServerHandshaker.clientHello(ServerHandshaker.java:724)
> sun.security.ssl.ServerHandshaker.processMessage(ServerHandshaker.java:213)
> sun.security.ssl.Handshaker.processLoop(Handshaker.java:925)
> sun.security.ssl.Handshaker$1.run(Handshaker.java:865)
> sun.security.ssl.Handshaker$1.run(Handshaker.java:862)
> java.security.AccessController.doPrivileged(Native Method)
> sun.security.ssl.Handshaker$DelegatedTask.run(Handshaker.java:1302)
> - locked sun.security.ssl.SSLEngineImpl@3f3d2d55
> org.xnio.ssl.JsseSslConduitEngine.handleHandshake(JsseSslConduitEngine.java:512)
> - locked sun.security.ssl.SSLEngineImpl@3f3d2d55
> org.xnio.ssl.JsseSslConduitEngine.unwrap(JsseSslConduitEngine.java:595)
> org.xnio.ssl.JsseSslConduitEngine.unwrap(JsseSslConduitEngine.java:543)
> org.xnio.ssl.JsseSslStreamSourceConduit.read(JsseSslStreamSourceConduit.java:89)
> org.xnio.conduits.ConduitStreamSourceChannel.read(ConduitStreamSourceChannel.java:127)
> io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:111)
> io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:69)
> io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:38)
> org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:291)
> org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:286)
> org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> org.xnio.ChannelListeners$DelegatingChannelListener.handleEvent(ChannelListeners.java:1092)
> org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> org.xnio.nio.NioTcpServerHandle.handleReady(NioTcpServerHandle.java:53)
> org.xnio.nio.WorkerThread.run(WorkerThread.java:531)
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 5 months
[JBoss JIRA] (WFLY-3079) Wildfly JDK 8
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-3079?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar closed WFLY-3079.
-----------------------------
Resolution: Rejected
> Wildfly JDK 8
> -------------
>
> Key: WFLY-3079
> URL: https://issues.jboss.org/browse/WFLY-3079
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Security, Server
> Affects Versions: 8.0.0.Final
> Reporter: Otávio Garcia
> Assignee: Tomaz Cerar
> Labels: jdk8, wildfly
>
> When I start wildfly in standalone mode I got this error.
> {noformat}
> 02:55:28,938 ERROR [org.xnio.listener] (XNIO-1 I/O-2) XNIO001007: A channel event listener threw an exception: java.lang.NoClassDefFoundError: Could not initialize class sun.security.ec.CurveDB
> at sun.security.ec.SunECEntries.putEntries(SunECEntries.java:72)
> at sun.security.ec.SunEC.<init>(SunEC.java:76)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) [rt.jar:1.8.0]
> at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) [rt.jar:1.8.0]
> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) [rt.jar:1.8.0]
> at java.lang.reflect.Constructor.newInstance(Constructor.java:408) [rt.jar:1.8.0]
> at java.lang.Class.newInstance(Class.java:433) [rt.jar:1.8.0]
> at sun.security.jca.ProviderConfig$2.run(ProviderConfig.java:221) [rt.jar:1.8.0]
> at sun.security.jca.ProviderConfig$2.run(ProviderConfig.java:206) [rt.jar:1.8.0]
> at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.8.0]
> at sun.security.jca.ProviderConfig.doLoadProvider(ProviderConfig.java:206) [rt.jar:1.8.0]
> at sun.security.jca.ProviderConfig.getProvider(ProviderConfig.java:187) [rt.jar:1.8.0]
> at sun.security.jca.ProviderList.loadAll(ProviderList.java:282) [rt.jar:1.8.0]
> at sun.security.jca.ProviderList.removeInvalid(ProviderList.java:299) [rt.jar:1.8.0]
> at sun.security.jca.Providers.getFullProviderList(Providers.java:173) [rt.jar:1.8.0]
> at java.security.Security.getProviders(Security.java:452) [rt.jar:1.8.0]
> at org.xnio.sasl.SaslUtils.getFactories(SaslUtils.java:121) [xnio-api-3.2.0.Final.jar:3.2.0.Final]
> at org.xnio.sasl.SaslUtils.getSaslServerFactories(SaslUtils.java:75) [xnio-api-3.2.0.Final.jar:3.2.0.Final]
> at org.jboss.remoting3.remote.ServerConnectionOpenListener$Initial.initialiseCapabilities(ServerConnectionOpenListener.java:165) [jboss-remoting-4.0.0.Final.jar:4.0.0.Final]
> at org.jboss.remoting3.remote.ServerConnectionOpenListener$Initial.sendCapabilities(ServerConnectionOpenListener.java:413) [jboss-remoting-4.0.0.Final.jar:4.0.0.Final]
> at org.jboss.remoting3.remote.ServerConnectionOpenListener$Initial.handleEvent(ServerConnectionOpenListener.java:260) [jboss-remoting-4.0.0.Final.jar:4.0.0.Final]
> at org.jboss.remoting3.remote.ServerConnectionOpenListener$Initial.handleEvent(ServerConnectionOpenListener.java:139) [jboss-remoting-4.0.0.Final.jar:4.0.0.Final]
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.2.0.Final.jar:3.2.0.Final]
> at org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:196) [xnio-api-3.2.0.Final.jar:3.2.0.Final]
> at org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:110) [xnio-api-3.2.0.Final.jar:3.2.0.Final]
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.2.0.Final.jar:3.2.0.Final]
> at org.xnio.ChannelListeners$DelegatingChannelListener.handleEvent(ChannelListeners.java:1092) [xnio-api-3.2.0.Final.jar:3.2.0.Final]
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.2.0.Final.jar:3.2.0.Final]
> at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) [xnio-api-3.2.0.Final.jar:3.2.0.Final]
> at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:87)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:531)
> 02:55:34,171 ERROR [org.xnio.listener] (XNIO-1 I/O-1) XNIO001007: A channel event listener threw an exception: java.lang.NoClassDefFoundError: Could not initialize class sun.security.ec.CurveDB
> at sun.security.ec.SunECEntries.putEntries(SunECEntries.java:72)
> at sun.security.ec.SunEC.<init>(SunEC.java:76)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) [rt.jar:1.8.0]
> at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) [rt.jar:1.8.0]
> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) [rt.jar:1.8.0]
> at java.lang.reflect.Constructor.newInstance(Constructor.java:408) [rt.jar:1.8.0]
> at java.lang.Class.newInstance(Class.java:433) [rt.jar:1.8.0]
> at sun.security.jca.ProviderConfig$2.run(ProviderConfig.java:221) [rt.jar:1.8.0]
> at sun.security.jca.ProviderConfig$2.run(ProviderConfig.java:206) [rt.jar:1.8.0]
> at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.8.0]
> at sun.security.jca.ProviderConfig.doLoadProvider(ProviderConfig.java:206) [rt.jar:1.8.0]
> at sun.security.jca.ProviderConfig.getProvider(ProviderConfig.java:187) [rt.jar:1.8.0]
> at sun.security.jca.ProviderList.loadAll(ProviderList.java:282) [rt.jar:1.8.0]
> at sun.security.jca.ProviderList.removeInvalid(ProviderList.java:299) [rt.jar:1.8.0]
> at sun.security.jca.Providers.getFullProviderList(Providers.java:173) [rt.jar:1.8.0]
> at java.security.Security.getProviders(Security.java:452) [rt.jar:1.8.0]
> at org.xnio.sasl.SaslUtils.getFactories(SaslUtils.java:121) [xnio-api-3.2.0.Final.jar:3.2.0.Final]
> at org.xnio.sasl.SaslUtils.getSaslServerFactories(SaslUtils.java:75) [xnio-api-3.2.0.Final.jar:3.2.0.Final]
> at org.jboss.remoting3.remote.ServerConnectionOpenListener$Initial.initialiseCapabilities(ServerConnectionOpenListener.java:165) [jboss-remoting-4.0.0.Final.jar:4.0.0.Final]
> at org.jboss.remoting3.remote.ServerConnectionOpenListener$Initial.sendCapabilities(ServerConnectionOpenListener.java:413) [jboss-remoting-4.0.0.Final.jar:4.0.0.Final]
> at org.jboss.remoting3.remote.ServerConnectionOpenListener$Initial.handleEvent(ServerConnectionOpenListener.java:260) [jboss-remoting-4.0.0.Final.jar:4.0.0.Final]
> at org.jboss.remoting3.remote.ServerConnectionOpenListener$Initial.handleEvent(ServerConnectionOpenListener.java:139) [jboss-remoting-4.0.0.Final.jar:4.0.0.Final]
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.2.0.Final.jar:3.2.0.Final]
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 5 months
[JBoss JIRA] (JBJCA-1159) ConnectionListener leaked if TSR throws IllegalStateException
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JBJCA-1159?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on JBJCA-1159:
------------------------------------------------
Carlo de Wolf <cdewolf(a)redhat.com> changed the Status of [bug 1088469|https://bugzilla.redhat.com/show_bug.cgi?id=1088469] from POST to MODIFIED
> ConnectionListener leaked if TSR throws IllegalStateException
> -------------------------------------------------------------
>
> Key: JBJCA-1159
> URL: https://issues.jboss.org/browse/JBJCA-1159
> Project: IronJacamar
> Issue Type: Bug
> Components: Core
> Affects Versions: 1.0.24.Final, 1.1.4.Final
> Environment: AS7 EAP6.1
> Reporter: Koen Janssens
> Assignee: Jesper Pedersen
> Priority: Blocker
> Fix For: 1.0.25.Final, 1.1.5.Final, 1.2.0.Beta1
>
>
> When a connection is retrieved from the MCP, ironjacamar will register it to ongoing JTA transaction. However, if the ongoing TX is not 'active' anymore the connection is lost.
> The code of AbstractPool demonstrates the problem. The call to getLock will throw an exception if the current TX is not active anymore and the cl is not returned to the pool.
> This issue can be reproduced on AS7 by using any EJB that requires a tx and does something with a DB connection. Put a breakpoint in the code below after retrieving the connectionlistener, and then wait for the transaction to timeout. Once that's done, continue the thread. The connection is not release (can be seen in JMX)
> We have noticed this problem regularly during our performance tests.
> {code}
> ConnectionListener cl = mcp.getConnection(subject, cri);
> if (trace)
> log.tracef("Got connection from pool tracked by transaction=%s tx=%s", cl, trackByTransaction);
> TransactionSynchronizationRegistry tsr = getTransactionSynchronizationRegistry();
> Lock lock = getLock();
> try
> {
> lock.lockInterruptibly();
> }
> catch (InterruptedException ie)
> {
> Thread.interrupted();
> throw new ResourceException(bundle.unableObtainLock(), ie);
> }
> {code}
> It seems this issue was introduced by changes done for https://issues.jboss.org/browse/JBJCA-572
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 5 months
[JBoss JIRA] (SECURITY-640) Jboss Negotiation fallback to login page if NTLM token is received or the user is not present in active directory.
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/SECURITY-640?page=com.atlassian.jira.plug... ]
RH Bugzilla Integration commented on SECURITY-640:
--------------------------------------------------
Carlo de Wolf <cdewolf(a)redhat.com> changed the Status of [bug 1085503|https://bugzilla.redhat.com/show_bug.cgi?id=1085503] from POST to MODIFIED
> Jboss Negotiation fallback to login page if NTLM token is received or the user is not present in active directory.
> ------------------------------------------------------------------------------------------------------------------
>
> Key: SECURITY-640
> URL: https://issues.jboss.org/browse/SECURITY-640
> Project: PicketBox
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Negotiation
> Environment: Active Directory Winwos 2003, Client Machine windows XP, Jboss Server Machine Window XP and Jboss 6.1
> Reporter: Hrishi Salvi
> Assignee: Derek Horton
> Fix For: Negotiation_2_2_8, Negotiation_2_3_0_CR2
>
>
> We are trying to configure the single sign on using jboss negotiation.
> We are able to login successfully if the user is present in active directory.
> But in case if user is not present in active directory users, it throw 401 error page.
> Instead of 401 we want user to access login form and authenticate user using different login module.
> In our case we have login page we authenticate user on that page.
> If we receive user credentials we login the user without asking for password.
> Now if the user credentials are not received then we want user to open login form present
> on login page, but before that is throws 401 error.
> We have configure the login-config.xml, web.xml and jboss-web.xml as per the documentation.
> Also defined
> <web-resource-collection>
> <web-resource-name>Restricted</web-resource-name>
> <url-pattern>/Request</url-pattern>
> <http-method>GET</http-method>
> <http-method>POST</http-method>
> </web-resource-collection>
> in web.xml
> Our application is access through Request servlet.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 5 months