Problems accessing databases over TLS with outdated cert signing algorithm

[Anonymous-Coward]

I have a database accessible over TLS with a certificate signed with SHA1 and with key algorithm RSA - I have no control over the certificate used by the database. Any attempt to migrate that database using Java 17 (openjdk) and mybatis will fail with the following error:

ERROR: Error getting connection. Cause: org.postgresql.util.PSQLException: SSL error: Certificates do not conform to algorithm constraints.

The reason for this is that SHA1 with RSA was found to be insecure some time in the past and more recent JDKs/JREs have disabled it.

When you configure other clients for accessing the database, you can change ${JAVA_HOME}/conf/security/java.security to allow that algorithm combination - remove offending entries from jdk.certpath.disabledAlgorithms - and set the SSL factory used by the driver to org.postgresql.ssl.DefaultJavaSSLFactory.

There's no way to influence the behavior of the postgres driver when being used from mybatis migrations - or at least not a documented one that I could find.

Same goes for the mybatis migrations plugin. Even if the java global security settings file is changed, the driver will still complain about outdated algorithms by throwing the exception.

Mybatis migrations version: MyBatis Migrations 3.3.11
Mybatis migrations maven plugin: 1.1.4
Postgres jdbc driver: 4.2.25 (both with the maven plugin and the CLI)

[harawata]

Hello @Anonymous-Coward ,

A different Java installation is used, maybe?
For CLI, there are scripts in the 'bin' directory.

It seems unlikely that Migrations can somehow override or ignore the JVM's security config.
If there is some condition that prohibits the driver from using the config, you should ask pgjdbc people about it.

[Anonymous-Coward]

My initial description of the problem is probably somewhat inaccurate - I won't fix it, though, or else the context of harawata's comment is partially lost.

There is a way to override the Java security settings from the command line:

-Djava.security.properties=<custom java security settings file> -Djava.security.disableSystemPropertiesFile=true

The setting java.security.disableSystemPropertiesFile is what makes things work. Additionally to the file java.security that's part of every JVM/JDK installation, there's also a global security settings file, which overrides whatever is in the individual, per-JVM/JDK files. Editing that file is not an acceptable - in order to run mybatis migrations you'd need to create a security risk for the entire system, for all Java installations.

If I edit the migrate script that's part of the mybatis migrations bundle, and add these parameters to the command at the end that runs the Java migrations application, I can run the migrations. Any other way to change what the migrate script uses fails. There are no command line overrides possible for the migrate script to pass to the Java command.

For running migrations with changed Java security settings using the maven plugin, I have not found any way to make it work. Other maven plugins allow overriding system properties in the plugin's configuration. The only configuration the mybatis migrations plugin allows is the repository.

The problem isn't that the driver doesn't pick the correct java.security settings file. It's that the mybatis migrations, both when used as a maven plugin and when used as a standalone application, don't provide a way to specify custom java security settings, to make it possible to use cipher combinations which are considered unsafe by newer JDKs but are unfortunately still used by major certificate providers. The SHA1 with RSA combination was marked as unsafe and therefore disabled already since 2019, but certificates with that combination of ciphers (certificate signature and key encryption) are still used by managed services on major public clouds.

[hazendaz]

Not sure I buy part of the last comments regarding security on a cloud. Most of the security there is on the user and degrading to use sha1 almost always is due to some library usage on the classpath that needs it not the cloud platform or otherwise. Aside from not buying that please share if you can what your classpath actually contains. If you need that private and I would think you do, please email one of us separately. One specific library I know requires this degrade is usage of bad security libs like cryptix. So it's important in general to use proper hygiene on all libs especially security libs. And btw. This was only very recently changed in the jdks so technically you could go back about a year and it is not directly blocked. Just noting that as java only did this very recently. Their change logs document exactly when and all else you have here is right on accurate info And useful for all but I don't believe it's a mybatis issue at this point. Sent from my Verizon, Samsung Galaxy smartphone Get Outlook for Android<https://aka.ms/AAb9ysg>

…

________________________________ From: Anonymous-Coward ***@***.***> Sent: Friday, March 31, 2023 6:21:26 AM To: mybatis/migrations ***@***.***> Cc: Subscribed ***@***.***> Subject: Re: [mybatis/migrations] Problems accessing databases over TLS with outdated cert signing algorithm (Issue #289) My initial description of the problem is probably somewhat inaccurate - I won't fix it, though, or else the context of harawata's comment is partially lost. There is a way to override the Java security settings from the command line:

-Djava.security.properties=<custom java security settings file> -Djava.security.disableSystemPropertiesFile=true The setting java.security.disableSystemPropertiesFile is what makes things work. Additionally to the file java.security that's part of every JVM/JDK installation, there's also a global security settings file, which overrides whatever is in the individual, per-JVM/JDK files. Editing that file is not an acceptable - in order to run mybatis migrations you'd need to create a security risk for the entire system, for all Java installations. If I edit the migrate script that's part of the mybatis migrations bundle, and add these parameters to the command at the end that runs the Java migrations application, I can run the migrations. Any other way to change what the migrate script uses fails. There are no command line overrides possible for the migrate script to pass to the Java command. For running migrations with changed Java security settings using the maven plugin, I have not found any way to make it work. Other maven plugins allow overriding system properties in the plugin's configuration. The only configuration the mybatis migrations plugin allows is the repository. The problem isn't that the driver doesn't pick the correct java.security settings file. It's that the mybatis migrations, both when used as a maven plugin and when used as a standalone application, don't provide a way to specify custom java security settings, to make it possible to use cipher combinations which are considered unsafe by newer JDKs but are unfortunately still used by major certificate providers. The SHA1 with RSA combination was marked as unsafe and therefore disabled already since 2019, but certificates with that combination of ciphers (certificate signature and key encryption) are still used by managed services on major public clouds. — Reply to this email directly, view it on GitHub<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmybatis%2Fmigrations%2Fissues%2F289%23issuecomment-1491690330&data=05%7C01%7C%7Cc9871fa2eb1c45e8e3cc08db31d1b001%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638158548888157877%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=GfVYQ1HE0Siv5vE13WZhVPnoYzJivbchLwoiwuU54JQ%3D&reserved=0>, or unsubscribe<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAAHODIZLH7C5THPBD73JXITW62V2NANCNFSM6AAAAAAWNPU2Y4&data=05%7C01%7C%7Cc9871fa2eb1c45e8e3cc08db31d1b001%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638158548888157877%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ariWsA3lRGa4IQ5y0iJg0Dt6baNXP7co7f4AfTOgHT8%3D&reserved=0>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[Anonymous-Coward]

@hazendaz Has nothing to do with what libs the client (in this case mybatis migrations) uses. If it was a problem of what libraries the client uses, it would still be a mybatis migrations issue - there's nothing on the classpath except what the JVM provides by default and the mybatis migrations standalone jar. But it isn't a problem of libraries, it's a problem of missing functionality.

There is a database on azure which should be updated using mybatis migrations. It's a managed service, so there's nothing anybody except Microsoft can do about what certificates that database uses. That database uses a root CA with an outdated signature algorithm - SHA1 with RSA. It's a managed service - a database provided as a service by Microsoft/Azure where the certificates are provided by Microsoft and can't be changed in any way by users.

The problem I'm trying to get across is that there is no way to tell the mybatis migrate script to use modified security settings other than editing the script itself, and no way whatsoever to do this for the mybatis migrations plugin, except changing Java security settings in a way that affects all Java processes on the machine. This doesn't seem an acceptable way to do it, to me. There should be a way for the migrate script to allow passing -D parameters on the command line to the JVM, and there should be a way to do the same in the maven plugin configuration.

[harawata]

@Anonymous-Coward ,

If I edit the migrate script that's part of the mybatis migrations bundle, and add these parameters to the command at the end that runs the Java migrations application, I can run the migrations. Any other way to change what the migrate script uses fails. There are no command line overrides possible for the migrate script to pass to the Java command.

In the scripts, the environment variable JAVA_OPTS is passed to the java command, I think.

export JAVA_OPTS="-Djava.security.properties=<custom java security settings file> -Djava.security.disableSystemPropertiesFile=true"

Note that the scripts are generated by appassembler and there seems to be some issue with JAVA_OPTS handling.

For running migrations with changed Java security settings using the maven plugin, I have not found any way to make it work. Other maven plugins allow overriding system properties in the plugin's configuration. The only configuration the mybatis migrations plugin allows is the repository.

I don't know much about maven plugins, but it sounds like a useful feature.
If you send us a PR to https://github.com/mybatis/migrations-maven-plugin, we will review it.
Or, just open a new feature request issue there.