any1
VNC Support for macOS clients
I am a bit puzzled to see MacOS 10.15.3 Catalina native VNC client requesting Client Protocol version 3.3 using Wireshark. Would it be difficult to support this in neatvnc? My use case is wayvnc.
The first published version of the rfb protocol was version 3.3. This was in 1998. The current revision (3.8) was published in 2007. It is puzzling indeed that an entity such as Apple hasn't caught up by now. Have you considered filing an issue with Apple?
Frankly, I'd prefer not to complicate the code needlessly. Is there no alternative VNC client software for MacOS?
@any1 Would you be interested in a PR to support RFB 3.3 clients? I ask as I read https://github.com/any1/wayvnc/issues/277#issuecomment-2634502214
@any1 Would you be interested in a PR to support RFB 3.3 clients? I ask as I read any1/wayvnc#277 (comment)
If it doesn't add a lot of code, I'll take it. However, keep in mind that I can't really test this myself since I don't have any apple products, so I can't guarantee that it won't break between releases.
I can't really test this myself since I don't have any apple products, so I can't guarantee that it won't break between releases.
If there are any MacOS related issues feel free to send them my way.
I have the RFB 3.3 part working with VNC Authentication at thezealousfool/neatvnc and thezealousfool/wayvnc but I am running riverwm and do not have cursor capture and seems like MacOS does not like that. If someone running a wayland wm with cursor capture (Gnome/KDE ?) checkout the rfb3.3 branch and see if it works that would be great. I will try to setup Gnome in a couple days and test if no-one else steps up.
I didn't know this (or I forgot), but according to spec, only security types 1 and 2 are supported for 3.3. This makes me like this a lot less than I otherwise would have. However, what happens if you ignore that and you tell it to use RFB_SECURITY_TYPE_APPLE_DH instead of the 3DES crap?
Did some digging. Turns out we do not need RFB 3.3 for Apple's VNC. If we set the RFB Version Message to RFB 003.889 we can use RFB_SECURITY_TYPE_APPLE_DH with username and password. I still need cursor capture to fully test but it certainly goes past authentication into Starting screen capture but then goes into connect-disconnect loop which I think is because of the cursor capture.
There is some mention of this here: https://github.com/LibVNC/libvncserver/blob/1c5d989ab50ee2baeb2fda717bc9c622516ccf98/include/rfb/rfb.h#L465
Using APPLE_DH I am getting messages that are not yet supported by neatvnc specifically:
- 9 SetServerInput
- 10 SetSW
- 16: This seems to be encrypted keyboard + mouse pointer events
Do we want to add apple_dh decryption abilities?
Do we want to add apple_dh decryption abilities?
You mean to ask if those other events should be implemented to support Apple's whacky protocol "version"? Sure, if you're up for it.
Version 3.3 without 3des would also be OK, but it would only be enabled when authentication is disabled.
So, Apple does not support "None" authentication I think because even when I set it 0 it asks for password. So either use 3des or implement Apple specific messages.
Riight. I meant 1 (I used the enum value). It still asks for password.
https://github.com/LibVNC/libvncserver/blob/1c5d989ab50ee2baeb2fda717bc9c622516ccf98/src/libvncserver/auth.c#L147
Don't know why my client does not send None, or how to make it send None.
I'd rather not have broken cryptography implemented. Would you be willing to try to figure out how to decode message 16?
By the way, does Apple's client give any warning about the connection being insecure when you connect using 3des?
This is probably relevant: https://github.com/rfbproto/rfbproto/issues/52#issuecomment-1591695202
I did not see any warnings.
Yes I can figure out message 16 and whatever else comes after that.
One more thing that needs to be discussed is how to handle the server sending the 889 version message. As far as I can tell, if the server sends 003.008 the Apple client falls back to 003.003 and only uses 889 when the server also said 889. I don't know if there is some way around it. We almost need a configuration option as to what the server broadcasted minor version should be. But will that mean if the config says 889 and server broadcasts that we can only connect from apple and nothing else? That would be quite unfortunate - having to change configuration every time connecting from apple or something else.
As far as I can tell, if the server sends 003.008 the Apple client falls back to 003.003 and only uses 889 when the server also said 889.
Yes, that is rather unfortunate. However, the specification says:
Handshaking begins by the server sending the client a ProtocolVersion message. This lets the client know which is the highest RFB protocol version number supported by the server. The client then replies with a similar message giving the version number of the protocol which should actually be used (which may be different to that quoted by the server). A client should never request a protocol version higher than that offered by the server. It is intended that both clients and servers may provide some level of backwards compatibility by this mechanism.
Although it isn't explicitly stated, I think that this strongly implies that a conformant client will simply reply with 003.008 if the server sends 003.889.
I am okay with reporting version 003.889, but it should be gated behind a config option. If this version is rejected by tigervnc, realvnc or libvncclient, we might consider enabling it on a separate port.