Open eCard

Thank you for this detailed report.

BC is clearly wrong in raising an error, so BC will definitely get an upgrade in the next version.
I started the update, but there are changes in the API of the TLS Client, so there is some more non-trivial work needed.
https://github.com/ecsec/open-ecard/tree/bc-161

Out of curiosity, do you know which one is the problematic hash algorithm? I can only imagine, that it is one of the SHA3 algorithms. But if it is, they are not defined for TLS 1.2 afaik. That means I would expect the error only to occur when the server is falling back to 1.2 from TLS 1.3.

In case you want to use 1.2 before the OeC release is made and distributed to the clients, you may also try to define the hash algorithms directly.

For Apache:
https://httpd.apache.org/docs/2.4/mod/mod_ssl.html#sslopensslconfcmd
https://www.openssl.org/docs/man1.0.2/man3/SSL_CONF_cmd.html#SUPPORTED-CONFIGURATION-FILE-COMMANDS

For nginx I couldn't see how to configure these values.

Best Regards
Tobias

Tobias Wich wrote:

Thank you for this detailed report.

BC is clearly wrong in raising an error, so BC will definitely get an upgrade in the next version.
I started the update, but there are changes in the API of the TLS Client, so there is some more non-trivial work needed.
https://github.com/ecsec/open-ecard/tree/bc-161

Thank you for your reply and for confirming!

We are looking forward to a new Open eCard release that is based on Bouncy Castle 1.6.1.

Out of curiosity, do you know which one is the problematic hash algorithm? I can only imagine, that it is one of the SHA3 algorithms. But if it is, they are not defined for TLS 1.2 afaik. That means I would expect the error only to occur when the server is falling back to 1.2 from TLS 1.3.

I think the "problematic" hash algorithms is rsa_pss_*, because that maps to hash algorithm "8", which Bouncy Castle complains about:

Signature Algorithm: rsa_pss_rsae_sha384 (0x0805)
    Signature Hash Algorithm Hash: Unknown (8)
    Signature Hash Algorithm Signature: Unknown (5)

java.lang.IllegalArgumentException: unknown HashAlgorithm: UNKNOWN(8)

In case you want to use 1.2 before the OeC release is made and distributed to the clients, you may also try to define the hash algorithms directly.

For Apache:
https://httpd.apache.org/docs/2.4/mod/mod_ssl.html#sslopensslconfcmd
https://www.openssl.org/docs/man1.0.2/man3/SSL_CONF_cmd.html#SUPPORTED-CONFIGURATION-FILE-COMMANDS

For nginx I couldn't see how to configure these values.

Unfortunately, we are running Nginx on our servers. And, indeed, there doesn't seem to be away to configure the hash-algorithms to be used.

Only "workaround" I found, so far, was disabling TLSv1.2 alltogether - which is not so great.

BTW: It seems that older versions of OpenSSL did not send the "problematic" hash algorithm, even with TLSv1.2 enabled. The problem only showed up after the upgrade to Ubuntu 18.04, probably due to a newer OpenSSL version.

Best Regards
Daniel

Hello,

I would like to ask what is the current status of this issue?

Thanky you and best regards
Daniel

It is now fixed, but no release has been performed so far as more work is currently going into Java 11 support before that will happen.

Tobias Wich wrote:

It is now fixed, but no release has been performed so far as more work is currently going into Java 11 support before that will happen.

Thank you for your reply. That is great news!

Is there any chance you can provide a build of the previous release with just the BouncyCastle v1.6.1 updates/fixes incorporated?

(Java 11 is not currently a priority for us, but working TLSv1.2 support is)

Best Regards
Daniel

Hello,

is there any schedule when the new version with working TLSv1.2 is going to be available?

(any update on the matter would be much appreciated)

Thank you and best regards
Daniel

I can't provide an exact date. However I can say that the last remaining item before the next release is to provide installers with Java 11 (which is the current LTS version). The situation is a bit messed up as the JavaFX Packager has been removed together with JavaFX in JDK 9 and will return with a new name in JDK 14. That means it is necessary to execute the package build with the still unreleased JDK 14 and an unfinished toolchain for which we provided patches to access all the features of the underlying packager tool.

The good news is that this looks pretty good right and we are basically in the test phase (and bugfixing) to have a smooth transition with respect to the installers.

We just found out that the situation is even more pressing: It appears that the current version of AusweisApp2 requires TLSv1.2; older TLS versions, including TLSv1.1 are no longer supported – TLS handshake fails. Unfortunately, we cannot enable TLSv1.2 on our servers at this time, as it would break the current version of the Open eCard software! This means that AusweisApp2 cannot work with our service for the time being. That is a big dilemma...

Is there any pre-release version of the upcoming Open eCard version that we could test?

Thank you and best regards
Daniel

We would like to ask if there is any ETA for the new version that fixes the TLSv1.2 problem.

If there are any pre-release builds available for testing that we can give a try, this would be much appreciated too.

Thank you and best regards
Daniel

There are still a few minor problems with the build process we need to solve. But here is a current snapshot for linux you may use to test.

Tobias Wich wrote:

There are still a few minor problems with the build process we need to solve. But here is a current snapshot for linux you may use to test.

Thank you! I can confirm that the TLSv1.2 bug is resolved with version 1.4.0 RC-4.

BTW: It would be helpful, if there was a download package with just the application code as JAR file(s), like the previous releases. Took some time to figure out how to "extract" the relevant modules from the provided JIMAGE and make them work with a "standard" JRE on the Windows platform.

Now that we are in 2020, is there any ETA for the Open eCard v1.4.0 release or at least a snapshot for the Windows platform?

Thank you and best regards
Daniel

We have noticed that version 1.4.1 has been released for Linux and MacOS X in the meantime, while the Windows package still is at version 1.3.0.

Is there a specific reason why the Windows package hasn't been updated to the latest version? And is there any ETA for the new version to be released for Windows too?

Thank you and best regards
Daniel

We have just released the version 1.4.1 for Windows also. You should see this in the Update functionality of the app and on github. The website should be updated also soon.

Thanks for your patience and best regards

Tobias

Tobias Assmann wrote:

We have just released the version 1.4.1 for Windows also. You should see this in the Update functionality of the app and on github. The website should be updated also soon.

Thanks for your patience and best regards

Tobias

Thank you for the information!

One more question: We see that the Windows version now is bundeled with a Java-Runtime and that is a 64-Bit version. So it won't work on 32-Bit Windows.

Will there be a 32-Bit version, that can work on 32-Bit Windows (and 64-Bit Windows) too? Or maybe a pure "JAR" release that we can launch with a standard JRE on the respective platform?

Best regards
Daniel

Please let us know why you think there should be a 32-Bit Windows Version.

Currently we have no plan to release such a version, but we can start investigating this issue if there is a convincing demand.
There are also no plans to release a pure Java Version, as the Releases are targeting on end users for easy install.

If any other form of bundeling is needed, maybe building from source could be an option for you?

Tobias Assmann wrote:

Please let us know why you think there should be a 32-Bit Windows Version.

Currently we have no plan to release such a version, but we can start investigating this issue if there is a convincing demand.
There are also no plans to release a pure Java Version, as the Releases are targeting on end users for easy install.

If any other form of bundeling is needed, maybe building from source could be an option for you?

Thanks for your reply!

Even the latest version of Windows 10 still exists as 32-Bit and 64-Bit version, and some of our customers may still be using the 32-Bit one. We don't have any control over that.

Our "core" application is based on .NET and therefore runs on 32-Bit Windows as well as 64-Bit Windows without modification. However, we have to ensure that any "external" applications that we depend on, such as the Open eCard App, will work on both platforms too. Obvisouly, if the new version of the Open eCard App is only available bundeled with a 64-Bit JVM, it cannot run on 32-Bit Windows. If there was a 32-Bit version available, it could run on 32-Bit and 64-Bit Windows – the 64-Bit Windows can run 32-Bit executables, but not the other way arround.

(We would like to avoid building from sources and much prefer to ship the "official" binaries)

Best regards
Daniel

Hello,

I did some investigation regarding 32bit binaries of JDK. Unfortunately there seems to be no 32bit version of Java 14 (EA) available for any platform.
As this might change in the future please feel free to let us know about that, so we can consider this again. A new issue should be opened for this.

Thank you so far. Best regards

Tobias

AdoptOpenJDK offers 32-Bit and 64-Bit Windows binaries of OpenJDK 11, which not only is the current LTS version of Java but also the verion of Java that is included with the "official" Open eCard App 1.4.1 package for Windows (the exact version included with Open eCard App v1.4 is Java v11.0.6). AdoptOpenJDK also offer 32-Bit and 64-Bit Windows binaries of OpenJDK 13, which is the latest Java version currently available. AFAIK, OpenJDK/Java 14 is not released yet and won't be an LTS version. So how is Java 14 a problem here, when Open eCard App v1.4 currently is based on Java 11?

(I would assume that AdoptOpenJDK will offer OpenJDK 14 binaries for all relevant platforms as soon as it will be officially released)

Thank you and best regards
Daniel

Java 14 is used for bundeling the app, so we are dependent on it. So yes, when 14 is officially released we can consider this again.

14 has been released and while Adopt has only 64 bit builds, Zulu provides 32 bit builds.
https://www.azul.com/downloads/zulu-community/?version=java-14&os=windows&architecture=x86-32-bit&package=jdk

Hello Daniel,

you can now find a 32bit Win build here:

https://github.com/ecsec/open-ecard/releases/download/1.4.1/Open-eCard-App-1.4.1_x86.exe

We will update our Download page soon.

Best regards

Tobias

Tobias Assmann wrote:

Hello Daniel,

you can now find a 32bit Win build here:

https://github.com/ecsec/open-ecard/releases/download/1.4.1/Open-eCard-App-1.4.1_x86.exe

We will update our Download page soon.

Best regards

Tobias

Thank you, that is great news!

Best regards
Daniel

BTW: AdoptOpenJDK has 32-Bit (x86) builds of Java 14 now too.