Using PTV xServer with HTTPS

The HTTPS protocol comprises the encryption and decryption of HTTP messages.
These operations are not part of the PTV xServer functions but have to be done by a web server or a proxy with message redirection.

Deployment Scenarios

Assuming that a PTV xServer cluster is being set up with a load balancer, there are several deployment scenarios possible:

Different deployment scenarios to handle SSL encryption/decryption with HTTPS

As an alternative scenario (2), each PTV xServer can be deployed behind their own proxy server which redirects HTTPS requests to the PTV xServer Tomcat as simple HTTP. The third scenario (3) uses the load balancer proxy, or puts the SSL proxy directly in front of the load balancer.

Evaluation of Deployment Scenarios

These scenarios all have specific advantages and disadvantages regarding:

1. Security

2. Cost of Required Certificates

3. Effort for Deployment and Maintenance

4. Network Traffic and Latencies

5. Distribution of CPU Load

We assess the scenarios as follows:

Assessment of the Scenarios

Web Server Bundled with PTV xServer

The Tomcat web server bundled with each PTV xServer is merely a means of enabling web communication and is not meant to secure the system: The Apache Tomcat Container is not easy to update outside the PTV xServer release cycles. It requires a very lax access policy setting so that PTV xServer components can efficiently collect data from different local and remote sources.

Also, the SSL certificate must cover multiple servers: Either each server receives its own certificate, or a (more expensive) wildcard certificate is required.

Therefore, for most situations we highly recommend to not use the PTV xServer web server to handle HTTPS.

For testing purposes the Tomcat web server can be configured to use HTTPS: Activate HTTPS

Multiple SSL Proxy with Redirect

Compared to the integrated web server, a separate proxy server can be easily kept up to date and can use the most restrictive settings feasible. This particular deployment also distributes the CPU load for SSL much better.

Network latency is a potential drawback as an additional processing step is inserted in the communication chain. Also, quite a lot of extra web servers have to be configured and, as with the first scenario, the certificates may be costly.

Single SSL Proxy with Redirect

This deployment has only one potential disadvantage: under heavy load the load balancer /SSL proxy may become a performance bottleneck. With modern CPUs or dedicated SSL hardware this would only become a problem with extremely high request traffic.

If no load balancer is necessary, this scenario is virtually the same as scenario 2 and is still the recommended deployment.

Impact on Performance

Modern processors should be able to handle SSL encryption/decryption without major problems. The HTTPS protocol includes an SSL handshake which will induce higher latency and network usage, but as long as an HTTP connection is not explicitly or implicitly terminated, an HTTPS session (which differs from an HTTP session) is created and no further communication is necessary while the connection is alive. In order to use this, make sure you do not have components in your hosting infrastructure that prevent HTTP/1.1 with connectionkeep-alive.

Configuration Example

Configuration of Proxy

To act as a load balancer and SSL decoder/encoder, your web server proxy has to be properly configured. Below we provide a configuration for the Apache HTTP Server, which serves as an example: other proxies might work just as well, or even better.

To use Apache HTTP Server, install the additional module mod_ssl and deploy the SSL certificate. Please refer to the web server documentation on how to do this (for instance, for Apache, https://httpd.apache.org/docs/current/ssl/ssl_faq.html). You can leave most default settings as they are.

In httpd.conf , configure the following modules:

LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_balancer_module
modules/mod_proxy_balancer.so
LoadModule proxy_http_module modules/mod_proxy_http.so

The mod_ssl extension comes with the configuration file ssl.conf . In that file, within element <VirtualHost _default_:443> , insert the load balancing declarations. The following example assumes that you want two dedicated clusters of two PTV xServer hosts. You still have to adapt and replicate these entries to match your hosting setup.

<Proxybalancer://xServerCluster>
  BalancerMember
  http://xServer1IP:50000
  BalancerMemberhttp://xServer2IP:50000
</Proxy>
ProxyPass/xServer/
balancer://xServerCluster/xServer/
ProxyPassReverse/xServer/
balancer://xServerCluster/xServer/

To use nginx HTTP and reverse proxy server deploy the SSL certificate. Please refer to the web server documentation how to do this (for instance http://nginx.org/en/docs/http/configuring_https_servers.html). You can leave most default settings as they are.

In nginx.conf, add the following lines to the server element:

location /xServer/ { rewrite ^/xServer(/.*)$ $1 break; proxy_pass http://localhost:50000; }