Quantcast

Error "Attempt to use unapproved implementation in approved thread" on Tomcat 8.5.9 with SSL Enabled - With Default Mode FIPS Mode Unapproved.

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Error "Attempt to use unapproved implementation in approved thread" on Tomcat 8.5.9 with SSL Enabled - With Default Mode FIPS Mode Unapproved.

Ansari, Junaid

Hi All,

 

We are observing the following errors when using BC FIPS with SSL Enabled.

 

2017/02/10 18:08:29.949 | org.bouncycastle.crypto.fips.FipsUnapprovedOperationError: Attempt to use unapproved implementation in approved thread: SHA-1/HMAC

2017/02/10 18:08:29.949 |       at org.bouncycastle.crypto.internal.io.Utils.approvedModeCheck(Unknown Source)

2017/02/10 18:08:29.949 |       at org.bouncycastle.crypto.internal.io.MacOutputStream.write(Unknown Source)

2017/02/10 18:08:29.949 |       at org.bouncycastle.crypto.UpdateOutputStream.update(Unknown Source)

2017/02/10 18:08:29.949 |       at org.bouncycastle.jcajce.provider.BaseHMac.engineUpdate(Unknown Source)

2017/02/10 18:08:29.949 |       at javax.crypto.Mac.update(Mac.java:485)

2017/02/10 18:08:29.949 |       at sun.security.ssl.MAC.compute(MAC.java:160)

2017/02/10 18:08:29.949 |       at sun.security.ssl.EngineOutputRecord.write(EngineOutputRecord.java:262)

2017/02/10 18:08:29.949 |       at sun.security.ssl.EngineOutputRecord.write(EngineOutputRecord.java:225)

2017/02/10 18:08:29.949 |       at sun.security.ssl.EngineWriter.writeRecord(EngineWriter.java:186)

2017/02/10 18:08:29.949 |       at sun.security.ssl.SSLEngineImpl.writeRecord(SSLEngineImpl.java:1300)

2017/02/10 18:08:29.949 |       at sun.security.ssl.SSLEngineImpl.writeAppRecord(SSLEngineImpl.java:1271)

2017/02/10 18:08:29.949 |       at sun.security.ssl.SSLEngineImpl.wrap(SSLEngineImpl.java:1186)

2017/02/10 18:08:29.949 |       at javax.net.ssl.SSLEngine.wrap(SSLEngine.java:469)

2017/02/10 18:08:29.949 |       at org.apache.tomcat.util.net.SecureNioChannel.write(SecureNioChannel.java:639)

2017/02/10 18:08:29.949 |       at org.apache.tomcat.util.net.NioBlockingSelector.write(NioBlockingSelector.java:101)

2017/02/10 18:08:29.950 |       at org.apache.tomcat.util.net.NioSelectorPool.write(NioSelectorPool.java:157)

2017/02/10 18:08:29.950 |       at org.apache.tomcat.util.net.NioEndpoint$NioSocketWrapper.doWrite(NioEndpoint.java:1241)

2017/02/10 18:08:29.950 |       at org.apache.tomcat.util.net.SocketWrapperBase.doWrite(SocketWrapperBase.java:670)

2017/02/10 18:08:29.950 |       at org.apache.tomcat.util.net.SocketWrapperBase.flushBlocking(SocketWrapperBase.java:607)

2017/02/10 18:08:29.950 |       at org.apache.tomcat.util.net.SocketWrapperBase.flush(SocketWrapperBase.java:597)

2017/02/10 18:08:29.950 |       at org.apache.coyote.http11.Http11OutputBuffer.flushBuffer(Http11OutputBuffer.java:519)

2017/02/10 18:08:29.950 |       at org.apache.coyote.http11.Http11OutputBuffer.finishResponse(Http11OutputBuffer.java:318)

2017/02/10 18:08:29.950 |       at org.apache.coyote.http11.Http11Processor.finishResponse(Http11Processor.java:1472)

2017/02/10 18:08:29.950 |       at org.apache.coyote.AbstractProcessor.action(AbstractProcessor.java:264)

2017/02/10 18:08:29.950 |       at org.apache.coyote.Response.action(Response.java:168)

2017/02/10 18:08:29.950 |       at org.apache.catalina.connector.OutputBuffer.close(OutputBuffer.java:273)

2017/02/10 18:08:29.950 |       at org.apache.catalina.connector.Response.finishResponse(Response.java:484)

2017/02/10 18:08:29.950 |       at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:379)

2017/02/10 18:08:29.950 |       at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:783)

2017/02/10 18:08:29.950 |       at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66)

2017/02/10 18:08:29.950 |       at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:789)

2017/02/10 18:08:29.950 |       at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1437)

2017/02/10 18:08:29.950 |       at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)

2017/02/10 18:08:29.950 |       at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)

2017/02/10 18:08:29.950 |       at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)

2017/02/10 18:08:29.951 |       at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)

2017/02/10 18:08:29.951 |       at java.lang.Thread.run(Thread.java:745)

2017/02/10 18:08:29.951 |

 

Other error which appear to be of same nature…

 

2017/02/21 13:05:19.966 | org.bouncycastle.crypto.fips.FipsUnapprovedOperationError: Attempt to use unapproved implementation in approved thread: SHA-256

2017/02/21 13:05:19.966 |         at org.bouncycastle.crypto.internal.io.Utils.approvedModeCheck(Unknown Source)

2017/02/21 13:05:19.966 |        at org.bouncycastle.crypto.internal.io.DigestOutputStream.write(Unknown Source)

2017/02/21 13:05:19.982 |        at org.bouncycastle.crypto.UpdateOutputStream.update(Unknown Source)

2017/02/21 13:05:19.982 |        at org.bouncycastle.jcajce.provider.BaseMessageDigest.engineUpdate(Unknown Source)

2017/02/21 13:05:19.998 |        at java.security.MessageDigest.update(MessageDigest.java:325)

2017/02/21 13:05:19.998 |        at sun.security.ssl.HandshakeHash.update(HandshakeHash.java:118)

2017/02/21 13:05:19.998 |        at sun.security.ssl.InputRecord.hashInternal(InputRecord.java:370)

2017/02/21 13:05:19.998 |        at sun.security.ssl.InputRecord.doHashes(InputRecord.java:351)

2017/02/21 13:05:20.013 |        at sun.security.ssl.HandshakeInStream.digestNow(HandshakeInStream.java:157)

2017/02/21 13:05:20.013 |        at sun.security.ssl.Handshaker.processLoop(Handshaker.java:980)

2017/02/21 13:05:20.013 |        at sun.security.ssl.Handshaker.process_record(Handshaker.java:914)

2017/02/21 13:05:20.013 |        at sun.security.ssl.SSLEngineImpl.readRecord(SSLEngineImpl.java:1025)

2017/02/21 13:05:20.029 |        at sun.security.ssl.SSLEngineImpl.readNetRecord(SSLEngineImpl.java:907)

2017/02/21 13:05:20.029 |        at sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:781)

2017/02/21 13:05:20.044 |        at javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:624)

2017/02/21 13:05:20.044 |        at org.apache.tomcat.util.net.SecureNioChannel.handshakeUnwrap(SecureNioChannel.java:335)

2017/02/21 13:05:20.044 |        at org.apache.tomcat.util.net.SecureNioChannel.handshake(SecureNioChannel.java:192)

2017/02/21 13:05:20.044 |        at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1534)

2017/02/21 13:05:20.060 |        at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1515)

2017/02/21 13:05:20.060 |        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)

2017/02/21 13:05:20.076 |        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)

2017/02/21 13:05:20.091 |        at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)

2017/02/21 13:05:20.107 |        at java.lang.Thread.run(Thread.java:745)

2017/02/21 13:05:20.107 |

 

Our usage of BC FIPS and sequence of events leading to error described below:

 

1.       In the servlet init()

a.       Add Bouncy Castle FIPS Provider to the top of providers list.

b.       Set the approved mode to be true.

c.       Create and store cipher for encryption.

2.       By the time steps in #1 are done, we also start another monitoring thread which does some encryption.

a.       This thread starts in approved mode (as the provider wasn’t yet added to the top of the list).

But before doing any encryption checks for BC FIPS Provider and if available at the top of the list moves the thread to approved mode.

This ensure that when this thread uses the Cipher created in #1.c does not fail with “Attempt to use approved implementation in unapproved thread” error. Solved.

So, far so good.

 

However, the error we are now seeing is a different scenario.

 

From what I see in, it appears the error happens cryptographic operation is performed in a thread whose approved mode was set to true is while the MacOutputStream/DigestOutputStream being used has the approved mode set as false. org.bouncycastle.crypto.internal.io.Utils.approvedModeCheck() is where it is failing.

 

From the CTOR of MacOutputStream/DigestOutputStream, their approved mode is inferred from the CryptoServicesRegistrar.isInApprovedOnlyMode().

 

In our case, for that particular instance of MacOutputStream/DigestOutputStream appears to set approved mode as false (default mode being ‘false’ and the thread fips mode not available).

 

It appears this instance of MacOutputStream/DigestOutputStream with approved mode as false is now being reused, when calculating mac/digest in approved thread and fails with “Attempt to use unapproved implementation in approved thread”

 

Note:

Our web app does not run with any security manager and to use BC FIPS by default in approved mode we know we shouldn’t grant “unapprovedModeEnabled” permission.

That is not an option for us, as the app fails to start due to other missing permission required by the app and we would have to identify each and every permission our ‘app’ requires (the list of permission our app require isn’t definitive)

 

Any inputs on what could be the next steps to resolve the issue are highly appreciated.

 

Thanks

Junaid

 

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Error "Attempt to use unapproved implementation in approved thread" on Tomcat 8.5.9 with SSL Enabled - With Default Mode FIPS Mode Unapproved.

David Hook-3

Hi Junaid,

This will happen where CSPs are shared across threads of different modes.

Regards,

David

On 23/02/17 00:07, Ansari, Junaid wrote:

Hi All,

 

We are observing the following errors when using BC FIPS with SSL Enabled.

 

2017/02/10 18:08:29.949 | org.bouncycastle.crypto.fips.FipsUnapprovedOperationError: Attempt to use unapproved implementation in approved thread: SHA-1/HMAC

2017/02/10 18:08:29.949 |       at org.bouncycastle.crypto.internal.io.Utils.approvedModeCheck(Unknown Source)

2017/02/10 18:08:29.949 |       at org.bouncycastle.crypto.internal.io.MacOutputStream.write(Unknown Source)

2017/02/10 18:08:29.949 |       at org.bouncycastle.crypto.UpdateOutputStream.update(Unknown Source)

2017/02/10 18:08:29.949 |       at org.bouncycastle.jcajce.provider.BaseHMac.engineUpdate(Unknown Source)

2017/02/10 18:08:29.949 |       at javax.crypto.Mac.update(Mac.java:485)

2017/02/10 18:08:29.949 |       at sun.security.ssl.MAC.compute(MAC.java:160)

2017/02/10 18:08:29.949 |       at sun.security.ssl.EngineOutputRecord.write(EngineOutputRecord.java:262)

2017/02/10 18:08:29.949 |       at sun.security.ssl.EngineOutputRecord.write(EngineOutputRecord.java:225)

2017/02/10 18:08:29.949 |       at sun.security.ssl.EngineWriter.writeRecord(EngineWriter.java:186)

2017/02/10 18:08:29.949 |       at sun.security.ssl.SSLEngineImpl.writeRecord(SSLEngineImpl.java:1300)

2017/02/10 18:08:29.949 |       at sun.security.ssl.SSLEngineImpl.writeAppRecord(SSLEngineImpl.java:1271)

2017/02/10 18:08:29.949 |       at sun.security.ssl.SSLEngineImpl.wrap(SSLEngineImpl.java:1186)

2017/02/10 18:08:29.949 |       at javax.net.ssl.SSLEngine.wrap(SSLEngine.java:469)

2017/02/10 18:08:29.949 |       at org.apache.tomcat.util.net.SecureNioChannel.write(SecureNioChannel.java:639)

2017/02/10 18:08:29.949 |       at org.apache.tomcat.util.net.NioBlockingSelector.write(NioBlockingSelector.java:101)

2017/02/10 18:08:29.950 |       at org.apache.tomcat.util.net.NioSelectorPool.write(NioSelectorPool.java:157)

2017/02/10 18:08:29.950 |       at org.apache.tomcat.util.net.NioEndpoint$NioSocketWrapper.doWrite(NioEndpoint.java:1241)

2017/02/10 18:08:29.950 |       at org.apache.tomcat.util.net.SocketWrapperBase.doWrite(SocketWrapperBase.java:670)

2017/02/10 18:08:29.950 |       at org.apache.tomcat.util.net.SocketWrapperBase.flushBlocking(SocketWrapperBase.java:607)

2017/02/10 18:08:29.950 |       at org.apache.tomcat.util.net.SocketWrapperBase.flush(SocketWrapperBase.java:597)

2017/02/10 18:08:29.950 |       at org.apache.coyote.http11.Http11OutputBuffer.flushBuffer(Http11OutputBuffer.java:519)

2017/02/10 18:08:29.950 |       at org.apache.coyote.http11.Http11OutputBuffer.finishResponse(Http11OutputBuffer.java:318)

2017/02/10 18:08:29.950 |       at org.apache.coyote.http11.Http11Processor.finishResponse(Http11Processor.java:1472)

2017/02/10 18:08:29.950 |       at org.apache.coyote.AbstractProcessor.action(AbstractProcessor.java:264)

2017/02/10 18:08:29.950 |       at org.apache.coyote.Response.action(Response.java:168)

2017/02/10 18:08:29.950 |       at org.apache.catalina.connector.OutputBuffer.close(OutputBuffer.java:273)

2017/02/10 18:08:29.950 |       at org.apache.catalina.connector.Response.finishResponse(Response.java:484)

2017/02/10 18:08:29.950 |       at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:379)

2017/02/10 18:08:29.950 |       at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:783)

2017/02/10 18:08:29.950 |       at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66)

2017/02/10 18:08:29.950 |       at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:789)

2017/02/10 18:08:29.950 |       at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1437)

2017/02/10 18:08:29.950 |       at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)

2017/02/10 18:08:29.950 |       at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)

2017/02/10 18:08:29.950 |       at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)

2017/02/10 18:08:29.951 |       at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)

2017/02/10 18:08:29.951 |       at java.lang.Thread.run(Thread.java:745)

2017/02/10 18:08:29.951 |

 

Other error which appear to be of same nature…

 

2017/02/21 13:05:19.966 | org.bouncycastle.crypto.fips.FipsUnapprovedOperationError: Attempt to use unapproved implementation in approved thread: SHA-256

2017/02/21 13:05:19.966 |         at org.bouncycastle.crypto.internal.io.Utils.approvedModeCheck(Unknown Source)

2017/02/21 13:05:19.966 |        at org.bouncycastle.crypto.internal.io.DigestOutputStream.write(Unknown Source)

2017/02/21 13:05:19.982 |        at org.bouncycastle.crypto.UpdateOutputStream.update(Unknown Source)

2017/02/21 13:05:19.982 |        at org.bouncycastle.jcajce.provider.BaseMessageDigest.engineUpdate(Unknown Source)

2017/02/21 13:05:19.998 |        at java.security.MessageDigest.update(MessageDigest.java:325)

2017/02/21 13:05:19.998 |        at sun.security.ssl.HandshakeHash.update(HandshakeHash.java:118)

2017/02/21 13:05:19.998 |        at sun.security.ssl.InputRecord.hashInternal(InputRecord.java:370)

2017/02/21 13:05:19.998 |        at sun.security.ssl.InputRecord.doHashes(InputRecord.java:351)

2017/02/21 13:05:20.013 |        at sun.security.ssl.HandshakeInStream.digestNow(HandshakeInStream.java:157)

2017/02/21 13:05:20.013 |        at sun.security.ssl.Handshaker.processLoop(Handshaker.java:980)

2017/02/21 13:05:20.013 |        at sun.security.ssl.Handshaker.process_record(Handshaker.java:914)

2017/02/21 13:05:20.013 |        at sun.security.ssl.SSLEngineImpl.readRecord(SSLEngineImpl.java:1025)

2017/02/21 13:05:20.029 |        at sun.security.ssl.SSLEngineImpl.readNetRecord(SSLEngineImpl.java:907)

2017/02/21 13:05:20.029 |        at sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:781)

2017/02/21 13:05:20.044 |        at javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:624)

2017/02/21 13:05:20.044 |        at org.apache.tomcat.util.net.SecureNioChannel.handshakeUnwrap(SecureNioChannel.java:335)

2017/02/21 13:05:20.044 |        at org.apache.tomcat.util.net.SecureNioChannel.handshake(SecureNioChannel.java:192)

2017/02/21 13:05:20.044 |        at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1534)

2017/02/21 13:05:20.060 |        at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1515)

2017/02/21 13:05:20.060 |        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)

2017/02/21 13:05:20.076 |        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)

2017/02/21 13:05:20.091 |        at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)

2017/02/21 13:05:20.107 |        at java.lang.Thread.run(Thread.java:745)

2017/02/21 13:05:20.107 |

 

Our usage of BC FIPS and sequence of events leading to error described below:

 

1.       In the servlet init()

a.       Add Bouncy Castle FIPS Provider to the top of providers list.

b.       Set the approved mode to be true.

c.       Create and store cipher for encryption.

2.       By the time steps in #1 are done, we also start another monitoring thread which does some encryption.

a.       This thread starts in approved mode (as the provider wasn’t yet added to the top of the list).

But before doing any encryption checks for BC FIPS Provider and if available at the top of the list moves the thread to approved mode.

This ensure that when this thread uses the Cipher created in #1.c does not fail with “Attempt to use approved implementation in unapproved thread” error. Solved.

So, far so good.

 

However, the error we are now seeing is a different scenario.

 

From what I see in, it appears the error happens cryptographic operation is performed in a thread whose approved mode was set to true is while the MacOutputStream/DigestOutputStream being used has the approved mode set as false. org.bouncycastle.crypto.internal.io.Utils.approvedModeCheck() is where it is failing.

 

From the CTOR of MacOutputStream/DigestOutputStream, their approved mode is inferred from the CryptoServicesRegistrar.isInApprovedOnlyMode().

 

In our case, for that particular instance of MacOutputStream/DigestOutputStream appears to set approved mode as false (default mode being ‘false’ and the thread fips mode not available).

 

It appears this instance of MacOutputStream/DigestOutputStream with approved mode as false is now being reused, when calculating mac/digest in approved thread and fails with “Attempt to use unapproved implementation in approved thread”

 

Note:

Our web app does not run with any security manager and to use BC FIPS by default in approved mode we know we shouldn’t grant “unapprovedModeEnabled” permission.

That is not an option for us, as the app fails to start due to other missing permission required by the app and we would have to identify each and every permission our ‘app’ requires (the list of permission our app require isn’t definitive)

 

Any inputs on what could be the next steps to resolve the issue are highly appreciated.

 

Thanks

Junaid

 


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Error "Attempt to use unapproved implementation in approved thread" on Tomcat 8.5.9 with SSL Enabled - With Default Mode FIPS Mode Unapproved.

David Hook-3

CSP is "critical security parameters" NIST use it to describe the private/secret keys and the internal state of ciphers and other operators.

In this case it appears one created in approved mode is being used by a thread not in approved mode.

The only solution in to stopping something like this is to have all threads running in approved mode - as far as configuration goes for 1.0.0 the only way to do this is via the security manager. 1.0.1 also has a system property which forces approved mode only on the executing application, from the sound of it this would solve your problem.

Regards,

David

On 23/02/17 15:13, Ansari, Junaid wrote:
Hi David,

I didn’t exactly get what you meant by “CSPs are shared across threads of different modes”.

When would the above happen or how can I avoid it from happening. Could you please point how to resolve this?

Again re-iterating our scenario with SOME MORE details and a small correction… may be it will help throw some light

Our usage of BC FIPS and sequence of events leading to error described below:


1.       In the servlet init()

a.       Add Bouncy Castle FIPS Provider to the top of providers list.

b.       Set the approved mode to be true.

c.       Create and store cipher for encryption.

2.       By the time steps in #1 are done, we also start another monitoring thread which does some encryption.

a.       This thread starts in unapproved mode (as the provider wasn’t yet added to the top of the list).

But before doing any encryption checks for BC FIPS Provider and if available at the top of the list moves the thread to approved mode.

This ensure that when this thread uses the Cipher created in #1.c does not fail with “Attempt to use approved implementation in unapproved thread” error. Solved.

So, far so good.

 

However, the error we are now seeing is a different scenario.

 

After step 2 i.e the application is initiliazed and Bouncy Castle is added to the top of the providers list


User tries to login to the web app, the thread (tomcat worker thread) is in unapproved mode but before doing authentication (encryption/hashing) we call CryptoServicesRegistrar.setApprovedOnlyMode(true) to move it to approved mode the user is authenticated but when the response is returned. The error occurs at the tomcat-browser layer when trying to write the response.

From what I see in, it appears the error happens cryptographic operation is performed in a thread whose approved mode was set to true is while the MacOutputStream/DigestOutputStream being used has the approved mode set as false. org.bouncycastle.crypto.internal.io.Utils.approvedModeCheck() is where it is failing.

 

From the CTOR of MacOutputStream/DigestOutputStream, their approved mode is inferred from the CryptoServicesRegistrar.isInApprovedOnlyMode().

 

In our case, for that particular instance of MacOutputStream/DigestOutputStream appears to set approved mode as false (default mode being ‘false’ and the thread fips mode not available).

 

It appears this instance of MacOutputStream/DigestOutputStream with approved mode as false is now being reused, when calculating mac/digest in approved thread and fails with “Attempt to use unapproved implementation in approved thread”


Thanks
Junaid

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Error "Attempt to use unapproved implementation in approved thread" on Tomcat 8.5.9 with SSL Enabled - With Default Mode FIPS Mode Unapproved.

Ansari, Junaid
Hi David,

The error being "Attempt to use unapproved implementation in approved thread: SHA-1/HMAC"

In this case it appears one created in approved mode is being used by a thread not in approved mode.

I guess you meant to say “In this case it appears one created in UNapproved mode is being used by a thread not in approved mode.” Right?

Thanks
Junaid
From: David Hook <[hidden email]>
Date: Thursday, 23 February 2017 at 10:01 AM
To: "Ansari, Junaid" <[hidden email]>, "[hidden email]" <[hidden email]>
Cc: "Kamal, Murali" <[hidden email]>
Subject: Re: [dev-crypto] Error "Attempt to use unapproved implementation in approved thread" on Tomcat 8.5.9 with SSL Enabled - With Default Mode FIPS Mode Unapproved.


CSP is "critical security parameters" NIST use it to describe the private/secret keys and the internal state of ciphers and other operators.

In this case it appears one created in approved mode is being used by a thread not in approved mode.

The only solution in to stopping something like this is to have all threads running in approved mode - as far as configuration goes for 1.0.0 the only way to do this is via the security manager. 1.0.1 also has a system property which forces approved mode only on the executing application, from the sound of it this would solve your problem.

Regards,

David

On 23/02/17 15:13, Ansari, Junaid wrote:
Hi David,

I didn’t exactly get what you meant by “CSPs are shared across threads of different modes”.

When would the above happen or how can I avoid it from happening. Could you please point how to resolve this?

Again re-iterating our scenario with SOME MORE details and a small correction… may be it will help throw some light

Our usage of BC FIPS and sequence of events leading to error described below:


1.       In the servlet init()

a.       Add Bouncy Castle FIPS Provider to the top of providers list.

b.       Set the approved mode to be true.

c.       Create and store cipher for encryption.

2.       By the time steps in #1 are done, we also start another monitoring thread which does some encryption.

a.       This thread starts in unapproved mode (as the provider wasn’t yet added to the top of the list).

But before doing any encryption checks for BC FIPS Provider and if available at the top of the list moves the thread to approved mode.

This ensure that when this thread uses the Cipher created in #1.c does not fail with “Attempt to use approved implementation in unapproved thread” error. Solved.

So, far so good.

 

However, the error we are now seeing is a different scenario.

 

After step 2 i.e the application is initiliazed and Bouncy Castle is added to the top of the providers list


User tries to login to the web app, the thread (tomcat worker thread) is in unapproved mode but before doing authentication (encryption/hashing) we call CryptoServicesRegistrar.setApprovedOnlyMode(true) to move it to approved mode the user is authenticated but when the response is returned. The error occurs at the tomcat-browser layer when trying to write the response.

From what I see in, it appears the error happens cryptographic operation is performed in a thread whose approved mode was set to true is while the MacOutputStream/DigestOutputStream being used has the approved mode set as false. org.bouncycastle.crypto.internal.io.Utils.approvedModeCheck() is where it is failing.

 

From the CTOR of MacOutputStream/DigestOutputStream, their approved mode is inferred from the CryptoServicesRegistrar.isInApprovedOnlyMode().

 

In our case, for that particular instance of MacOutputStream/DigestOutputStream appears to set approved mode as false (default mode being ‘false’ and the thread fips mode not available).

 

It appears this instance of MacOutputStream/DigestOutputStream with approved mode as false is now being reused, when calculating mac/digest in approved thread and fails with “Attempt to use unapproved implementation in approved thread”


Thanks
Junaid

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Error "Attempt to use unapproved implementation in approved thread" on Tomcat 8.5.9 with SSL Enabled - With Default Mode FIPS Mode Unapproved.

Ansari, Junaid
Another thing that is unexplained is…

We no code change, if I change the Tomcat HTTP Cconnector (SSL enabled) allowed Cipher Suites list from below to “TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256”,
it works fine in Chrome and Firefox but not IE11.

<Connector port="8043" redirectPort="80" secure="true" SSLEnabled="true" sslProtocol="TLS" sslEnabledProtocols="TLSv1.2,TLSv1.1,TLSv1" connectionTimeout="86400000" maxThreads="200" minSpareThreads="1" maxHttpHeaderSize="65536" keystoreFile="..\config\mykeystore.jks" keystorePass="*********" ciphers="TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_3DES_EDE_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_DES_CBC_SHA,SSL_RSA_WITH_DES_CBC_SHA,SSL_RSA_FIPS_WITH_DES_CBC_SHA,SSL_RSA_WITH_3DES_EDE_CBC_SHA,SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA,SSL_RSA_WITH_AES_128_CBC_SHA" enableLookups="false" disableUploadTimeout="true" acceptCount="100" scheme="https" clientAuth="false" URIEncoding="UTF-8" useBodyEncodingForURI="true" server="DUMMY" />

CHANGED TO:

<Connector port="8043" redirectPort="80" secure="true" SSLEnabled="true" sslProtocol="TLS" sslEnabledProtocols="TLSv1.2,TLSv1.1,TLSv1" connectionTimeout="86400000" maxThreads="200" minSpareThreads="1" maxHttpHeaderSize="65536" keystoreFile="..\config\mykeystore.jks" keystorePass="*********" ciphers=“TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256” enableLookups="false" disableUploadTimeout="true" acceptCount="100" scheme="https" clientAuth="false" URIEncoding="UTF-8" useBodyEncodingForURI="true" server="DUMMY" />

Thanks
Junaid

From: "Ansari, Junaid" <[hidden email]>
Date: Thursday, 23 February 2017 at 11:26 AM
To: David Hook <[hidden email]>, "[hidden email]" <[hidden email]>
Cc: "Kamal, Murali" <[hidden email]>
Subject: Re: [dev-crypto] Error "Attempt to use unapproved implementation in approved thread" on Tomcat 8.5.9 with SSL Enabled - With Default Mode FIPS Mode Unapproved.

Hi David,

The error being "Attempt to use unapproved implementation in approved thread: SHA-1/HMAC"

In this case it appears one created in approved mode is being used by a thread not in approved mode.

I guess you meant to say “In this case it appears one created in UNapproved mode is being used by a thread not in approved mode.” Right?

Thanks
Junaid
From: David Hook <[hidden email]>
Date: Thursday, 23 February 2017 at 10:01 AM
To: "Ansari, Junaid" <[hidden email]>, "[hidden email]" <[hidden email]>
Cc: "Kamal, Murali" <[hidden email]>
Subject: Re: [dev-crypto] Error "Attempt to use unapproved implementation in approved thread" on Tomcat 8.5.9 with SSL Enabled - With Default Mode FIPS Mode Unapproved.


CSP is "critical security parameters" NIST use it to describe the private/secret keys and the internal state of ciphers and other operators.

In this case it appears one created in approved mode is being used by a thread not in approved mode.

The only solution in to stopping something like this is to have all threads running in approved mode - as far as configuration goes for 1.0.0 the only way to do this is via the security manager. 1.0.1 also has a system property which forces approved mode only on the executing application, from the sound of it this would solve your problem.

Regards,

David

On 23/02/17 15:13, Ansari, Junaid wrote:
Hi David,

I didn’t exactly get what you meant by “CSPs are shared across threads of different modes”.

When would the above happen or how can I avoid it from happening. Could you please point how to resolve this?

Again re-iterating our scenario with SOME MORE details and a small correction… may be it will help throw some light

Our usage of BC FIPS and sequence of events leading to error described below:


1.       In the servlet init()

a.       Add Bouncy Castle FIPS Provider to the top of providers list.

b.       Set the approved mode to be true.

c.       Create and store cipher for encryption.

2.       By the time steps in #1 are done, we also start another monitoring thread which does some encryption.

a.       This thread starts in unapproved mode (as the provider wasn’t yet added to the top of the list).

But before doing any encryption checks for BC FIPS Provider and if available at the top of the list moves the thread to approved mode.

This ensure that when this thread uses the Cipher created in #1.c does not fail with “Attempt to use approved implementation in unapproved thread” error. Solved.

So, far so good.

 

However, the error we are now seeing is a different scenario.

 

After step 2 i.e the application is initiliazed and Bouncy Castle is added to the top of the providers list


User tries to login to the web app, the thread (tomcat worker thread) is in unapproved mode but before doing authentication (encryption/hashing) we call CryptoServicesRegistrar.setApprovedOnlyMode(true) to move it to approved mode the user is authenticated but when the response is returned. The error occurs at the tomcat-browser layer when trying to write the response.

From what I see in, it appears the error happens cryptographic operation is performed in a thread whose approved mode was set to true is while the MacOutputStream/DigestOutputStream being used has the approved mode set as false. org.bouncycastle.crypto.internal.io.Utils.approvedModeCheck() is where it is failing.

 

From the CTOR of MacOutputStream/DigestOutputStream, their approved mode is inferred from the CryptoServicesRegistrar.isInApprovedOnlyMode().

 

In our case, for that particular instance of MacOutputStream/DigestOutputStream appears to set approved mode as false (default mode being ‘false’ and the thread fips mode not available).

 

It appears this instance of MacOutputStream/DigestOutputStream with approved mode as false is now being reused, when calculating mac/digest in approved thread and fails with “Attempt to use unapproved implementation in approved thread”


Thanks
Junaid

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Error "Attempt to use unapproved implementation in approved thread" on Tomcat 8.5.9 with SSL Enabled - With Default Mode FIPS Mode Unapproved.

David Hook-3
In reply to this post by Ansari, Junaid

Sort of. Either way it's actually the same result. CSPs cannot be passed across the "approved mode" boundary in either direction.

Regards,

David

On 23/02/17 16:53, Ansari, Junaid wrote:
Hi David,

The error being "Attempt to use unapproved implementation in approved thread: SHA-1/HMAC"

In this case it appears one created in approved mode is being used by a thread not in approved mode.

I guess you meant to say “In this case it appears one created in UNapproved mode is being used by a thread not in approved mode.” Right?

Thanks
Junaid
From: David Hook <[hidden email]>
Date: Thursday, 23 February 2017 at 10:01 AM
To: "Ansari, Junaid" <[hidden email]>, "[hidden email]" <[hidden email]>
Cc: "Kamal, Murali" <[hidden email]>
Subject: Re: [dev-crypto] Error "Attempt to use unapproved implementation in approved thread" on Tomcat 8.5.9 with SSL Enabled - With Default Mode FIPS Mode Unapproved.


CSP is "critical security parameters" NIST use it to describe the private/secret keys and the internal state of ciphers and other operators.

In this case it appears one created in approved mode is being used by a thread not in approved mode.

The only solution in to stopping something like this is to have all threads running in approved mode - as far as configuration goes for 1.0.0 the only way to do this is via the security manager. 1.0.1 also has a system property which forces approved mode only on the executing application, from the sound of it this would solve your problem.

Regards,

David

On 23/02/17 15:13, Ansari, Junaid wrote:
Hi David,

I didn’t exactly get what you meant by “CSPs are shared across threads of different modes”.

When would the above happen or how can I avoid it from happening. Could you please point how to resolve this?

Again re-iterating our scenario with SOME MORE details and a small correction… may be it will help throw some light

Our usage of BC FIPS and sequence of events leading to error described below:


1.       In the servlet init()

a.       Add Bouncy Castle FIPS Provider to the top of providers list.

b.       Set the approved mode to be true.

c.       Create and store cipher for encryption.

2.       By the time steps in #1 are done, we also start another monitoring thread which does some encryption.

a.       This thread starts in unapproved mode (as the provider wasn’t yet added to the top of the list).

But before doing any encryption checks for BC FIPS Provider and if available at the top of the list moves the thread to approved mode.

This ensure that when this thread uses the Cipher created in #1.c does not fail with “Attempt to use approved implementation in unapproved thread” error. Solved.

So, far so good.

 

However, the error we are now seeing is a different scenario.

 

After step 2 i.e the application is initiliazed and Bouncy Castle is added to the top of the providers list


User tries to login to the web app, the thread (tomcat worker thread) is in unapproved mode but before doing authentication (encryption/hashing) we call CryptoServicesRegistrar.setApprovedOnlyMode(true) to move it to approved mode the user is authenticated but when the response is returned. The error occurs at the tomcat-browser layer when trying to write the response.

From what I see in, it appears the error happens cryptographic operation is performed in a thread whose approved mode was set to true is while the MacOutputStream/DigestOutputStream being used has the approved mode set as false. org.bouncycastle.crypto.internal.io.Utils.approvedModeCheck() is where it is failing.

 

From the CTOR of MacOutputStream/DigestOutputStream, their approved mode is inferred from the CryptoServicesRegistrar.isInApprovedOnlyMode().

 

In our case, for that particular instance of MacOutputStream/DigestOutputStream appears to set approved mode as false (default mode being ‘false’ and the thread fips mode not available).

 

It appears this instance of MacOutputStream/DigestOutputStream with approved mode as false is now being reused, when calculating mac/digest in approved thread and fails with “Attempt to use unapproved implementation in approved thread”


Thanks
Junaid


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Error "Attempt to use unapproved implementation in approved thread" on Tomcat 8.5.9 with SSL Enabled - With Default Mode FIPS Mode Unapproved.

David Hook-3
In reply to this post by Ansari, Junaid

Hi Junaid,

I think it's a question of how the JSSE provider does things internally - there are somethings where it pre-allocates message digests on start up in other situations it creates signers and CSPs on request. My guess is that the set up phase is probably the one allocating objects not in approved mode and then it depends what code path is used to do the negotiation with the browser as to whether one of the "time bomb" objects gets invoked in the wrong mode. If you could add the JSSE provider by hand in code you would probably be able to get around this but I think in this case, the 1.0.1 release is probably your only safe option if you do not wish to use a SecurityManager.

Regards,

David

On 28/02/17 01:11, Ansari, Junaid wrote:

Hi David,

 

It doesn’t make sense to me on why changing the CIPHER SUITES list does not cause the error and there is no code change compared to previous error scenario.

In this case too all the thread starts in “unapproved” mode and are later moved into “approved” state, but we don’t see any issue here.

 

Is it discouraged to change the threads “FIPS” mode to approved and rather use Security Manager approach to start in approved mode?

 

I think there is something going wrong here which causes CSPs created in unapproved mode being used by threads which are in approved mode.

 

Thanks

Junaid

 

From: Ansari, Junaid
Sent: Thursday, February 23, 2017 11:33 AM
To: David Hook [hidden email]; [hidden email]
Cc: Kamal, Murali [hidden email]
Subject: Re: [dev-crypto] Error "Attempt to use unapproved implementation in approved thread" on Tomcat 8.5.9 with SSL Enabled - With Default Mode FIPS Mode Unapproved.

 

Another thing that is unexplained is…

 

We no code change, if I change the Tomcat HTTP Cconnector (SSL enabled) allowed Cipher Suites list from below to “TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256”,

it works fine in Chrome and Firefox but not IE11.

 

<Connector port="8043" redirectPort="80" secure="true" SSLEnabled="true" sslProtocol="TLS" sslEnabledProtocols="TLSv1.2,TLSv1.1,TLSv1" connectionTimeout="86400000" maxThreads="200" minSpareThreads="1" maxHttpHeaderSize="65536" keystoreFile="..\config\mykeystore.jks" keystorePass="*********" ciphers="TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_3DES_EDE_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_DES_CBC_SHA,SSL_RSA_WITH_DES_CBC_SHA,SSL_RSA_FIPS_WITH_DES_CBC_SHA,SSL_RSA_WITH_3DES_EDE_CBC_SHA,SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA,SSL_RSA_WITH_AES_128_CBC_SHA" enableLookups="false" disableUploadTimeout="true" acceptCount="100" scheme="https" clientAuth="false" URIEncoding="UTF-8" useBodyEncodingForURI="true" server="DUMMY" />

 

CHANGED TO:

 

<Connector port="8043" redirectPort="80" secure="true" SSLEnabled="true" sslProtocol="TLS" sslEnabledProtocols="TLSv1.2,TLSv1.1,TLSv1" connectionTimeout="86400000" maxThreads="200" minSpareThreads="1" maxHttpHeaderSize="65536" keystoreFile="..\config\mykeystore.jks" keystorePass="*********" ciphers=“TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256” enableLookups="false" disableUploadTimeout="true" acceptCount="100" scheme="https" clientAuth="false" URIEncoding="UTF-8" useBodyEncodingForURI="true" server="DUMMY" />

 

Thanks

Junaid

 

From: "Ansari, Junaid" <[hidden email]>
Date: Thursday, 23 February 2017 at 11:26 AM
To: David Hook <[hidden email]>, "[hidden email]" <[hidden email]>
Cc: "Kamal, Murali" <[hidden email]>
Subject: Re: [dev-crypto] Error "Attempt to use unapproved implementation in approved thread" on Tomcat 8.5.9 with SSL Enabled - With Default Mode FIPS Mode Unapproved.

 

Hi David,

 

The error being "Attempt to use unapproved implementation in approved thread: SHA-1/HMAC"

 

In this case it appears one created in approved mode is being used by a thread not in approved mode.

 

I guess you meant to say “In this case it appears one created in UNapproved mode is being used by a thread not in approved mode.” Right?

 

Thanks

Junaid

From: David Hook <[hidden email]>
Date: Thursday, 23 February 2017 at 10:01 AM
To: "Ansari, Junaid" <[hidden email]>, "[hidden email]" <[hidden email]>
Cc: "Kamal, Murali" <[hidden email]>
Subject: Re: [dev-crypto] Error "Attempt to use unapproved implementation in approved thread" on Tomcat 8.5.9 with SSL Enabled - With Default Mode FIPS Mode Unapproved.

 


CSP is "critical security parameters" NIST use it to describe the private/secret keys and the internal state of ciphers and other operators.

In this case it appears one created in approved mode is being used by a thread not in approved mode.

The only solution in to stopping something like this is to have all threads running in approved mode - as far as configuration goes for 1.0.0 the only way to do this is via the security manager. 1.0.1 also has a system property which forces approved mode only on the executing application, from the sound of it this would solve your problem.

Regards,

David

On 23/02/17 15:13, Ansari, Junaid wrote:

Hi David,

 

I didn’t exactly get what you meant by “CSPs are shared across threads of different modes”.

 

When would the above happen or how can I avoid it from happening. Could you please point how to resolve this?

 

Again re-iterating our scenario with SOME MORE details and a small correction… may be it will help throw some light

Our usage of BC FIPS and sequence of events leading to error described below:

 

1.       In the servlet init()

a.       Add Bouncy Castle FIPS Provider to the top of providers list.

b.       Set the approved mode to be true.

c.       Create and store cipher for encryption.

2.       By the time steps in #1 are done, we also start another monitoring thread which does some encryption.

a.       This thread starts in unapproved mode (as the provider wasn’t yet added to the top of the list).

But before doing any encryption checks for BC FIPS Provider and if available at the top of the list moves the thread to approved mode.

This ensure that when this thread uses the Cipher created in #1.c does not fail with “Attempt to use approved implementation in unapproved thread” error. Solved.

So, far so good.

 

However, the error we are now seeing is a different scenario.

 

After step 2 i.e the application is initiliazed and Bouncy Castle is added to the top of the providers list…

 

User tries to login to the web app, the thread (tomcat worker thread) is in unapproved mode but before doing authentication (encryption/hashing) we call CryptoServicesRegistrar.setApprovedOnlyMode(true) to move it to approved mode the user is authenticated but when the response is returned. The error occurs at the tomcat-browser layer when trying to write the response.

From what I see in, it appears the error happens cryptographic operation is performed in a thread whose approved mode was set to true is while the MacOutputStream/DigestOutputStream being used has the approved mode set as false. org.bouncycastle.crypto.internal.io.Utils.approvedModeCheck() is where it is failing.

 

From the CTOR of MacOutputStream/DigestOutputStream, their approved mode is inferred from the CryptoServicesRegistrar.isInApprovedOnlyMode().

 

In our case, for that particular instance of MacOutputStream/DigestOutputStream appears to set approved mode as false (default mode being ‘false’ and the thread fips mode not available).

 

It appears this instance of MacOutputStream/DigestOutputStream with approved mode as false is now being reused, when calculating mac/digest in approved thread and fails with “Attempt to use unapproved implementation in approved thread”

 

Thanks

Junaid

 


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Error "Attempt to use unapproved implementation in approved thread" on Tomcat 8.5.9 with SSL Enabled - With Default Mode FIPS Mode Unapproved.

Ansari, Junaid
Hi David,

Could you please let me know how can I access the beta version of bc-fips 1.0.1?

I looked @ https://downloads.bouncycastle.org/betas/ but bc-fips doesn’t appear in the list of betas.

Thanks
Junaid

From: David Hook <[hidden email]>
Date: Tuesday, 28 February 2017 at 6:07 AM
To: "Ansari, Junaid" <[hidden email]>, "[hidden email]" <[hidden email]>
Cc: "Kamal, Murali" <[hidden email]>
Subject: Re: [dev-crypto] Error "Attempt to use unapproved implementation in approved thread" on Tomcat 8.5.9 with SSL Enabled - With Default Mode FIPS Mode Unapproved.


Hi Junaid,

I think it's a question of how the JSSE provider does things internally - there are somethings where it pre-allocates message digests on start up in other situations it creates signers and CSPs on request. My guess is that the set up phase is probably the one allocating objects not in approved mode and then it depends what code path is used to do the negotiation with the browser as to whether one of the "time bomb" objects gets invoked in the wrong mode. If you could add the JSSE provider by hand in code you would probably be able to get around this but I think in this case, the 1.0.1 release is probably your only safe option if you do not wish to use a SecurityManager.

Regards,

David

On 28/02/17 01:11, Ansari, Junaid wrote:

Hi David,

 

It doesn’t make sense to me on why changing the CIPHER SUITES list does not cause the error and there is no code change compared to previous error scenario.

In this case too all the thread starts in “unapproved” mode and are later moved into “approved” state, but we don’t see any issue here.

 

Is it discouraged to change the threads “FIPS” mode to approved and rather use Security Manager approach to start in approved mode?

 

I think there is something going wrong here which causes CSPs created in unapproved mode being used by threads which are in approved mode.

 

Thanks

Junaid

 

From: Ansari, Junaid
Sent: Thursday, February 23, 2017 11:33 AM
To: David Hook [hidden email]; [hidden email]
Cc: Kamal, Murali [hidden email]
Subject: Re: [dev-crypto] Error "Attempt to use unapproved implementation in approved thread" on Tomcat 8.5.9 with SSL Enabled - With Default Mode FIPS Mode Unapproved.

 

Another thing that is unexplained is…

 

We no code change, if I change the Tomcat HTTP Cconnector (SSL enabled) allowed Cipher Suites list from below to “TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256”,

it works fine in Chrome and Firefox but not IE11.

 

<Connector port="8043" redirectPort="80" secure="true" SSLEnabled="true" sslProtocol="TLS" sslEnabledProtocols="TLSv1.2,TLSv1.1,TLSv1" connectionTimeout="86400000" maxThreads="200" minSpareThreads="1" maxHttpHeaderSize="65536" keystoreFile="..\config\mykeystore.jks" keystorePass="*********" ciphers="TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_3DES_EDE_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_DES_CBC_SHA,SSL_RSA_WITH_DES_CBC_SHA,SSL_RSA_FIPS_WITH_DES_CBC_SHA,SSL_RSA_WITH_3DES_EDE_CBC_SHA,SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA,SSL_RSA_WITH_AES_128_CBC_SHA" enableLookups="false" disableUploadTimeout="true" acceptCount="100" scheme="https" clientAuth="false" URIEncoding="UTF-8" useBodyEncodingForURI="true" server="DUMMY" />

 

CHANGED TO:

 

<Connector port="8043" redirectPort="80" secure="true" SSLEnabled="true" sslProtocol="TLS" sslEnabledProtocols="TLSv1.2,TLSv1.1,TLSv1" connectionTimeout="86400000" maxThreads="200" minSpareThreads="1" maxHttpHeaderSize="65536" keystoreFile="..\config\mykeystore.jks" keystorePass="*********" ciphers=“TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256” enableLookups="false" disableUploadTimeout="true" acceptCount="100" scheme="https" clientAuth="false" URIEncoding="UTF-8" useBodyEncodingForURI="true" server="DUMMY" />

 

Thanks

Junaid

 

From: "Ansari, Junaid" <[hidden email]>
Date: Thursday, 23 February 2017 at 11:26 AM
To: David Hook <[hidden email]>, "[hidden email]" <[hidden email]>
Cc: "Kamal, Murali" <[hidden email]>
Subject: Re: [dev-crypto] Error "Attempt to use unapproved implementation in approved thread" on Tomcat 8.5.9 with SSL Enabled - With Default Mode FIPS Mode Unapproved.

 

Hi David,

 

The error being "Attempt to use unapproved implementation in approved thread: SHA-1/HMAC"

 

In this case it appears one created in approved mode is being used by a thread not in approved mode.

 

I guess you meant to say “In this case it appears one created in UNapproved mode is being used by a thread not in approved mode.” Right?

 

Thanks

Junaid

From: David Hook <[hidden email]>
Date: Thursday, 23 February 2017 at 10:01 AM
To: "Ansari, Junaid" <[hidden email]>, "[hidden email]" <[hidden email]>
Cc: "Kamal, Murali" <[hidden email]>
Subject: Re: [dev-crypto] Error "Attempt to use unapproved implementation in approved thread" on Tomcat 8.5.9 with SSL Enabled - With Default Mode FIPS Mode Unapproved.

 


CSP is "critical security parameters" NIST use it to describe the private/secret keys and the internal state of ciphers and other operators.

In this case it appears one created in approved mode is being used by a thread not in approved mode.

The only solution in to stopping something like this is to have all threads running in approved mode - as far as configuration goes for 1.0.0 the only way to do this is via the security manager. 1.0.1 also has a system property which forces approved mode only on the executing application, from the sound of it this would solve your problem.

Regards,

David

On 23/02/17 15:13, Ansari, Junaid wrote:

Hi David,

 

I didn’t exactly get what you meant by “CSPs are shared across threads of different modes”.

 

When would the above happen or how can I avoid it from happening. Could you please point how to resolve this?

 

Again re-iterating our scenario with SOME MORE details and a small correction… may be it will help throw some light

Our usage of BC FIPS and sequence of events leading to error described below:

 

1.       In the servlet init()

a.       Add Bouncy Castle FIPS Provider to the top of providers list.

b.       Set the approved mode to be true.

c.       Create and store cipher for encryption.

2.       By the time steps in #1 are done, we also start another monitoring thread which does some encryption.

a.       This thread starts in unapproved mode (as the provider wasn’t yet added to the top of the list).

But before doing any encryption checks for BC FIPS Provider and if available at the top of the list moves the thread to approved mode.

This ensure that when this thread uses the Cipher created in #1.c does not fail with “Attempt to use approved implementation in unapproved thread” error. Solved.

So, far so good.

 

However, the error we are now seeing is a different scenario.

 

After step 2 i.e the application is initiliazed and Bouncy Castle is added to the top of the providers list…

 

User tries to login to the web app, the thread (tomcat worker thread) is in unapproved mode but before doing authentication (encryption/hashing) we call CryptoServicesRegistrar.setApprovedOnlyMode(true) to move it to approved mode the user is authenticated but when the response is returned. The error occurs at the tomcat-browser layer when trying to write the response.

From what I see in, it appears the error happens cryptographic operation is performed in a thread whose approved mode was set to true is while the MacOutputStream/DigestOutputStream being used has the approved mode set as false. org.bouncycastle.crypto.internal.io.Utils.approvedModeCheck() is where it is failing.

 

From the CTOR of MacOutputStream/DigestOutputStream, their approved mode is inferred from the CryptoServicesRegistrar.isInApprovedOnlyMode().

 

In our case, for that particular instance of MacOutputStream/DigestOutputStream appears to set approved mode as false (default mode being ‘false’ and the thread fips mode not available).

 

It appears this instance of MacOutputStream/DigestOutputStream with approved mode as false is now being reused, when calculating mac/digest in approved thread and fails with “Attempt to use unapproved implementation in approved thread”

 

Thanks

Junaid

 


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Error "Attempt to use unapproved implementation in approved thread" on Tomcat 8.5.9 with SSL Enabled - With Default Mode FIPS Mode Unapproved.

David Hook-3

Hi Junaid,

the beta versions of the FIPS APIs are available through the FIPS early access program provided to BC support contract holders.

Regards,

David

On 20/03/17 16:30, Ansari, Junaid wrote:
Hi David,

Could you please let me know how can I access the beta version of bc-fips 1.0.1?

I looked @ https://downloads.bouncycastle.org/betas/ but bc-fips doesn’t appear in the list of betas.

Thanks
Junaid

From: David Hook <[hidden email]>
Date: Tuesday, 28 February 2017 at 6:07 AM
To: "Ansari, Junaid" <[hidden email]>, "[hidden email]" <[hidden email]>
Cc: "Kamal, Murali" <[hidden email]>
Subject: Re: [dev-crypto] Error "Attempt to use unapproved implementation in approved thread" on Tomcat 8.5.9 with SSL Enabled - With Default Mode FIPS Mode Unapproved.


Hi Junaid,

I think it's a question of how the JSSE provider does things internally - there are somethings where it pre-allocates message digests on start up in other situations it creates signers and CSPs on request. My guess is that the set up phase is probably the one allocating objects not in approved mode and then it depends what code path is used to do the negotiation with the browser as to whether one of the "time bomb" objects gets invoked in the wrong mode. If you could add the JSSE provider by hand in code you would probably be able to get around this but I think in this case, the 1.0.1 release is probably your only safe option if you do not wish to use a SecurityManager.

Regards,

David

On 28/02/17 01:11, Ansari, Junaid wrote:

Hi David,

 

It doesn’t make sense to me on why changing the CIPHER SUITES list does not cause the error and there is no code change compared to previous error scenario.

In this case too all the thread starts in “unapproved” mode and are later moved into “approved” state, but we don’t see any issue here.

 

Is it discouraged to change the threads “FIPS” mode to approved and rather use Security Manager approach to start in approved mode?

 

I think there is something going wrong here which causes CSPs created in unapproved mode being used by threads which are in approved mode.

 

Thanks

Junaid

 

From: Ansari, Junaid
Sent: Thursday, February 23, 2017 11:33 AM
To: David Hook [hidden email]; [hidden email]
Cc: Kamal, Murali [hidden email]
Subject: Re: [dev-crypto] Error "Attempt to use unapproved implementation in approved thread" on Tomcat 8.5.9 with SSL Enabled - With Default Mode FIPS Mode Unapproved.

 

Another thing that is unexplained is…

 

We no code change, if I change the Tomcat HTTP Cconnector (SSL enabled) allowed Cipher Suites list from below to “TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256”,

it works fine in Chrome and Firefox but not IE11.

 

<Connector port="8043" redirectPort="80" secure="true" SSLEnabled="true" sslProtocol="TLS" sslEnabledProtocols="TLSv1.2,TLSv1.1,TLSv1" connectionTimeout="86400000" maxThreads="200" minSpareThreads="1" maxHttpHeaderSize="65536" keystoreFile="..\config\mykeystore.jks" keystorePass="*********" ciphers="TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_3DES_EDE_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_DES_CBC_SHA,SSL_RSA_WITH_DES_CBC_SHA,SSL_RSA_FIPS_WITH_DES_CBC_SHA,SSL_RSA_WITH_3DES_EDE_CBC_SHA,SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA,SSL_RSA_WITH_AES_128_CBC_SHA" enableLookups="false" disableUploadTimeout="true" acceptCount="100" scheme="https" clientAuth="false" URIEncoding="UTF-8" useBodyEncodingForURI="true" server="DUMMY" />

 

CHANGED TO:

 

<Connector port="8043" redirectPort="80" secure="true" SSLEnabled="true" sslProtocol="TLS" sslEnabledProtocols="TLSv1.2,TLSv1.1,TLSv1" connectionTimeout="86400000" maxThreads="200" minSpareThreads="1" maxHttpHeaderSize="65536" keystoreFile="..\config\mykeystore.jks" keystorePass="*********" ciphers=“TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256” enableLookups="false" disableUploadTimeout="true" acceptCount="100" scheme="https" clientAuth="false" URIEncoding="UTF-8" useBodyEncodingForURI="true" server="DUMMY" />

 

Thanks

Junaid

 

From: "Ansari, Junaid" <[hidden email]>
Date: Thursday, 23 February 2017 at 11:26 AM
To: David Hook <[hidden email]>, "[hidden email]" <[hidden email]>
Cc: "Kamal, Murali" <[hidden email]>
Subject: Re: [dev-crypto] Error "Attempt to use unapproved implementation in approved thread" on Tomcat 8.5.9 with SSL Enabled - With Default Mode FIPS Mode Unapproved.

 

Hi David,

 

The error being "Attempt to use unapproved implementation in approved thread: SHA-1/HMAC"

 

In this case it appears one created in approved mode is being used by a thread not in approved mode.

 

I guess you meant to say “In this case it appears one created in UNapproved mode is being used by a thread not in approved mode.” Right?

 

Thanks

Junaid

From: David Hook <[hidden email]>
Date: Thursday, 23 February 2017 at 10:01 AM
To: "Ansari, Junaid" <[hidden email]>, "[hidden email]" <[hidden email]>
Cc: "Kamal, Murali" <[hidden email]>
Subject: Re: [dev-crypto] Error "Attempt to use unapproved implementation in approved thread" on Tomcat 8.5.9 with SSL Enabled - With Default Mode FIPS Mode Unapproved.

 


CSP is "critical security parameters" NIST use it to describe the private/secret keys and the internal state of ciphers and other operators.

In this case it appears one created in approved mode is being used by a thread not in approved mode.

The only solution in to stopping something like this is to have all threads running in approved mode - as far as configuration goes for 1.0.0 the only way to do this is via the security manager. 1.0.1 also has a system property which forces approved mode only on the executing application, from the sound of it this would solve your problem.

Regards,

David

On 23/02/17 15:13, Ansari, Junaid wrote:

Hi David,

 

I didn’t exactly get what you meant by “CSPs are shared across threads of different modes”.

 

When would the above happen or how can I avoid it from happening. Could you please point how to resolve this?

 

Again re-iterating our scenario with SOME MORE details and a small correction… may be it will help throw some light

Our usage of BC FIPS and sequence of events leading to error described below:

 

1.       In the servlet init()

a.       Add Bouncy Castle FIPS Provider to the top of providers list.

b.       Set the approved mode to be true.

c.       Create and store cipher for encryption.

2.       By the time steps in #1 are done, we also start another monitoring thread which does some encryption.

a.       This thread starts in unapproved mode (as the provider wasn’t yet added to the top of the list).

But before doing any encryption checks for BC FIPS Provider and if available at the top of the list moves the thread to approved mode.

This ensure that when this thread uses the Cipher created in #1.c does not fail with “Attempt to use approved implementation in unapproved thread” error. Solved.

So, far so good.

 

However, the error we are now seeing is a different scenario.

 

After step 2 i.e the application is initiliazed and Bouncy Castle is added to the top of the providers list…

 

User tries to login to the web app, the thread (tomcat worker thread) is in unapproved mode but before doing authentication (encryption/hashing) we call CryptoServicesRegistrar.setApprovedOnlyMode(true) to move it to approved mode the user is authenticated but when the response is returned. The error occurs at the tomcat-browser layer when trying to write the response.

From what I see in, it appears the error happens cryptographic operation is performed in a thread whose approved mode was set to true is while the MacOutputStream/DigestOutputStream being used has the approved mode set as false. org.bouncycastle.crypto.internal.io.Utils.approvedModeCheck() is where it is failing.

 

From the CTOR of MacOutputStream/DigestOutputStream, their approved mode is inferred from the CryptoServicesRegistrar.isInApprovedOnlyMode().

 

In our case, for that particular instance of MacOutputStream/DigestOutputStream appears to set approved mode as false (default mode being ‘false’ and the thread fips mode not available).

 

It appears this instance of MacOutputStream/DigestOutputStream with approved mode as false is now being reused, when calculating mac/digest in approved thread and fails with “Attempt to use unapproved implementation in approved thread”

 

Thanks

Junaid

 



Loading...