Request for AnonDH option

[frispete]

Hi,

I stumbled across this issue yesterday.

Setup: serving VNC though Xorg server module:

Section "Module"
    Load "vnc"
EndSection

Section "Screen"
    Identifier "Screen0"
    Option "SecurityTypes" "TLSVnc"
    Option "PasswordFile" "/root/.vnc/passwd"
EndSection

Reasoning: provide the most simple and flexible cryptographically secured VNC support.
Works for all interesting desktop clients, but Android bVNC with Android versions >= 6.0.
Solution: provide an option to NOT offer Diffie Hellman anonymous key exchange in TLS setup, e.g. Option "AnonDH" "off", similar to the x11vnc option -vencrypt nodh:only.

The default of TigerVNC seems to be susceptible to MITM attacks, and therefore is not supported anymore on newer Android devices.

Simply removing ":+ANON-ECDH:+ANON-DH" from kx_anon_priority seems not enough, I'm afraid.

Please consider such a change.

[frispete]

Here's the VNC log with such an unsuccessful attempt:

2017-09-02T15:48:17.205836+02:00 kuno Xorg[13050]: Connections: accepted: x.y.z.z::45397
2017-09-02T15:48:17.208614+02:00 kuno Xorg[13050]: SConnection: reading protocol version
2017-09-02T15:48:17.209146+02:00 kuno Xorg[13050]: SConnection: Client needs protocol version 3.8
2017-09-02T15:48:17.210741+02:00 kuno Xorg[13050]: SConnection: processing security type message
2017-09-02T15:48:17.211294+02:00 kuno Xorg[13050]: SConnection: Client requests security type VeNCrypt(19)
2017-09-02T15:48:17.211704+02:00 kuno Xorg[13050]: SConnection: processing security message
2017-09-02T15:48:17.213733+02:00 kuno Xorg[13050]: message repeated 2 times: [ SConnection: processing security message]
2017-09-02T15:48:17.214131+02:00 kuno Xorg[13050]: XserverDesktop: client gone, sock 29
2017-09-02T15:48:17.214562+02:00 kuno Xorg[13050]: Connections: closed: x.y.z.z::36660 (Clean disconnection)
2017-09-02T15:48:17.214960+02:00 kuno Xorg[13050]: EncodeManager: Framebuffer updates: 0
2017-09-02T15:48:17.215371+02:00 kuno Xorg[13050]: EncodeManager:   Total: 0 rects, 0 pixels
2017-09-02T15:48:17.215774+02:00 kuno Xorg[13050]: EncodeManager:          0 B (1:-nan ratio)
2017-09-02T15:48:17.216171+02:00 kuno Xorg[13050]: ComparingUpdateTracker: 13.395 kpixels in / 11.219 kpixels out
2017-09-02T15:48:17.216565+02:00 kuno Xorg[13050]: ComparingUpdateTracker: (1:1.19396 ratio)
2017-09-02T15:48:17.219735+02:00 kuno Xorg[13050]: SConnection: processing security message
2017-09-02T15:48:17.219948+02:00 kuno Xorg[13050]: SVeNCrypt: Client requests security type TLSVnc (258)
2017-09-02T15:48:17.220103+02:00 kuno Xorg[13050]: TLS: Process security message (session (nil))
2017-09-02T15:48:17.254022+02:00 kuno Xorg[13050]: TLS: Anonymous session has been set
2017-09-02T15:48:17.254584+02:00 kuno Xorg[13050]: TLS: Deferring completion of TLS handshake: Resource temporarily unavailable, try again.
2017-09-02T15:48:17.344450+02:00 kuno Xorg[13050]: SConnection: processing security message
2017-09-02T15:48:17.344966+02:00 kuno Xorg[13050]: TLS: Process security message (session 0x2307c90)
2017-09-02T15:48:17.345374+02:00 kuno Xorg[13050]: TLS: Deferring completion of TLS handshake: Resource temporarily unavailable, try again.

[bphinz]

Have you tried using X509vnc as the security type?

[frispete]

Unfortunately, that security type is not available, neither with bVNC nor with bVNC Pro. :(
Apart from that, fiddling with certificates isn't the most convenient thing on earth, either.

[bphinz]

I'm not sure exactly what you are asking for, isn't x11vnc's "-vencrypt nodh:only" equivalent to using -SecurityTypes X509vnc? Also, I don't know what encryption protocol you are expecting that will mitigate MITM attacks without the use of certificates.

[frispete]

I'm not sure exactly what you are asking for, isn't x11vnc's "-vencrypt nodh:only" equivalent to using -SecurityTypes X509vnc?

With "-vencrypt nodh:only", it allows bVNC to connect on newer Android devices with an option, that is called "Secure VNC with VeNCrypt". On Android devices below 6.0 (Marshmellow), this works nice since years. This option not the same as X509vnc, if I understand all this correctly, but gives reasonable security without big fuzz.

Also, I don't know what encryption protocol you are expecting that will mitigate MITM attacks without the use of certificates.

Unfortunately, X509 certificate based schemes are not supported from any of my typical VNC clients (krdc and bVNC).

For various reasons, I much prefer TigerVNC over x11vnc (that I used for years). It excels in performance, is much better integrated in the Xorg environment, doesn't require fiddling with /etc/X11/xdm/Xsetup and kdm config in order to support the display manager properly, and handles shared mode much more reliable...

OTOH, TigerVNC does require a patch to /etc/xdg/kwinrc to force XRender mode for the compositor, and bails out on this issue. With this issue fixed, the advantages surpass the x11vnc approach by far. With time passing, more and more android devices will be locked out by it. Therefore, I kindly ask for such an option. If somebody with more insight in the VNC security schemes and types could advise me, I might be able to provide a SR.

I've looked into both, x11vnc and TigerVNC, but the code bases deviate immensely in this respect. :(

[bphinz]

With "-vencrypt nodh:only", it allows bVNC to connect on newer Android devices with an option, that is called "Secure VNC with VeNCrypt". On Android devices below 6.0 (Marshmellow), this works nice since years. This option not the same as X509vnc, if I understand all this correctly, but gives reasonable security without big fuzz.

I've looked at the x11vnc code, and all -vencrypt nodh: does is prevent the TLS* subtypes from being added to the list of supported types: (line 1688, src/sslhelper.c)

	if (!ssl_verify && vencrypt_kx != VENCRYPT_NODH) {
		if (screen->authPasswdData != NULL) {
			subtypes[n++] = rfbVencryptTlsVnc;
		} else {
			if (vencrypt_enable_plain_login && unixpw) {
				subtypes[n++] = rfbVencryptTlsPlain;
			} else {
				subtypes[n++] = rfbVencryptTlsNone;
			}
		}
	}

Have you verified which security type your client is actually using in both the old and new versions? In the snip that you sent, it's clear that the client requested the TLSvnc subtype:

2017-09-02T15:48:17.219948+02:00 kuno Xorg[13050]: SVeNCrypt: Client requests security type TLSVnc (258)

This seems like a client-side bug to me. If the client doesn't support the anonymous TLS subtypes, then why is it requesting it? Please see the VeNCrypt protocol specification for more info on how the subtype is negotiated.

[frispete]

Hi Brian,
your investigation is much appreciated. Thank you.

Iordan bases his TLS processing on Android infrastructure, and if I read the supported cipher suite table correctly, the anon variants are available for SSLv3 only, but not for any TLS protocol. The relevant code of bVNC is here. Could this indeed be the problem?

Questions arise, how anonymous TLS variants are supposed to work at all then with Android, which ones are typically supported in VeNCrypt, and/or is Google overshooting the target (once again). 👎

TigerVNC seems to support the anonymous ECDH variants as well, which shouldn't be that bad...
To my knowledge, there're still other heavily used remote desktop protocols out there, that suck rocks cryptographic wise...

Cheers,
Pete

[bphinz]

It's not an issue with the bVNC code. The Android API appears to have removed support for all of the DH_anon ciphers as of API level 23. The VeNCrypt TLS* subtypes are, by definition, anonymous TLS (see section 6.2.19.257 of the aforementioned VeNCrypt spec). The bVNC client leverages the Android API in much the same way that our java client does with the JRE. If Oracle or OpenJDK decided to remove support for those ciphers then we would be in the same position. I don't have much experience with Android, but in the case of Java it would be possible to implement a custom security provider instead of relying on what's provided by the JSSE (Bouncy Castle, for example). The bVNC home page seems to indicate that the VeNCrypt X509 subtypes are supported, as a short-term solution I would suggest trying those. Generating certificates isn't really that much work and it would be more secure.

[CendioOssman]

I agree with @bphinz. There doesn't seem to be an issue here. What you are asking for already exists. Just replace TLSVnc with X509Vnc in your configuration and add the X509Cert and X509Key options. It might not even have to be a "proper" certificate, depending on what ability bVNC has to handle bad certificates.

Anonymous TLS isn't a very good idea to begin with, so I can't really blame Google for removing it.

[frispete]

Hi @CendioOssman,

I checked your suggestion, and indeed, it fixed the problem with bVNC. Unfortunately, I'm locked out with my primary VNC client with such a setup, that I use about a dozen times on every day: krdc 😞

Not sure, if I like my current opportunities, as it basically renders TigerVNC unusable for me, which is a pity, since it does another couple of things much better than x11vnc.

I've tried to combine my necessary security types:
Option "SecurityTypes" "TLSVnc,X509Vnc"
but depending on order either one or the other client chokes on it.

[CendioOssman]

I'm afraid you'll have to report those bugs to them in that case. We can't really break our stuff just because of other buggy clients.

[iiordanov]

@frispete, I believe all you'd need to do to make my client (bVNC) work with the TigerVNC settings:

Option "SecurityTypes" "TLSVnc,X509Vnc"

on Android 6.0+ devices is to change your "Connection Type" from Basic VNC to "Secure VNC over VeNCrypt".

This should cause bVNC to force the use of X509Vnc over TLSVnc. Then, if my understanding is correct, your other client will work too.

[iiordanov]

All VNC modes are supported with VNC over SSH. The modes that explicitly say for example VeNCrypt, are there to force the usage of that encryption rather than automatically selecting the fist supported one. Thanks! Iordan

…

On Jan 17, 2018 5:02 PM, "Alain Kalker" ***@***.***> wrote: @iiordanov <https://github.com/iiordanov> This may work for "Basic VNC", but what about "Secure VNC over SSH"? What if a user on the remote host runs x0vncserver and has a password configured (to prevent other users on that same host from connecting without a password)? I.e. in bVNC there is no option "Secure VNC over SSH with VeNCrypt"... I know it looks a bit paranoid, but whatever. better too much security than too little. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#507 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABWyV2jwGVMWsyKOoRrIFcO6V4AjvtzUks5tLm3fgaJpZM4PK5xa> .

[michael-ts]

@iiordanov Are you saying that using "VNC over SSH" should just work? Because I had it working between Android 9 and Ubuntu 18.10 with that setting, but when I did a new 20.10 install it refuses to connect because the key changed and (yech) wants me to recreate the connection. But when I do that I get this error.

Of note, I'm using the "tigervnc-scraping-server" package because I'm actually running x0vncserver. When I try to use the "-vencrypt" option mentioned above I just get a usage message so that route isn't working for me either.

It sounds like it should work, but after reading this entire thread it's unclear to me exactly what I need to do to make it work.

[iiordanov]

The bottom line is that there are still Anonymous DH ciphers being offered up by the server with whatever auth mode your server ends up starting. The "-vencrypt" option you mention sounds like an x11vnc server option, not a tigervnc server option.

I posted a thorough answer on the support forum for bVNC where I felt it may be read by more people:
https://groups.google.com/g/bvnc-ardp-aspice-opaque-remote-desktop-clients/c/qCuJs-6ZC-s/m/P8EFPsmmAgAJ