Summary
We would like a server-side option — ideally a flag in ultravnc.ini — that lets ultravnc not require the DSM encryption plugin (and, optionally, not require additional authentication) for connections that originate from 127.0.0.1/localhost. In our deployment encryption and authentication are already provided by the transport layer (an SSL tunnel), so the DSM handshake on top is redundant overhead and an extra failure mode.
Setup / context
We wrap the VNC server in an SSL tunnel (OpenSSL/stunnel-style) that terminates on the target host itself and forwards to ultravnc on 127.0.0.1/localhost:5900. Because the tunnel terminates locally, the connection reaching ultravnc appears to come from localhost.
Problem
ultravnc enforces the DSM plugin and VNC auth for all connections, including loopback. In a tunneled topology this means double encryption (no benefit), an extra handshake stage that adds timeout/drop failure modes (cf. #360/#361, worse with SecureVNC's multi-stage DSM handshake), and no clean "tunnel already secures it" config.
Proposed solution
Opt-in ultravnc.ini settings, e.g. AllowLoopbackWithoutDSM=1 and a separate AllowLoopbackWithoutAuth=0. For a loopback-origin connection, proceed without the DSM plugin (plain RFB over the already-encrypted tunnel); non-loopback addresses behave exactly as today.
Security rationale
The peer is already mutually authenticated and the channel encrypted at tunnel establishment. The trust boundary is the tunnel, not the loopback socket. Scoped to loopback origins (not network-reachable), opt-in, default off.
Safeguards
Default off; loopback-only gating (guard against spoofing in the accept path); independent DSM-skip vs. auth-skip switches; log when the relaxed path is used for auditability.
Related
#360, #361 — both aggravated by the extra DSM handshake stage.
Summary
We would like a server-side option — ideally a flag in
ultravnc.ini— that lets ultravnc not require the DSM encryption plugin (and, optionally, not require additional authentication) for connections that originate from127.0.0.1/localhost. In our deployment encryption and authentication are already provided by the transport layer (an SSL tunnel), so the DSM handshake on top is redundant overhead and an extra failure mode.Setup / context
We wrap the VNC server in an SSL tunnel (OpenSSL/stunnel-style) that terminates on the target host itself and forwards to ultravnc on
127.0.0.1/localhost:5900. Because the tunnel terminates locally, the connection reaching ultravnc appears to come from localhost.Problem
ultravnc enforces the DSM plugin and VNC auth for all connections, including loopback. In a tunneled topology this means double encryption (no benefit), an extra handshake stage that adds timeout/drop failure modes (cf. #360/#361, worse with SecureVNC's multi-stage DSM handshake), and no clean "tunnel already secures it" config.
Proposed solution
Opt-in
ultravnc.inisettings, e.g.AllowLoopbackWithoutDSM=1and a separateAllowLoopbackWithoutAuth=0. For a loopback-origin connection, proceed without the DSM plugin (plain RFB over the already-encrypted tunnel); non-loopback addresses behave exactly as today.Security rationale
The peer is already mutually authenticated and the channel encrypted at tunnel establishment. The trust boundary is the tunnel, not the loopback socket. Scoped to loopback origins (not network-reachable), opt-in, default off.
Safeguards
Default off; loopback-only gating (guard against spoofing in the accept path); independent DSM-skip vs. auth-skip switches; log when the relaxed path is used for auditability.
Related
#360, #361 — both aggravated by the extra DSM handshake stage.