Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

In 4.3.9 if using the Oracle JDK Certain Authentication types fail. #14153

Closed
neddy0graylog opened this issue Dec 7, 2022 · 0 comments · Fixed by #14193
Closed

In 4.3.9 if using the Oracle JDK Certain Authentication types fail. #14153

neddy0graylog opened this issue Dec 7, 2022 · 0 comments · Fixed by #14193
Assignees
@mpfz0r
Labels
bug

Comments

@neddy0graylog
Copy link

  • Graylog Version: 4.3.9
  • Java Version: 1.8.0_261 Oracle

After updating to 4.3.9, when attempting login with a previously setup Authentication Provider the below error is thrown.

2022-12-05T11:32:21.149+04:00 INFO [SessionCreator] Invalid credentials in session create request. Actor: "urn:graylog:user:USERNAME"
2022-12-05T11:32:26.872+04:00 ERROR [AESTools] Could not encrypt value.
java.lang.SecurityException: JCE cannot authenticate the provider BC
at javax.crypto.Cipher.getInstance(Cipher.java:660) ~[?:1.8.0_271]

    at [org.graylog2.security](http://org.graylog2.security/).AESTools.encrypt([AESTools.java:63](http://aestools.java:63/)) ~[graylog.jar:?]

    at [org.graylog2.security](http://org.graylog2.security/).encryption.EncryptedValueService.encrypt([EncryptedValueService.java:45](http://encryptedvalueservice.java:45/)) ~[graylog.jar:?]

    at [org.graylog2.security](http://org.graylog2.security/).realm.UsernamePasswordRealm.doGetAuthenticationInfo([UsernamePasswordRealm.java:92](http://usernamepasswordrealm.java:92/)) ~[graylog.jar:?]

    at [org.graylog2.security](http://org.graylog2.security/).realm.UsernamePasswordRealm.doGetAuthenticationInfo([UsernamePasswordRealm.java:71](http://usernamepasswordrealm.java:71/)) ~[graylog.jar:?]

    at org.apache.shiro.realm.AuthenticatingRealm.getAuthenticationInfo([AuthenticatingRealm.java:571](http://authenticatingrealm.java:571/)) ~[graylog.jar:?]

    at org.apache.shiro.authc.pam.ModularRealmAuthenticator.doMultiRealmAuthentication([ModularRealmAuthenticator.java:225](http://modularrealmauthenticator.java:225/)) ~[graylog.jar:?]

    at org.apache.shiro.authc.pam.ModularRealmAuthenticator.doAuthenticate([ModularRealmAuthenticator.java:275](http://modularrealmauthenticator.java:275/)) ~[graylog.jar:?]

    at org.apache.shiro.authc.AbstractAuthenticator.authenticate([AbstractAuthenticator.java:198](http://abstractauthenticator.java:198/)) ~[graylog.jar:?]

    at org.apache.shiro.mgt.AuthenticatingSecurityManager.authenticate([AuthenticatingSecurityManager.java:106](http://authenticatingsecuritymanager.java:106/)) ~[graylog.jar:?]

    at org.apache.shiro.mgt.DefaultSecurityManager.login([DefaultSecurityManager.java:275](http://defaultsecuritymanager.java:275/)) ~[graylog.jar:?]

    at [org.apache.shiro.subject.support](http://org.apache.shiro.subject.support/).DelegatingSubject.login([DelegatingSubject.java:260](http://delegatingsubject.java:260/)) ~[graylog.jar:?]

    at [org.graylog2.shared.security](http://org.graylog2.shared.security/).SessionCreator.login([SessionCreator.java:87](http://sessioncreator.java:87/)) ~[graylog.jar:?]

    at [org.graylog2.rest](http://org.graylog2.rest/).resources.system.SessionsResource.newSession([SessionsResource.java:142](http://sessionsresource.java:142/)) ~[graylog.jar:?]

    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.8.0_261]

    at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) ~[?:1.8.0_261]

    at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) ~[?:1.8.0_261]

    at java.lang.reflect.Method.invoke(Unknown Source) ~[?:1.8.0_261]

    at org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory.lambda$static$0([ResourceMethodInvocationHandlerFactory.java:52](http://resourcemethodinvocationhandlerfactory.java:52/)) ~[graylog.jar:?]
@mpfz0r mpfz0r self-assigned this Dec 7, 2022
mpfz0r added a commit that referenced this issue Dec 12, 2022
@mpfz0r
Use PKCS5Padding instead of ISO10126d2Padding for secrets encryption
b9aeb09 
If Graylog is run in an FIPS environment there is no
crypto provider available that supports "AES/CBC/ISO10126d2Padding".
This is likely because this padding standard was withdrawn from ISO in
2007.
It is considered bad practice to leave a subliminal channel in the
padding.

We tried to workaround this by explicitly using BouncyCastle
for the encryption/decryption.

This however creates problems with Oracle Java, because
we strip the signature off the bouncy castle jar while repackaging
it into our Uber-Jar.
In contrast to OpenJDK, Oracle Java does not allow the use
of unsigned Security Providers.

Solution:

Change our secret encryption to using PKCS5Padding instead.
There is a FIPS compatible provider "SunPKCS11-NSS-FIPS"
available which supports "AES/CBC/PKCS5Padding".

For backwards compatibility, we decrypt the ISO10126d2Padded keys
without stripping the padding, and do that manually.

Fixes #14153

Refs #13525
@mpfz0r mpfz0r mentioned this issue Dec 12, 2022
Merged
mpfz0r added a commit that referenced this issue Dec 13, 2022
@mpfz0r
Use PKCS5 instead of ISO10126 padding for secrets encryption
7ac06a7 
If Graylog is run in an FIPS environment there is no
crypto provider available that supports "AES/CBC/ISO10126Padding".
This is likely because this padding standard was withdrawn from ISO in
2007.
It is considered bad practice to leave a subliminal channel in the
padding.

We tried to workaround this by explicitly using BouncyCastle
for the encryption/decryption.

This however creates problems with Oracle Java, because
we strip the signature off the bouncy castle jar while repackaging
it into our Uber-Jar.
In contrast to OpenJDK, Oracle Java does not allow the use
of unsigned Security Providers.

Solution:

Change our secret encryption to using PKCS5Padding instead.
There is a FIPS compatible provider "SunPKCS11-NSS-FIPS"
available which supports "AES/CBC/PKCS5Padding".

For backwards compatibility, we decrypt the ISO10126Padded keys
without stripping the padding, and do that manually.

Fixes #14153

Refs #13525
mpfz0r added a commit that referenced this issue Dec 14, 2022
@mpfz0r
Use PKCS5 instead of ISO10126 padding for secrets encryption
97719e8 
If Graylog is run in an FIPS environment there is no
crypto provider available that supports "AES/CBC/ISO10126Padding".
This is likely because this padding standard was withdrawn from ISO in
2007.
It is considered bad practice to leave a subliminal channel in the
padding.

We tried to workaround this by explicitly using BouncyCastle
for the encryption/decryption.

This however creates problems with Oracle Java, because
we strip the signature off the bouncy castle jar while repackaging
it into our Uber-Jar.
In contrast to OpenJDK, Oracle Java does not allow the use
of unsigned Security Providers.

Solution:

Change our secret encryption to using PKCS5Padding instead.
There is a FIPS compatible provider "SunPKCS11-NSS-FIPS"
available which supports "AES/CBC/PKCS5Padding".

For backwards compatibility, we decrypt the ISO10126Padded keys
without stripping the padding, and do that manually.

Fixes #14153

Refs #13525

use explicit type to simplify backport

Also try legacy decoding when catching a ProviderException

This seems to happen with FIPS enabled OpenJDK 17

Try decrypting legacy keys on any Exception

improve wording on comments

improve changelog
@mpfz0r mpfz0r mentioned this issue Dec 14, 2022
Merged
mpfz0r added a commit that referenced this issue Dec 14, 2022
@mpfz0r
Use PKCS5 instead of ISO10126 padding for secrets encryption
115e972 
If Graylog is run in an FIPS environment there is no
crypto provider available that supports "AES/CBC/ISO10126Padding".
This is likely because this padding standard was withdrawn from ISO in
2007.
It is considered bad practice to leave a subliminal channel in the
padding.

We tried to workaround this by explicitly using BouncyCastle
for the encryption/decryption.

This however creates problems with Oracle Java, because
we strip the signature off the bouncy castle jar while repackaging
it into our Uber-Jar.
In contrast to OpenJDK, Oracle Java does not allow the use
of unsigned Security Providers.

Solution:

Change our secret encryption to using PKCS5Padding instead.
There is a FIPS compatible provider "SunPKCS11-NSS-FIPS"
available which supports "AES/CBC/PKCS5Padding".

For backwards compatibility, we decrypt the ISO10126Padded keys
without stripping the padding, and do that manually.

Fixes #14153

Refs #13525

use explicit type to simplify backport

Also try legacy decoding when catching a ProviderException

This seems to happen with FIPS enabled OpenJDK 17

Try decrypting legacy keys on any Exception

improve wording on comments

improve changelog
@mpfz0r mpfz0r mentioned this issue Dec 14, 2022
Merged
mpfz0r added a commit that referenced this issue Dec 14, 2022
@mpfz0r
Use PKCS5Padding instead of ISO10126Padding for secrets encryption (#…
9d4d054 
…14193)

* Use PKCS5 instead of ISO10126 padding for secrets encryption

If Graylog is run in an FIPS environment there is no
crypto provider available that supports "AES/CBC/ISO10126Padding".
This is likely because this padding standard was withdrawn from ISO in
2007.
It is considered bad practice to leave a subliminal channel in the
padding.

We tried to workaround this by explicitly using BouncyCastle
for the encryption/decryption.

This however creates problems with Oracle Java, because
we strip the signature off the bouncy castle jar while repackaging
it into our Uber-Jar.
In contrast to OpenJDK, Oracle Java does not allow the use
of unsigned Security Providers.

Solution:

Change our secret encryption to using PKCS5Padding instead.
There is a FIPS compatible provider "SunPKCS11-NSS-FIPS"
available which supports "AES/CBC/PKCS5Padding".

For backwards compatibility, we decrypt the ISO10126Padded keys
without stripping the padding, and do that manually.

Fixes #14153

Refs #13525

* use explicit type to simplify backport

* Also try legacy decoding when catching a ProviderException

This seems to happen with FIPS enabled OpenJDK 17

* Try decrypting legacy keys on any Exception

* improve wording on comments

* improve changelog
bernd pushed a commit that referenced this issue Dec 14, 2022
@mpfz0r
Use PKCS5 instead of ISO10126 padding for secrets encryption (#14212)
0c1538e 
If Graylog is run in an FIPS environment there is no
crypto provider available that supports "AES/CBC/ISO10126Padding".
This is likely because this padding standard was withdrawn from ISO in
2007.
It is considered bad practice to leave a subliminal channel in the
padding.

We tried to workaround this by explicitly using BouncyCastle
for the encryption/decryption.

This however creates problems with Oracle Java, because
we strip the signature off the bouncy castle jar while repackaging
it into our Uber-Jar.
In contrast to OpenJDK, Oracle Java does not allow the use
of unsigned Security Providers.

Solution:

Change our secret encryption to using PKCS5Padding instead.
There is a FIPS compatible provider "SunPKCS11-NSS-FIPS"
available which supports "AES/CBC/PKCS5Padding".

For backwards compatibility, we decrypt the ISO10126Padded keys
without stripping the padding, and do that manually.

Fixes #14153

Refs #13525

use explicit type to simplify backport

Also try legacy decoding when catching a ProviderException

This seems to happen with FIPS enabled OpenJDK 17

Try decrypting legacy keys on any Exception

improve wording on comments

improve changelog
bernd pushed a commit that referenced this issue Dec 14, 2022
@mpfz0r
Use PKCS5 instead of ISO10126 padding for secrets encryption (#14211)
4190143 
If Graylog is run in an FIPS environment there is no
crypto provider available that supports "AES/CBC/ISO10126Padding".
This is likely because this padding standard was withdrawn from ISO in
2007.
It is considered bad practice to leave a subliminal channel in the
padding.

We tried to workaround this by explicitly using BouncyCastle
for the encryption/decryption.

This however creates problems with Oracle Java, because
we strip the signature off the bouncy castle jar while repackaging
it into our Uber-Jar.
In contrast to OpenJDK, Oracle Java does not allow the use
of unsigned Security Providers.

Solution:

Change our secret encryption to using PKCS5Padding instead.
There is a FIPS compatible provider "SunPKCS11-NSS-FIPS"
available which supports "AES/CBC/PKCS5Padding".

For backwards compatibility, we decrypt the ISO10126Padded keys
without stripping the padding, and do that manually.

Fixes #14153

Refs #13525

use explicit type to simplify backport

Also try legacy decoding when catching a ProviderException

This seems to happen with FIPS enabled OpenJDK 17

Try decrypting legacy keys on any Exception

improve wording on comments

improve changelog
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@mpfz0r mpfz0r

Labels
bug
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Use PKCS5Padding instead of ISO10126Padding for secrets encryption Graylog2/graylog2-server
2 participants
@mpfz0r @neddy0graylog