[TurboVNC-Users] ssl problem logging in to turbovnc server

Discussion:

j***@verona.se

2016-11-30 11:30:23 UTC

Hello,

I recently upgraded my fedora25 server running a turbovnc server.

On a fedora 25 client I get:

/opt/TurboVNC/bin/vncviewer 192.168.200.66:2
libjawt.so path: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.111-3.b16.fc25.x86_64/jre/lib/amd64
CConn: connected to host 192.168.200.66 port 5902
CConnection: Server supports RFB protocol version 3.8
CConnection: Using RFB protocol version 3.8
com.turbovnc.rdr.SystemException: javax.net.ssl.SSLHandshakeException: No appropriate protocol (protocol is disabled or cipher suites are inappropriate)
at com.turbovnc.rfb.CSecurityTLS.processMsg(CSecurityTLS.java:118)
at com.turbovnc.rfb.CSecurityStack.processMsg(CSecurityStack.java:39)
at com.turbovnc.rfb.CSecurityVeNCrypt.processMsg(CSecurityVeNCrypt.java:179)
at com.turbovnc.rfb.CSecurityTight.processMsg(CSecurityTight.java:56)
at com.turbovnc.rfb.CConnection.processSecurityMsg(CConnection.java:213)
at com.turbovnc.rfb.CConnection.processMsg(CConnection.java:62)
at com.turbovnc.vncviewer.VncViewer.run(VncViewer.java:838)
at java.lang.Thread.run(Thread.java:745)

It seems some kind of cipher was removed during an upgrade of the
server.

I can still connect from another machine, which is running fedora 23.
This suggests something happened on the fedora 25 server, maybe some
cipher deprecation.

I tried various workarounds like
/opt/TurboVNC/bin/vncviewer 192.168.200.66::5902 --SecurityTypes=Tight --User=joakim -loglevel 100
but so far found no working solution

both the problem client and server are running fedora 25, and the latest
2.1 turbovnc rpm.

I also tried commenting out
#jdk.tls.disabledAlgorithms=SSLv3, RC4, MD5withRSA, DH keySize < 768
in java.security, on a hunch. Havent tried this on the server yet.

--
Joakim Verona
***@verona.se

------------------------------------------------------------------------------

DRC

2016-11-30 19:35:54 UTC

Permalink

I'll look into it. I just installed Fedora 25 yesterday. It is not
unusual for Fedora and other bleeding-edge distros to break things,
because most commercial TurboVNC users are using RHEL or SLES or Ubuntu
LTS. Thus the majority of users won't notice issues like this until
they make it into the enterprise/long-term distros.

Post by j***@verona.se
Hello,
I recently upgraded my fedora25 server running a turbovnc server.
/opt/TurboVNC/bin/vncviewer 192.168.200.66:2
libjawt.so path: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.111-3.b16.fc25.x86_64/jre/lib/amd64
CConn: connected to host 192.168.200.66 port 5902
CConnection: Server supports RFB protocol version 3.8
CConnection: Using RFB protocol version 3.8
com.turbovnc.rdr.SystemException: javax.net.ssl.SSLHandshakeException: No appropriate protocol (protocol is disabled or cipher suites are inappropriate)
at com.turbovnc.rfb.CSecurityTLS.processMsg(CSecurityTLS.java:118)
at com.turbovnc.rfb.CSecurityStack.processMsg(CSecurityStack.java:39)
at com.turbovnc.rfb.CSecurityVeNCrypt.processMsg(CSecurityVeNCrypt.java:179)
at com.turbovnc.rfb.CSecurityTight.processMsg(CSecurityTight.java:56)
at com.turbovnc.rfb.CConnection.processSecurityMsg(CConnection.java:213)
at com.turbovnc.rfb.CConnection.processMsg(CConnection.java:62)
at com.turbovnc.vncviewer.VncViewer.run(VncViewer.java:838)
at java.lang.Thread.run(Thread.java:745)
It seems some kind of cipher was removed during an upgrade of the
server.
I can still connect from another machine, which is running fedora 23.
This suggests something happened on the fedora 25 server, maybe some
cipher deprecation.
I tried various workarounds like
/opt/TurboVNC/bin/vncviewer 192.168.200.66::5902 --SecurityTypes=Tight --User=joakim -loglevel 100
but so far found no working solution
both the problem client and server are running fedora 25, and the latest
2.1 turbovnc rpm.
I also tried commenting out
#jdk.tls.disabledAlgorithms=SSLv3, RC4, MD5withRSA, DH keySize < 768
in java.security, on a hunch. Havent tried this on the server yet.

------------------------------------------------------------------------------

j***@verona.se

2016-12-01 16:52:33 UTC

Permalink

Post by DRC
I'll look into it. I just installed Fedora 25 yesterday. It is not
unusual for Fedora and other bleeding-edge distros to break things,
because most commercial TurboVNC users are using RHEL or SLES or Ubuntu
LTS. Thus the majority of users won't notice issues like this until
they make it into the enterprise/long-term distros.

This helps on the server:
VNCSERVERARGS[2]="-geometry 1024x768 -securitytypes none"

Which is of course not very good if you are not encrypting by other
means.

Post by DRC

------------------------------------------------------------------------------

--
Joakim Verona
***@verona.se
+46705459454

------------------------------------------------------------------------------

DRC

2016-12-02 00:15:12 UTC

Permalink

You were on the right track. Apparently Fedora 25 started disabling the
anonymous TLS cipher suites by default in its OpenJDK security
configuration files. The workaround is to edit

/etc/crypto-policies/back-ends/java.config

and remove "DH_anon" and "ECDH_anon" from the jdk.tls.disabledAlgorithms
list.

The other workaround is to use an X.509 certificate, which doesn't
require the use of an anonymous cipher suite.

DRC

Post by j***@verona.se

VNCSERVERARGS[2]="-geometry 1024x768 -securitytypes none"
Which is of course not very good if you are not encrypting by other
means.

j***@verona.se

2016-12-02 12:09:03 UTC

Permalink

Post by DRC
You were on the right track. Apparently Fedora 25 started disabling the
anonymous TLS cipher suites by default in its OpenJDK security
configuration files. The workaround is to edit
/etc/crypto-policies/back-ends/java.config
and remove "DH_anon" and "ECDH_anon" from the jdk.tls.disabledAlgorithms
list.
The other workaround is to use an X.509 certificate, which doesn't
require the use of an anonymous cipher suite.

Thanks, I\ll try this!

Post by DRC
DRC

Post by j***@verona.se

VNCSERVERARGS[2]="-geometry 1024x768 -securitytypes none"
Which is of course not very good if you are not encrypting by other
means.

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

--
Joakim Verona
***@verona.se
+46705459454