Java 8U71 is out

Classic Servoy
1

Another java update is out :

At startup Smart Client :

SEVERE: Throwable
javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: Certificates does not conform to algorithm constraints
at sun.security.ssl.Alerts.getSSLException(Unknown Source)
at sun.security.ssl.SSLSocketImpl.fatal(Unknown Source)
at sun.security.ssl.Handshaker.fatalSE(Unknown Source)
at sun.security.ssl.Handshaker.fatalSE(Unknown Source)
at sun.security.ssl.ClientHandshaker.serverCertificate(Unknown Source)
at sun.security.ssl.ClientHandshaker.processMessage(Unknown Source)
at sun.security.ssl.Handshaker.processLoop(Unknown Source)
at sun.security.ssl.Handshaker.process_record(Unknown Source)
at sun.security.ssl.SSLSocketImpl.readRecord(Unknown Source)
at sun.security.ssl.SSLSocketImpl.performInitialHandshake(Unknown Source)
at sun.security.ssl.SSLSocketImpl.writeRecord(Unknown Source)
at sun.security.ssl.AppOutputStream.write(Unknown Source)
at com.servoy.j2db.rmi.compressing.CompressingOutputStream.flush(CompressingOutputStream.java:161)
at java.io.DataOutputStream.flush(Unknown Source)
at com.servoy.j2db.rmi.SignallingChannel.connect(SignallingChannel.java:158)
at com.servoy.j2db.rmi.SignallingChannel.(SignallingChannel.java:49)
at com.servoy.j2db.rmi.ClientTwoWaySocketFactory.establishSignallingChannel(ClientTwoWaySocketFactory.java:138)
at com.servoy.j2db.rmi.DefaultClientSocketFactoryFactory.initRMISocketFactory(DefaultClientSocketFactoryFactory.java:55)
at com.servoy.j2db.rmi.DefaultClientSocketFactoryFactory.(DefaultClientSocketFactoryFactory.java:41)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
at java.lang.reflect.Constructor.newInstance(Unknown Source)
at com.servoy.j2db.smart.J2DBClient.initRMISocketFactory(J2DBClient.java:843)
at com.servoy.j2db.smart.J2DBClient.startupApplication(J2DBClient.java:780)
at com.servoy.j2db.smart.J2DBClient$4.run(J2DBClient.java:692)
at com.servoy.j2db.smart.J2DBClient.mainImpl(J2DBClient.java:716)
at com.servoy.j2db.smart.J2DBClient.main(J2DBClient.java:679)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at com.sun.javaws.Launcher.executeApplication(Unknown Source)
at com.sun.javaws.Launcher.executeMainClass(Unknown Source)
at com.sun.javaws.Launcher.doLaunchApp(Unknown Source)
at com.sun.javaws.Launcher.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: java.security.cert.CertificateException: Certificates does not conform to algorithm constraints
at sun.security.ssl.AbstractTrustManagerWrapper.checkAlgorithmConstraints(Unknown Source)
at sun.security.ssl.AbstractTrustManagerWrapper.checkAdditionalTrust(Unknown Source)
at sun.security.ssl.AbstractTrustManagerWrapper.checkServerTrusted(Unknown Source)
… 33 more

Has anybody info what Oracle has changed?

Regards,

2

this means that certain Algorithms that are used to generate a certificate are not allowed anymore because they are to weak
Not sure if they disabled some, can’t really find much about that currently in the release notes

Not sure if it is your server side certificate (do you have your own there?) or if it is the “test ssl” that we use
what is exactly your configuration under: network-settings tab in the admin page?

Can you switch to “http&socket” and restart the server to see if that helps?

3

Hi all,

I have just tested the new 8u71 with two different Servoy servers.
I can load a client from one but not the other.

On the Network Settings page on the server:

SocketFactory.useSSL: is not ticked on the one that works.

4

With ‘http&socket’ I get:
javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated
at sun.security.ssl.SSLSessionImpl.getPeerCertificates(Unknown Source)
at com.sebster.tunnel.impl.cb.a(cb.java:9)
at com.sebster.tunnel.impl.bb.connect(bb.java:8)
at com.sebster.tunnel.DelegatingTunnelClient.connect(DelegatingTunnelClient.java:2)
at com.sebster.tunnel.impl.le.(le.java:11)
at com.sebster.tunnel.multiplexer.rmi.ClientMultiplexedRmiSocketFactoryProvider$1.(ClientMultiplexedRmiSocketFactoryProvider.java:2)
at com.sebster.tunnel.multiplexer.rmi.ClientMultiplexedRmiSocketFactoryProvider.(ClientMultiplexedRmiSocketFactoryProvider.java:11)
at com.sebster.tunnel.multiplexer.rmi.ClientMultiplexedRmiSocketFactoryProvider.(ClientMultiplexedRmiSocketFactoryProvider.java:10)
at com.servoy.j2db.server.rmi.tunnel.ClientTunnelRMISocketFactoryFactory$RmiSocketFactoryProvider.(ClientTunnelRMISocketFactoryFactory.java:301)
at com.servoy.j2db.server.rmi.tunnel.ClientTunnelRMISocketFactoryFactory$RmiSocketFactoryProvider.(ClientTunnelRMISocketFactoryFactory.java:299)
at com.servoy.j2db.server.rmi.tunnel.ClientTunnelRMISocketFactoryFactory.createFactoryProvider(ClientTunnelRMISocketFactoryFactory.java:253)
at com.servoy.j2db.server.rmi.tunnel.ClientTunnelRMISocketFactoryFactory.(ClientTunnelRMISocketFactoryFactory.java:241)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
at java.lang.reflect.Constructor.newInstance(Unknown Source)
at com.servoy.j2db.smart.J2DBClient.initRMISocketFactory(J2DBClient.java:843)
at com.servoy.j2db.smart.J2DBClient.startupApplication(J2DBClient.java:780)
at com.servoy.j2db.smart.J2DBClient$4.run(J2DBClient.java:692)
at com.servoy.j2db.smart.J2DBClient.mainImpl(J2DBClient.java:716)
at com.servoy.j2db.smart.J2DBClient.main(J2DBClient.java:679)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at com.sun.javaws.Launcher.executeApplication(Unknown Source)
at com.sun.javaws.Launcher.executeMainClass(Unknown Source)
at com.sun.javaws.Launcher.doLaunchApp(Unknown Source)
at com.sun.javaws.Launcher.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)

With SSL switched off: no problem

We sign our jar files with our own signing certificate but that has nothing to do with the SSL-certificate from the Servoy server?

In Java 8u71 the security settings are changed in the file java.security :

jdk.certpath.disabledAlgorithms=MD2, MD5, RSA keySize < 1024
and
jdk.tls.disabledAlgorithms=SSLv3, RC4, MD5withRSA, DH keySize < 768

In 8u66 it was :

jdk.certpath.disabledAlgorithms=MD2
and
jdk.tls.disabledAlgorithms=SSLv3

When I remove MD5 and MD5withRSA the smart client starts up ok.

Servoy action?

5

Looks like a SSL issue to me.
Perhaps Oracle did the same as what FireFox did per Januari 1st and requires SHA-2 certs instead of the old standard SHA-1?

Edit: I just try to read all the related info on this update and it’s as clear as mud.
It only lists some release ‘highlights’ with the only item remotely related to this is:

Problem with PBE algorithms using AES crypto corrected
An error was corrected for PBE using 256-bit AES ciphers such that the derived key may be different and not equivalent to keys previously derived from the same password.

Also the link to the actual bug-fixes page is broken. Here is the working one: http://www.oracle.com/technetwork/java/ … 11127.html

6

lwjwillemsen:
With SSL switched off: no problem

And do you have your own keystore configured?
Or are you just using “useSSL” of servoy? (which means we take a ‘test’ keystore that we ship inside servoy)

lwjwillemsen:
We sign our jar files with our own signing certificate but that has nothing to do with the SSL-certificate from the Servoy server?

signing doesn’t have anything to do with this.

It sounds like it the keystore that is used on the server, i guess what we ship as a default ‘test’ keystore (when you just select useSSL but not provide a keystore, which is not fully secure as we mention on the network settings page)

lwjwillemsen:
In Java 8u71 the security settings are changed in the file java.security :

jdk.certpath.disabledAlgorithms=MD2, MD5, RSA keySize < 1024
and
jdk.tls.disabledAlgorithms=SSLv3, RC4, MD5withRSA, DH keySize < 768

In 8u66 it was :

jdk.certpath.disabledAlgorithms=MD2
and
jdk.tls.disabledAlgorithms=SSLv3

When I remove MD5 and MD5withRSA the smart client starts up ok.

Yes that is the change then i guess

We use by default a certificate that is created with SHA-1
which has a keysize of 160 bits so that RSA keySize < 1024 doesn’t allow that anymore

So for now, disable “useSSL” or give use a valid ssl keystore with your own valid certificate.

7

Is Servoy gonna change their server SSL certificate?
The current one is a bit old (cryptographic) I guess…

8

yes we can ship a different one, but at production you shouldn’t really use that
It is kind of just for testing or that at least some encryption and compressing does happen
But it is not really secure.

What version of servoy are you testing?

9

We see this Issue with Servoy 5 en 7. Servoy 6 not tested.

I remember a session long ago with Jan Aleman and how proud he was that (out of the Servoy box) the smart client
communicated secure with the server…

10

this sentence is there for ages on our admin page:

“The use SSL option indicates that the server and clients will talk to each other using an SSL tunnel. For this to work securely you need to generate a valid keystore file with the SSL keys and certificates and place it in the ‘server/conf/keystore’ location on the server.”

It can never be fully secure in what we ship, that is impossible because we ship a (generated) certificate with a private key inside our installation. Which is fully open source and everybody can look and see in it…

I already generated a new one but the problem is if we ship that, then no server will startup anymore because that same key is used to encrypt the passwords in the servoy settings
So nothing can be decrypted anymore with the new keystore, so the database connections are not coming up.

11

Thanks Johan,

It’s all clear to me now.

12

We did some intensive testing and it’s not the fact that the certificate is a selfsigned certificate from Servoy, but it’s an old certifcate with MD5, which is now by default is disabled by this Java version.

Here are the releasenotes:
http://www.oracle.com/technetwork/java/ … 73756.html

and here some quotes:

MD5 now disabled for X509 Certificate validating
MD5 must not be used for digital signatures where collision resistance is required. In order to prevent the usage of MD5 as digital signature algorithm during X.509 certificate operations, MD5 has been added to the jdk.certpath.disabledAlgorithms Security property. For applications which still using MD5 signed certificates, please upgrade the weak certificate as soon as possible.
Reversing this change is possible, by removing MD5 from the jdk.certpath.disabledAlgorithms property contained in the java.security file. This is not recommended.

So, I think if Servoy updates that certificate by using not MD5 anymore, that that will fix the issue.
BUT… even if Servoy does that, that’s NOT the solution!

So you have the option, to search your java.security file and remove MD5 from the jdk.certpath.disabledAlgorithms list. (not recommended!!)

the other quick option, is to set use SLL to off in the servoy-admin page, restart Servoy (which in IMHO is also not recommended, because, if you run the smart client with the (default test) certifcate from Servoy, or running no SSL at all, security-wise that’s the same! :!: :idea: :lol: )

If you want to fix this the best way (and the way we do this for already a couple of years) you have two options:

Use a official signed certificate (in a java keustore) and place that directly in Tomcat. useSSL to off and useSSLoverTunnel to off and the connection to http, only!
that way all traffic by tomcat and the smart-client (through tunnel) is securely encrypted!

If you want to use smart-client by rmi/socket, you have to set the certificate path to the java-keystore (with your certificate) and the password in the servoy-admin page. (be aware that you do this in the admin-page, because than Servoy takes care of all your db connection passwords, they will be newly encrypted!)
set useSSL to ON, set useSSLoverTunnel to ON or OFF, depending if you also have the certificate in Tomcat itself and the connection to http&socket.
Now your smart-client is using socket (rmi port) and all traffice from smart-client to the server is securely encrypted

If you need any help in securing, hosting, tuning your Servoy application server, let me know. We do it a lot! :wink:

Also the security-issue with rmi-traffic, which is explained here: https://www.servoy.com/forum/viewtopic.php?f=16&t=21087
We still see dozens of servers, which uses smart-client and do nothing with it… Keeping up and be focused on security is not the top priority with most of the Servoy Developers… :roll: :wink:

13

At least one user also installed Java 8u71 now, and I saw this message suddenly a lot in the server log, both on our test server and on our live server.

Is this also related to Java 8u71, so that we should tell the user to go back to Java 8u65 which runs fine?

The link for that tried and tested Java version 65 is here:
http://www.oracle.com/technetwork/java/ … 65-oth-JPR

multiplexer.png
multiplexer.png2028×238 40.2 KB

14

Hi Bernd, rolling Java back is in my opinion the wrong advice!

15

Do you have any experience with self-signed certificates on Java 8u71? I would like to try it out on our inhouse application servers, but we dont have a signed certificate for them. The application servers dont have a domain name, just IPs.

I am getting following errors when I start a smart-client:

javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated
	at sun.security.ssl.SSLSessionImpl.getPeerCertificates(Unknown Source)
	at com.sebster.tunnel.impl.cb.a(cb.java:9)
	at com.sebster.tunnel.impl.bb.connect(bb.java:8)
	at com.sebster.tunnel.DelegatingTunnelClient.connect(DelegatingTunnelClient.java:2)
	at com.sebster.tunnel.impl.le.<init>(le.java:11)
	at com.sebster.tunnel.multiplexer.rmi.ClientMultiplexedRmiSocketFactoryProvider$1.<init>(ClientMultiplexedRmiSocketFactoryProvider.java:2)
	at com.sebster.tunnel.multiplexer.rmi.ClientMultiplexedRmiSocketFactoryProvider.<init>(ClientMultiplexedRmiSocketFactoryProvider.java:11)
	at com.sebster.tunnel.multiplexer.rmi.ClientMultiplexedRmiSocketFactoryProvider.<init>(ClientMultiplexedRmiSocketFactoryProvider.java:10)
	at com.servoy.j2db.server.rmi.tunnel.ClientTunnelRMISocketFactoryFactory$RmiSocketFactoryProvider.<init>(ClientTunnelRMISocketFactoryFactory.java:301)
	at com.servoy.j2db.server.rmi.tunnel.ClientTunnelRMISocketFactoryFactory$RmiSocketFactoryProvider.<init>(ClientTunnelRMISocketFactoryFactory.java:299)
	at com.servoy.j2db.server.rmi.tunnel.ClientTunnelRMISocketFactoryFactory.createFactoryProvider(ClientTunnelRMISocketFactoryFactory.java:253)
	at com.servoy.j2db.server.rmi.tunnel.ClientTunnelRMISocketFactoryFactory.<init>(ClientTunnelRMISocketFactoryFactory.java:241)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
	at java.lang.reflect.Constructor.newInstance(Unknown Source)
	at com.servoy.j2db.smart.J2DBClient.initRMISocketFactory(J2DBClient.java:843)
	at com.servoy.j2db.smart.J2DBClient.startupApplication(J2DBClient.java:780)
	at com.servoy.j2db.smart.J2DBClient$4.run(J2DBClient.java:692)
	at com.servoy.j2db.smart.J2DBClient.mainImpl(J2DBClient.java:716)
	at com.servoy.j2db.smart.J2DBClient.main(J2DBClient.java:679)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
	at java.lang.reflect.Method.invoke(Unknown Source)
	at com.sun.javaws.Launcher.executeApplication(Unknown Source)
	at com.sun.javaws.Launcher.executeMainClass(Unknown Source)
	at com.sun.javaws.Launcher.doLaunchApp(Unknown Source)
	at com.sun.javaws.Launcher.run(Unknown Source)
	at java.lang.Thread.run(Unknown Source)

I also imported the self-signed certificate into the JRE, but nothing changed

16

Harjo:
Hi Bernd, rolling Java back is in my opinion the wrong advice!

Hi Harjo,
I agree in general, but we are currently in a rollout-situation, which means the users want to start at once.
Changing the server would take longer, I guess.

17

Bernd.N:

Harjo:
Hi Bernd, rolling Java back is in my opinion the wrong advice!

Hi Harjo,
I agree in general, but we are currently in a rollout-situation, which means the users want to start at once.
Changing the server would take longer, I guess.

no changing the server would take 1 minute.
useSSL to false and restart…

18

jozef.kopanicak:
I also imported the self-signed certificate into the JRE, but nothing changed

normally selfsigned will not work, because the smartclient would do that certificate check
But if you really imported your certificate into the JRE certificates as a trusted (root) certificate then i think it should work
(but then you need to do that on all your clients)

For a self signed certificate to really work we could potentially give you an extra option on that network settings page
“selfSigned”

that you have to set to true.

But that still won’t be that secure because the certificate in the smart client will not be checked so it can be then any kind of certificate…

19

I consider the choice of Servoy to use the same keystore for SSL client - server and for encryption of
passwords in the servoy.properties a bad one.
The needed security level for client - server communication is so much higher then for passwords
in the properties file. For access to the properties file an intruder has to gain access to the file system of the application server.

Now when on a running Servoy Application server the SSL certificate expires and you install a new one all Servoy database connections are out of order!

We have a lot of on premise Servoy servers with smart clients in the field so the problem seems obvious imho.

20

lwjwillemsen:
Now when on a running Servoy Application server the SSL certificate expires and you install a new one all Servoy database connections are out of order!

not true!
when you renew your certificate and renew through the admin-page, Servoy converts the passwords automaticly for you.
If you don’t want that, just stop the server, set the passwords in the servoy.properties file in plain-text, start the server, and the passwords are also newly encrypted again, with the new certificate.