VNC "Security type" preference (to pick VNC over VeNCrypt)
Hi there,
From my point of view (upgrading from 2024.1.29 to 2025.1.33) the issue I ran into looked like a regression, but diving into the log files, and packet captures, it turns out this upgrade causes the default "Security type" picked by RDM's VNC client (ultra, and free) to be VeNCrypt instead of VNC with the earlier one (and that makes the SW more secure, but it breaks things in my environment!? :) :( ).
Config Details: Win 11 (24H2 26100.3775) client connecting to TigerVNC server (1.8.0 - 33.0.3.el7_9) running on Oracle Linux 7.
Packet capture and VNCServer logs show that earlier version was picking VNC security type, and the authentication (which is much less secure, I know) was working fine [1], whereas the most recent version is picking VeNCrypt and running into a
TLS Handshake failed: Could not negotiate a supported cipher suite
error later on the server side [2].
I realize this is what I should be fixing, but I thought I should first report this here so it gets recorded in your "knowledge-base" for curious folks like me! :) (Since the latest VNC Server release on my OS cannot pick a cipher suite among the offered 104 suites, that research may be more tedious)
So is there a way to instruct RDM to pick a certain encryption type (or provide some sort of order) for VNC? I couldn't see one in settings.
Thanks,
Özgür
[1]
Connections: accepted: 172.30.3.41::60275 SConnection: Client needs protocol version 3.8 SConnection: Client requests security type VncAuth(2) VNCSConnST: Server default pixel format depth 24 (32bpp) little-endian rgb888
[2]
SConnection: Client requests security type VeNCrypt(19)
SVeNCrypt: Client requests security type TLSVnc (258)
TLS: TLS Handshake failed: Could not negotiate a supported cipher
suite.
TLS: TLS session wasn't terminated gracefully
SConnection: AuthFailureException: TLS Handshake failed
Connections: closed: 172.30.3.41::59868 (TLS Handshake failed)All Comments (3)
Hello
Thanks for your post and the detailed analysis!
I haven't dived into the details here, but 2024.1.29 is quite old comparatively. It might be simply possible that we didn't support VEncrypt in that version, so it wouldn't have been selected if the server offered it. For UltrraVNC, I'm not sure, because we obviously don't maintain that client. But I expect in both cases it would be normal that the more secure authentication is chosen, and it seems that you are in agreement there.
I don't have a TigerVNC install handy to play with, but would it not be possible to disable the authentication types you don't want on the server side?
Otherwise, your point about preferring a particular authentication type is a good one. We don't have any option for that at the moment, but I will enter a ticket and that's a setting that we can add. I'll link it back to this forum thread so you can be notified once that is implemented.
Once again, thanks for your post and don't hesitate with further questions or comments
Kind regards,
Richard Markievicz
I don't have a TigerVNC install handy to play with, but would it not be possible to disable the authentication types you don't want on the server side?
Thanks for quick and also a detailed response! Last night, after noticing your reply, (but not being able to read it due to issues w/ my phone) I also realized I could have done this, and yes, after adding the following line in the ~/.vnc/config file:
securitytypes=vncauth
I was able to enforce the outcome I wanted from the server side, and the latest version also worked fine! Thanks for the suggestion!
So, my "feature request" of being able to specify the securitytype(s) on the RDM side can now be assigned a much lower priority!
Since you guys are doing such a good job (of eliminating the need for different clients for remote access! ;) ), I don't have an independent VNCViewer client installed to test, but can you please also confirm that, you're not doing anything special for cipher suites, and my original issue with the VeNCrypt security type is most likely due to a server side issue? (Since, both FreeVnc, and UltraVnc are both failing the same way, there already is a strong clue for this reasoning, but I wanted to double check)
(BTW, for sake of completeness: during my research, I ran into another post in this forum that was suggesting disabling TLS 1.3 for SCHANNEL in Win11 (for another TLS related issue), but that didn't help).
(Also, <IronVNC client in RDM - TigerVNC server> combination is even worse that it can't even get to those later handshake phases, but I'm not worried about that right now)
Thanks,
Ozgur
Hello
Yes, given that both freevnc and UltraVNC are having an issue, it strongly suggests a problem on the server side. I'd be happy to try and help you figure it out. Disabling anything in schannel on the client won't help; at least for freevnc we use mbedTLS.
Since you seem comfortable taking packet captures, I'd be inclined to Wireshark the connection attempt and inspect the TLS Handshake to see exactly what ciphers and TLS versions are being offered by the client.
The ironvnc integration is still in it's very early stages but we eventually hope to replace freevnc with that. So I'm not surprised it's not working in this case. Actually the library is very complete but we're still missing a lot of the interfaces we need to tie it into RDM (there are a lot, as freevnc is used extensively inside in RDM for different VNC flavours and VNC-like protocols).
Let me know if you have some questions or something isn't clear
Kind regards,
Richard Markievicz