-
-
Notifications
You must be signed in to change notification settings - Fork 63
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support standard VNC protocol authentication #277
Comments
I've seen no mention of plain text auth in rfc6143 or that it is required for conformance. Do you mean "VNC Authentication" (3des)? That's the only authentication method mentioned in the spec. I also do not see any mention of that being mandatory.
This is inaccurate. RealVNC, for instance supports a security type which uses RSA for authentication and key derivation and AES-XTS for encryption thereafter. I would also think that the Apples support a diffie-hellman based security type (30). It is their own extension, after all. Wayvnc implements both RealVNC's RSA-AES and Apple's security type 30. I would be curious to know if it works for macOS users.
I'd say it's secure enough for most users if they set the permissions correctly on their config files. It would be possible to make things more secure with a new security type, but only if all other security types are disabled. |
Yes, this is what I'm referring to. Given that the 3des algorithm and 8-character password limitation is very insecure by today's standards, and trivially bruteforced or decrypted, it's effectively similar to "plaintext" in practice. 1 A bit of a tongue-in-cheek reference to that insecurity, but effectively accurate. Although not "mandatory" per-se by the spec and "in theory", based on limited client support for the RSA-AES method, and other custom security protocol extensions made by many proprietary software vendors, "in practice" this becomes a bit more mandatory to implement as a basic level of support for insecure clients. 1: Some discussion of this over at TigerVNC's repo here |
Yeah, maybe I'm not being as clear or accurate as I could be. The idea I'm trying to get across is that although RealVNC does offer AES encryption as part of a paid/commercial packaged version, historically it wasn't offered with many free clients (whether OSS, freeware or "shareware"). |
🤔 Hmm... I wasn't able to get the RSA config option working in my testing. Yet, upon closer inspection it looks like this feature was added in |
As a quick followup to this: I was able to build packages Testing this with the RSA Security Type (
Again, TigerVNC does seem to support the RSA Security Type (as it also does for VeNCrypt TLS). TigerVNC connects fine after the TOFU key trust dialog box is accepted. I'm not sure what exactly Apple's So, based on this macOS client testing, we're still effectively left with a blocker for migrating old VNC servers to For what it's worth, |
But if you enable security type 30 via the |
In case it helps w.r.t. testing security type Info: New client connection from localhost: 0x561a7c26c680 (ref 1)
DEBUG: ../neatvnc/src/server.c: 183: close_after_write(0x561a7c26c680): ref 1
Info: Closing client connection 0x561a7c26c680: ref 0
Info: New client connection from localhost: 0x561a7c26c680 (ref 1)
DEBUG: ../neatvnc/src/server.c: 788: Client chose security type: 30
Info: User "d�V�Q����M�,�R6��ߐh���*6�q�=I"���;����6B��2�,ca��ND�@" rejected
DEBUG: ../neatvnc/src/server.c: 183: close_after_write(0x561a7c26c680): ref 1
free(): double free detected in tcache 2
[1] 2355153 IOT instruction (core dumped) wayvnc --gpu --performance --output=HDMI-A-1 --log-level=debug
## From SSH tunnel:
channel 5: open failed: connect failed: Connection refused macOS Info: New client connection from localhost: 0x562c3aeda680 (ref 1)
DEBUG: ../neatvnc/src/server.c: 183: close_after_write(0x562c3aeda680): ref 1
Info: Closing client connection 0x562c3aeda680: ref 0 |
Some more testing, using another macOS VNC client called
This client helpfully reports more information about unsupported Security Type, "
Info: New client connection from localhost: 0x556d54bc6690 (ref 1)
Info: Client 0x556d54bc6690 (1) hung up
Info: Closing client connection 0x556d54bc6690: ref 0 Same results when I tried Finally, this app has an idea of Apple's macOS User + Password authentication. Trying that with |
Sorry for the noise, but just had another thought... Given that last app's mention of |
The "None" security type is what you get if authentication is disabled. |
Got it! 🙏 Thanks... just tested with just Yet using
And log: Info: New client connection from localhost: 0x562977886690 (ref 1)
DEBUG: ../neatvnc/src/server.c: 183: close_after_write(0x562977886690): ref 1
Info: Closing client connection 0x562977886690: ref 0 |
I pushed a fix for type 30 to neatvnc master, so it should at least work with bVNC now. |
It looks like the "Screen Sharing App" might not like something that it sees. It might be interesting to look at this in wireshark. I don't have a mac and haven't used one since the noughties, so I can't really help you there, but if you record the network traffic I'd be happy to take a look. |
Thanks! 🙏 I was able to test with
I'd be happy to help with testing this! I'll have to get a |
Well, traffic on localhost:7900 won't be encrypted, but I'm off to bed anyhow. Thanks for testing! |
|
Ahh, could it be that it just wants an older version of the RFB protocol? Edit: That could very well be the case. See: any1/neatvnc#48 |
I also want to get back to the OP's initial request. |
I'm rather apprehensive about fail2ban. I wouldn't trust it myself. The problem here seems to be that |
I agree with @cRoCx : I use Apache Guacamole to access some devices exclusively using an OpenVPN tunnel and, at the moment, I can't use devices installed with raspbian+wayvnc . It would be helpful to have the standard VNC auth implemented in wayvnc. |
You can turn off authentication completely. Edit: I looked at guacamole's source and found out that it's using libvncclient, so you can use security types supported by libvncclient. This includes VeNCrypt and Apple's diffie-hellman based authentication type 30, which are both supported by wayvnc. See: https://github.com/LibVNC/libvncserver?tab=readme-ov-file#security-types |
Interesting, I'll take a look. Thanks |
Given that:
wayvnc
is currently the only VNC server implementation for Waylandplaintext authentication protocolVNC Authentication Security Type.wayvnc
due to this.wayvnc
stores thepassword=
option in a plaintext config file.Would you be willing to revisit #176 so that standard VNC clients will work properly with
wayvnc
server? (Either implementing this feature or accepting a Pull Request for this.)The option could be behind a config file key to switch on this functionality while maintaining that the user knows what they're doing is insecure (by design due to VNC basic auth protocol 1). For example, something like
insecure_plaintext_auth = true
,insecure_vnc_auth = true
,dont_blame_wayvnc = true
2, or evenplease_hack_me_use_plaintext_insecure_stupid_old_vnc_auth = true
.1: Historically, VNC was never secure for many reasons. Plaintext auth was one problem, but encryption/decryption of the VNC password config file was also trivially possible. Full disclosure: I'm the author of
vncpasswd.py
, which decrypts~/.vnc/passwd
and/or Windows Registry key for this using the known insecure AES decryption key.2: This is in reference to an option in Enterprise-level software, Nagios NRPE,
dont_blame_nrpe
which is actually used in practice on production servers, quite often. Engineers well-trained in security often enable it alongside firewall rules and/or secure tunnels, because they know what they're doing, and this option enables certain functionality which is otherwise unavailable.The text was updated successfully, but these errors were encountered: