We are very happy to announce a new Green Screens Server v6.0.0.0. Today, we released the latest major version after being 8 months in development and 3 months in pre-production testing and bug chasing.
GSv4 & GSv5 versions are production battle tested in large organizations with thousands of workstations and used as a critical infrastructure product. Based on that premise, we continue our development and product improvements.
The new version is a big step forward. After removing support for MS IE, we were able to implement modern web technologies available in modern browsers. At the backend side, changes are mostly related to security and server automatic configuration improvements.
Check below for the list of the most important changes in GSv6!
A full change list can be found here.
MS IE deprecation
Removing support for IE allowed us to remove all 3d party libraries required for IE and to use modern browser native APIs and other modern features. Removing such libraries makes web terminal loading faster and lighter than ever before, with reduced memory usage. Deprecating IE, allowed us to use modern JavaScript constructs to get leaner and cleaner code. Easier to maintain, extend and develop.
UI changes
A front-end part is completely new. Written from scratch, based on modern web technologies such as WebComponents. Complete UI such as Web Admin and login forms etc. are now based on our own modern and open source Web UI library.
Adding new features in future versions will be easier and faster than ever before.
How big change is that, for an example, the latest Web Admin console base code is now only 43 KB compared to some 2 MB for previous version.
If you want to see the glimpse of a new Web Admin console, check out our demo version here.
Quark Engine
Quark Engine is our own modern and open-source library for web-2-server RPC calls. It is updated to support function parameter overloading, request timeouts, easy to use event based request processing and many more. The most important change is removal of callback mechanism, replaced with modern "async/await" constructs, which is not supported by MS IE. This change allows us to create cleaner and more maintainable code also.
Web Security
Our Web 5250 Terminal encrypt requests from its beginnings, protecting data while traveling cross the networks even if HTTPS is not used. However, with MS IE, we were limited to JavaScript 3rd party libraries to allow encryption simply because other modern browser features required are not available in IE. Such libraries implementing RSA based security adds additional memory requirements, are slower and less secure than native counterpart.
Deprecating IE, allowed us to use highly secure and browser native encryption API with fallback to WebAssembly modules when Crypto API is not available (HTTP mode).
Also, we replaced a module to support encryption when Crypto API is not available (when HTTPS not used) with more modern version. In the future, we will remove that also, and rely only on browser based native features, forcing our clients to use HTTPS as mandatory.
Web Terminal URL
The main terminal URL is now switched from /lite to /terminal. The old link will still work, as we added automated redirection to a new address.
Server automatic configuration
After initial installation, upon first server start, server will reconfigure itself by automatically preparing HTTPs, digital certificates and security stores where private keys are stored. We significantly improved that process. Also, we increased keys storage security to the next level with brute force tampering prevention.
Server data security
At the server back-end part, most of the changes relate to security mechanism changes and improvements. All server side data such as certificates and private key stores are now highly protected from tampering with dynamically calculated security keys.
In a case, master key storage is lost or corrupted, we will be able to help as we use ECDH shared encryption based on our public key distributed with the product. This will allow us to regenerate private key for data decryption as long as client keep server generated public key for encrypted data restore.
Now, sensitive data such as FIDO/OTP/API Key records use stronger encryption. Every record is stored individually, as an encrypted binary file, to reduce data corruption and to ease recovery in a case of disk/file or secure storage disaster.
TLS/HTTPS Certificates
We added many improvements to the server TLS/SSL certificate configurations, such as PFX/P12 file import support. Certificate request mechanism is improved to generate signing requests. Private key export is optional, keeping it unknown to anyone else except the server itself.
Certificate PFX/P12 file imports now can automatically detect and rearrange certificate chains to create a valid server certificate configuration. Order of Base64 encoded private/public keys inside an import file are not relevant.
Certificate hot-deployment
In previous versions, server restart was required after importing or generating new server HTTPS certificates. Now, certificate update can be hot deployed without any interruption. Newly loaded certificates will be automatically applied to new network connections.
Certificate REST API
A new REST API service protected by an API Key is added to allow remote programmatic server certificate installation. API Key is linked to a connecting IP address filtering. This allows a better integration with other systems and services.
Certificate automatic loading
A new special monitoring directory for certificate automatic load is added, useful when the server is linked to ACME certificate service but running on different ports than required by ACME protocol. Simply, upload required files to a monitoring directory and GS server will apply them automatically.