You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@santuario.apache.org by "Scott Cantor (Jira)" <ji...@apache.org> on 2023/02/08 14:53:00 UTC
[jira] [Commented] (SANTUARIO-598) Secured webservices block if entropy is running low
[ https://issues.apache.org/jira/browse/SANTUARIO-598?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17685930#comment-17685930 ]
Scott Cantor commented on SANTUARIO-598:
----------------------------------------
The normal way to fix this is to point Java at /dev/urandom. There's a long and tortured history around all this, with mistakes by both Java and all the people who believe in blocking entropy sources in the kinds of environments where servers run.
What the library is doing is fine, and this isn't the best workaround for it.
> Secured webservices block if entropy is running low
> ---------------------------------------------------
>
> Key: SANTUARIO-598
> URL: https://issues.apache.org/jira/browse/SANTUARIO-598
> Project: Santuario
> Issue Type: Bug
> Components: Java
> Affects Versions: Java 3.0.1
> Reporter: Christian Kleinewaechter
> Assignee: Colm O hEigeartaigh
> Priority: Major
>
> In SANTUARIO-589 "Enable configurable RNG in initialization of XMlSecurityConstants" the RNG was not only made configurable, but the default also was changed from SHA1PRNG to the generator given by getInstanceStrong. At least on Linux systems, this defaults to NativePRNGBlocking, which blocks when entropy is running low. This can lead to stalled webservice calls.
> As a workaround, setting property org.apache.xml.security.securerandom.algorithm to SHA1PRNG gives back the old behaviour and avoids blocking calls. Blocking PRNGs might be useful for things like key generation on low entropy devices shortly after boot, its problematic for generating a high volume of random values.
> On Linux kernels >= 5.6, this probably isn't an issue, because /dev/random behaviour was changed then.
> Sample thread dump:
> {quote}"http-nio-8080-exec-1" - Thread t@24
> java.lang.Thread.State: BLOCKED
> at java.base@17.0.6/sun.security.provider.NativePRNG$RandomIO.implNextBytes(NativePRNG.java:547)
> - waiting to lock <577bfadd> (a java.lang.Object) owned by "http-nio-8080-exec-8" t@31
> at java.base@17.0.6/sun.security.provider.NativePRNG$Blocking.engineNextBytes(NativePRNG.java:269)
> at java.base@17.0.6/java.security.SecureRandom.nextBytes(SecureRandom.java:758)
> at org.apache.xml.security.stax.ext.XMLSecurityConstants.generateBytes(XMLSecurityConstants.java:85)
> at org.apache.wss4j.dom.util.WSSecurityUtil.generateNonce(WSSecurityUtil.java:644)
> at org.apache.wss4j.dom.message.token.UsernameToken.addNonce(UsernameToken.java:291)
> at org.apache.wss4j.dom.message.token.UsernameToken.<init>(UsernameToken.java:258)
> at org.apache.wss4j.dom.message.WSSecUsernameToken.prepare(WSSecUsernameToken.java:170)
> at org.apache.wss4j.dom.message.WSSecUsernameToken.build(WSSecUsernameToken.java:231)
> at org.apache.wss4j.dom.message.WSSecUsernameToken.build(WSSecUsernameToken.java:238)
> {quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)