Properly store certificate exceptions in Java viewer
Like the native viewer, the Java viewer didn't store certificate
exceptions properly. Whilst not as bad as the native viewer, it still
failed to check that a stored certificate wouldn't be maliciously used
for another server. In practice this can in most cases be used to
impersonate another server.
Handle this like the native viewer by storing exceptions for a specific
hostname/certificate combination.
Make all viewer parameters static. Viewer instances are isolated from each other by spawning a completely new process for each viewer, rather than simply starting a new thread. All dialogs were redesigned to better match the look of the native viewer, and also to be more tolerant of sizing differences between platforms.
95f39a5 introduced a regression whereby an exception would be thrown
when a PEM encoded CA certificate file containing one or more blank
lines was read in under Apple Java 6. Additionally, CA certs were
being appended to the ~/.vnc/x509_savedcerts.pem file even if they
were already included in it. Also fixes a possible FileNotFoundException
if the x509_savedcerts.pem file didn't exist.
Fixes #193 and also adds automatic certificate saving feature like
the Fltk viewer. Also pulls in CA certificates from all trusted
authorities known to the JRE for the case when the server is using
a certificate from a top-level authority.
The SSLEngineManager was basically an abomination. The work is now
done as it should be, with the buffers being fed and the engine
deciding when data is consumed or produced. The engine should be
much more robust now as well.
Additionally, although JRE 7 supports the TLSv1.1 and TLSv1.2
protocols, they are not actually enabled by default. The JSSE
reference cites compatibility reasons for this but this doesn't
appear to be the case with the TigerVNC server and they will be
enabled by default in JRE 8.
The regular expression for enabling anonymous DH cipher suites
was too narrow and excluded the elliptic curve ciphers, which
are now ordered ahead of the ephemeral ciphers by the default
security provider.
Lastly, increase the size of the buffer in FdOutStream from 8Kb
to 16Kb. I'm not sure why FdInStream and FdOutStream were
asymmetric to begin with, but 16Kb is the default size for TLS
packets and there seems to be now negative effects on plain
text connections.
Implemented rfb/Configuration similar to the native client methods. Added equivalent cmd line options for all native client options except "-menuKey", which needs a little more work on the GUI side before it can be added.
Replace all stream-based IO with non-blocking NIO-based implementation. Still a fair amount of cleanup to do, particularly in the SSL handler, which is not very robust, and exception handling in general. All core functionality appears to be working fine though.
The previous fix to the NullPointer issue did not work, because it was simply setting separator to null (not what we want.) Fix the issue properly + fix spelling of "separator".
Fixes for bug #3418258. Cleans up all of the 'unchecked' and 'deprecated' linter warnings. Several of the redundant casts have been intentionally left for clarity. Set '-serial' and '-cast' linter flags to reduce the number of warnings (it should be safe to ignore serial because the end product is a jar rather than individual class files. AFAIK, there is no performance penalty for redundant casts in Java). If anyone objects to the linter flags they can be removed (the linter flags, that is).