Administrator's Guide > Installation and Configuration > Using PTV xServer with HTTPS

Using PTV xServer with HTTPS

Introduction

The HTTPS protocol comprises 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 setup with a load balancer, there are several deployment scenarios possible (see also the figure below):

Different deployment scenarios to handle SSL encryption/decryption with HTTPS.

(1) Use the web server bundled with PTV xServer
(2) Setup multiple SSL Proxy and redirect
(3) Setup the load balancer proxy

The easiest deployment scenario (1) is to use the Tomcat web server that comes bundled with each PTV xServer. 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:

Security
Cost of Required Certificates
Effort for Deployment and Maintenance
Network Traffic and Latencies
Distribution of CPU Load

We assess the scenarios as follows:

Criterion	Scenario 1: PTV xServer	Scenario 2: Proxies	Scenario 3:Load balancer
Security	-	+	+
Certificates Cost	-	-	+
Maintenance Efforts	+	-	o
Network Latency	o	-	+
Load Distribution	o	+	-

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.

We would only recommend this scenario if the incoming requests are so many and so large that the SSL protocol cannot be handled by a single proxy server.

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.

We recommend this deployment.

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 how to do this (for instance, for Apache, http://httpd.apache.org/docs/2.2/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 assume that you want two dedicated clusters of two PTV xRoute Server and two PTV xMap Server hosts. You still have to adapt and replicate these entries to match your hosting setup.

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:

Configuration of PTV xServer

With the recommended deployment, PTV xServer receive ordinary HTTP requests and hence can use default HTTP settings.

A load balanced PTV xMap ImageServer can only benefit from the tile cache if you either mount a shared network folder for the cache, or set the load balancer to "sticky" for all PTV xMap Server requests. The ImageServer also requires a response URL that is externally visible. Since you currently can only provide one response URL, you cannot easily mix HTTP and HTTPS requests for ImageServer.