Oplon Global Distributed Gateway release 10 is out!

Oplon Global Distributed Gateway release 10 introduces many new features. Four years of development, 2 new modules, dozens of new features make it a great major release innovation.

From the initial login, the distribution is enriched with information that they can always keep updated those who passionately use Oplon tools.

In addition to providing information on the latest version released, the home page contains links to ours social pages and the latest news that constantly informs about product developments but also insights on specific topics developed by the Oplon staff.

NOTE: At the time of writing this document, the latest version released is 9.9.13 and 10 is in release phase.

Preparation for installation

The new version of the Oplon suite is fully backward compatible with versions previous. Even the settings of users of previous versions while implementing the multitenancy functionality.

GDG core: Multitenancy

Multitenancy is now a fundamental part of the Oplon suite. With multitenancy it is possible to assign the management of different modules to as many users who can act on their own appurtenances without having the ability to interact with other tenants.

This technology allows different types of application which can be applied from technical fields to organizational up to commercial areas.

It is in fact possible to have people or groups of people, different in compliance with internal organizational policies.

It is also possible to assign modules to manage to different people or groups of people autonomously, such as Application Delivery Controllers (ADCs), commercially leveraging the use of features for multiple organizations.

In addition to the management for individual Tenants, these can be grouped in Resourse group so that being able to assign the management of multiple tenants to different people or groups. This feature facilitates the management of multiple integrators on different groupings of resources assigned to multiple customers.

The functionality has been specifically designed for large organizations or providers to be able to share resources with multiple customers and make the most of the computing power of modern systems.

ADC module: HTTP/2 Bridge - HTTP 1.1

A very powerful feature! HTTP/2 Bridge allows existing HTTP 1.1 applications to be exposed on the Internet with the new HTTP/2 protocol without the need to modify or reconfigure application servers or web servers.

How does HTTP/2 work?

The HTTP/2 protocol was implemented to decrease the number of TCP/IP connections for each single client from countless to one (1) connection while maintaining parallel use more resources typical of HTTP 1.0 and HTTP 1.1.

For this reason, HTTP/2 implements the multiplexing of the single TCP/IP channel by fragmenting more parallel streams in multiple frames crossing the TCP/IP channel. The frames, once arrived from the opposite side, are recomposed by the receiver and parallelized again. Data transfers are in double stream (full duplex) client to server and server to client.

In the image above and below it has been summarized in a drawing what happens inside the browser, where frames are multiplexed and de-multiplexed, and what happens inside of the ADC where the frames are recomposed and parallelized to the application servers/web servers. In the opposite sense, the response of the application servers to the single one is multiplexed open channel with the client.

This feature allows you to take full advantage of the new protocol and not modify the application infrastructure of the datacenter.

Maximum compatibility is guaranteed with all existing routing and content rewriting rules in previous versions and on all the features used by the Application Delivery Controller.

To activate the HTTP/2 bridge functionality is very simple. Just activate a new listener, starting from HTTP 1.1 and specify the HTTP/2 parameters or use the appropriate template:

ADC module: HTTP/2 Bridge - HTTP 1.0/1.1 autosensing

Nothing in your infrastructure needs to be changed to use HTTP/2!

If you have client applications that don't speak HTTP/2, such as using wget on procedures and scripts, no problem.

Oplon ADC is able to distinguish the client evolution level in advance and set communication over HTTP 1.0/1.1 or HTTP/2 depending on the client protocol.

The same listener with the same address and the same port can therefore be used interchangeably for applications that speak only HTTP 1.0/1.1 and from applications that also speak HTTP/2.

FIM new module: File Integrity Monitoring

The File Integrity Monitoring (FIM) module constantly checks the integrity of the existing system keeping under control.

FIM is able to detect file and directory tampering by immediately warning the violation by intruders, allowing immediate remedial action.

FIM is the module that allows you to obtain PCI-DSS certification. PCI-DSS affects any subject deals with specific information: the payment card number (technically known such as PAN) issued by Visa, Mastercard, American Express, JCB or Discovery brands. So all the commercial activities (shops, hotels, e-commerce operators), banks, service providers (hosting providers who hold credit card data in the database).

FIM can be activated on the entire Oplon suite for organizations that need to obtain the PCI-DSS certification or organizations that have a modern security system.

FIM can also be installed and activated on platforms other than Oplon to constantly verify the integrity of files and directories such as Apache, JBoss, Tomcat installations, MySQL, Linux OS. The system is however parameterizable and can be configured for any service.

Oplon File Integrity Monitoring integrates with all SIEM and centralized management systems alarms of datacenters and organizations.

GDG module: Let's Encrypt automatic renewal of certificates

This version adds to the already present functionality of automatic creation of digital certificates Let's Encypt through the ACME protocol, the ability to enable the automatic renewal of expiring certificates in compliance with Let's Encrypt specifications.

The system constantly checks that if the number of days of "warning" of the imminence of certificate expiration is reached, enters the renewal schedule. In fact, with Let’s Encrypt at the time of writing, places a limit of 5 simultaneous renewal requests with one consequent waiting for 2 minutes to carry out further renewals. The algorithm takes these limits into account scheduling the renewals of expiring certificates in advance and in a fractional manner.

CACERTM new module: Certification Authority & Certificates Manager

This new module integrates and amplifies the management of digital certificates for large organizations and service provider. This feature allows you to create root CA certificates, to sign additional ones intermediary CA certificates, to manage large volumes of certificates in a structured manner with bulk-load and bulk export functionality for distribution to users.

This module allows large organizations to easily raise the level of security access to applications without the need to use VPN for WEB applications.

The system, completely HTML5 via browser, has been designed to be simple and intuitive with wizard-driven operations.

Operations for the generation and massive maintenance of certificates can be carried out through the Excel import tool facilitating the initial header and being able to delegate it to staff not related to information technology as well.

In the same way it is possible to carry out a massive export of signed certificates in order to do so easily distribute to tempts.

ADC module: Domain loading and executing priority

With the domain management (virtual domain) it is possible to use, in addition to domains, expressions regular to analyze the name of the requested domain and perform the transfer to the services applications that match the rule. In this version, given the great use of this technique, Implementations have been made to scan in an orderly manner by visual setting.

Visually, it is possible to move the order of the domains from the graphical interface to determine the analysis priority and therefore routing during runtime.

This allows you to create simplified routing rules in case you manage countless domains.

ADC module: TLS 1.3

From this version, the SSL/TLS stack is completely renewed by introducing the new one TLS 1.3 protocol drastically reducing handshake times.

Below is the graphical representation of the number of messages exchanged for the establishment of the channel encrypted with TLS 1.2 and TLS 1.3.

Also with this new protocol it is possible to obtain Perfect Forward Secrecy with the new set of ciphersuite. However, protocoll and previous ciphersuites can still be used for applications not yet adhering to the new security implementations.

It is possible to differentiate the use of protocols between frontend and backend even for individual listeners and for single endpoints ensuring maximum flexibility of use.

The supported protocols are: TLSv1.3 TLSv1.2 TLSv1.1 TLSv1 SSLv3 SSLv2Hello

ADC module: ALPN protocol

ALPN protocol is fully supported both in listeners and in backend (endpoint) services.

The ALPN functionality allows you to indicate the application protocol to be used after the handshake TLS. Together with TLS-SNI it provides the possibility to use a single port address for multiple application protocols.

The implementation involves indicating the enabled application protocols and routing requests based on the proposed value.

ADC module: L4/UDP downtime Out Of Order

With the UDP protocol at layer 4 it was given the possibility to temporarily put in Out Of Order an endpoint when the expected response exceeds the set timeout. To activate the new functionality is sufficient, in a layer 4 UDP communication, to indicate in the endpoint a downtime greater than 0 milliseconds.

ADC module: TLS-SNI implementation sniForwarding

With end-to-end TLS-SNI connections terminated in the listener you can specify to run the forwarding of the host name (domain) indicated in the handshake to the endpoint during the re-handshake encryption.

It remains possible to establish a TLS-SNI connection with a domain name other than that indicated in the connection terminated in the listener.

Or a connection on the endpoint without the support of the TLS-SNI protocol.

ADC module: New parameters functions

New parameters to manage the multiple application routing activities have been implemented some features that make management easier.

Among these the following parameters have been added:

1. redirectToSSL - if set and the connection arrives in clear text, a redirect is performed with the same values but in SSL

2. proxyDestionation - is a new parameter of the proxy pass functionality. It allows to change the "Destination:" header element with the new value set. Mostly used on WEBDAV connection.

3. removePortFromHost - if set, allows you to remove the port indication in the header element Host:. For example, if the value arrives in the HTTP header Host: http: //www.mydomain.com: 4443, the endpoint service will be delivered Host: http: //www.mydomain.com:

WRSK module: WORKSPACE

In the concise views of the ADCs there are now also the panels that highlight the status of connections with Highwater, Tunnelse Sessions. This allows you to have in a single point to view the status of that specific ADC or ADC cluster.

WRSK module: REST API

REST API features have been released that allow you to safely run script operations. The functions are self-documenting through the online help directly from the browser.

By accessing the console with the URI https://ip_address: 4444/japi/help, after authenticating you will be proposed the list of available APIs.

By entering the link for each function, the help is available to make the best use of it.

ADC module: New templates

New templates have been implemented to facilitate service setup operations with adaptation to the new protocols. In particular, the following are the new templates:

1. HTTP/2 listener: Allows you to create an HTTP/2 listener

2. HTTP/2 listener with client certificate request: Allows you to create an HTTP/2 listener with set the request parameters of the client certificate authorized by digital certificate registered in a truststore.

3. x-forwarded-headers - http header rewite rule: this rule introduces the features necessary to communicate the use of a reverse proxy to WordPress.

4. RewriteHref_From_Http_To_Https - http body rewrite rule: modify the html bodies coming from endpoint services from "http" to "https". This rule is useful in cases where endpoint services are not in SSL and refer to links not in SSL.

5. OplonHTTPCookieSetOption - http header rewite rule: On services that do not rely on cookies security systems it is possible to modify them on-the-fly during the creation phase Set- Cookie, to add features that enable new security implementations such as sameSite, Max-Age, secure, HttpOnly, Domain...