Also, with respect to Java, if you are running a standalone Java application, then it is no more or less secure than a standalone native application. The security risks you refer to are primarily related to running Java in a web browser, which most web browsers don't support anymore. The Java TurboVNC Viewer still supports an in-browser applet mode, but even the company who paid for that feature can no longer use it because of lack of Java plugin support in modern browsers. It really isn't an issue unless someone absolutely needs a VNC viewer that runs in their browser window. Otherwise, Java Web Start can easily be used to launch the TurboVNC Viewer in a "zero-install" capacity, without requiring any browser plugins, as long as a JVM is installed on the client machine. I'm also looking into extending noVNC to support the RFB flow control extensions and other features necessary to make it perform reasonably on WAN connections. It will never perform very well on LAN connections, but I'd like to at least make it as fast as possible, so it can serve as a stopgap for those who previously needed the in-browser TurboVNC Viewer applet. The long-term solution for an in-browser VNC viewer is probably WebAssembly, but all of that stuff is still in a state of flux right now.
With the exception of risks introduced by improper installation or configuration, probably the worst-case security risk of a VNC viewer is that you're using the built-in session encryption feature (VeNCrypt) with a buggy underlying SSL implementation, which could conceivably (but not easily) expose you to such exploits as a "man in the middle" attack. It is conceivable that such an attack might allow the attacked to snoop your Unix login credentials, if you were authenticating with the server using those credentials. That's actually an argument in favor of Java, however, because the underlying SSL implementation that our Java viewer uses is part of the JVM, and Oracle does a pretty good job of keeping abreast of any security flaws in it. Producing a cross-platform native viewer would require that we either link statically with OpenSSL or GnuTLS (requiring us to keep abreast of any potential security flaws in those libraries ourselves-- no thanks) or to load OpenSSL on demand like we do in the server. The latter approach will probably be the approach I take to implement session encryption in the next-gen cross-platform native viewer, but that approach is really no more or less secure than Java. It still relies on someone else-- in this case, the O/S distributor-- to keep abreast of security bugs in the SSL/TLS libraries. On Linux, this is really no different than using Java, since the distribution-supplied OpenJDK implementations will themselves link against the system-supplied build of GnuTLS or OpenSSL. But Java has a slight edge, because-- at least on Linux-- you can obtain it from multiple sources. So if the distribution-supplied JVM has a security bug that Oracle has fixed, you can install Oracle's version until the distribution maintainers fix the bug in their implementation. The historical reasons behind the hybrid Java/native viewer on Mac and Linux platforms were primarily monetary. I received funding in the 2012 timeframe to develop a proof-of-concept Android TurboVNC Viewer, and since Android is a Java-based platform, the first phase of this involved improving the Java TurboVNC Viewer so that it had the necessary underlying features to provide a full-fledged TurboVNC Viewer experience. Phase 2 would have involved developing a new, Android-specific GUI. The project was dropped prior to Phase 2, but since the resulting Java TurboVNC Viewer was much more user-friendly and feature-rich than the existing Un*x/X11 viewer (which, at the time, was based on Xt, which required XQuartz on Mac and had the crappiest GUI imaginable), the Java viewer was phased in as a replacement. In TurboVNC 1.2, the Java viewer fully replaced the Xt viewer on Mac platforms and was provided as an option on Linux platforms. With TurboVNC 2.0, I introduced a new glueware library on Linux that worked around some underlying Java/X11 interaction issues, which allowed the Java/native hybrid viewer to fully replace the Xt viewer, so the Xt viewer was retired in that release. I do recognize that, at least on Mac and Windows platforms, a Java viewer introduces additional install dependencies that may not be desirable in all cases. Also, our Windows viewer is popular and has some GUI features that the Java viewer lacks-- another reason to expand it to other platforms. Fortunately, there is now funding to look into this, although the feature may not be fully implemented until next year because it is not the highest priority. On 3/17/17 9:37 PM, Steve Volumetric wrote: > DRC - thanks for putting all this together, by the way. I'm a big fan. > Unrelated, I gave up on trying to compile the turbovnc viewer from > source (my linux distro is too weird) and I got up and running off your > precompiled rpm that I pried apart. You're right - the performance is a > staggering improvement over TigerVNC even with the java dependency! > > On Fri, Mar 17, 2017 at 9:34 PM, DRC <[email protected] > <mailto:[email protected]>> wrote: > > The Windows viewer has a pure C++ version, but other platforms require > Java at the moment. Why is that a limitation? It's as fast as our > native viewer and considerably faster than TigerVNC's native viewer on > Mac platforms. I am looking at a cross-platform native viewer in the > long term, probably based on our Windows code but ported to some > cross-platform toolkit like GTK. For now, however, Mac and Linux > require Java. > > On 3/17/17 6:22 PM, Steve Volumetric wrote: > > I'm hoping the viewer isn't completely java dependent, though so far > > that's the only way I've been able to build it. ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ TurboVNC-Users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/turbovnc-users
