Architecture Overview

This chapter provides a high-level, feature-oriented view of nevisProxy and provides information about the context in which nevisProxy is used.

nevisProxy design goals

The reverse proxy nevisProxy was designed in line with the following design goals:

• Thread safeness for optimized resource use
• Enhanced security features (cookie caching, renegotiation of the client's session association)
• Failsafe connectors to content providers
• Architecture that separates the functional components from the carrier server's environment and provides an environment that enables efficiently writing customer-specific plugins.
• Support for proxy-unaware content providers
• Configuration engine that allows consistent component setups
• State-of-the-art configuration
• Input validation and web application firewall functionality
• OS platform abstraction

Feature overview

As a(n) (authenticating) secure reverse proxy, nevisProxy has the following main tasks:

• Secure client identification: Associating a client's communication channel with previous requests, if required (e.g. for addressing an authenticated session).
• Authentication and authorization: Enforcing authentication and access restrictions on protected resources.
• Reverse proxying: Forwarding HTTP(S) requests to content providers performing protocol and content translation if possible and required (e.g. for non-proxy-aware legacy applications). In addition, nevisProxy may filter out cookie information from the content provider's reply and reinsert them when forwarding requests. Content caching may also be used to reduce the application load for static content.
• Web Application Firewall: The reverse proxy protects web applications from hacker attacks using state-of-the-art WAF techniques.
• Failsafeness: The reverse proxy supports failover in the backend, i.e. the ability to access multiple application instances providing the same content.

In the sections that follow you will find an overview of the respective core features. See the chapter Configuration for a more detailed description.

Security features

Client identification

Reverse proxy security is based on the identification. In this context, the term identification is used for a mechanism to decide whether two HTTP requests are made by one and the same client browser. The main identification mechanism is the following:

• Cookies: A secure cookie is sent to the client. The client has to send back the cookie, and nevisProxy uses it to find the session associated with it. The cookie itself does not contain any information about session internals.

The Cookie client identification mechanism supports renegotiations at any given time. This permits reducing the lifetime of a client identification, which is an important security aspect.

• Customer specific rules: Client may be tracked using an arbitrary attributes using a virtual session filter.
• Attribute locking: Customer rules may be configured to track client attributes during a session and to enforce the preconfigured actions.

Authentication

Based on this client identification, user authentication can be enforced. In other words, the user has to provide information to prove that he is who he claims to be. This information is forwarded to the 'authentication service' for validation. Security role Furthermore, a security role concept allows access control for authenticated users, i.e. resource-oriented authorization.

Failover and load balancing

Content providers as well as the authentication service can be addressed in failover and/or load balancing mode.

PKCS#11

nevisProxy supports the PKCS#11 API for access to hardware security modules (HSM) for all components that use TLS.

Proxy features

The current version of nevisProxy supports the use of HTTP and HTTPS web servers as content providers, which are implementing the Nevis HTTP gateway interface.

The connection to content-providing services can be adjusted to user needs by fine-tuning the following capabilities:

• TCP connection pooling
• TLS session caching
• Failover and/or load balancing mode
• Streaming, especially in cases where the content provider supports HTTP chunking
• Reverse proxy and authentication context propagation, including the propagation of a user identity in a secure (verifiable) way.

For content providers that are not proxy aware, the following features are also available:

• HTTP Header rewriting
• Automatic rewriting of response bodies of type text/html
• Manual rewriting rules for incoming / outgoing HTTP traffic.

Web application firewall features

HTTP interception

nevisProxy intercepts all HTTP traffic and allows full control over all aspects of the protocol. This includes checks that detect protocol violations, enforcing restrictions on the protocol interactions, such as allowing only a subset of methods and parameters, and enforcing size limits on the messages exchanged.

Input validation

On the application layer, fine-grained input validation (based on whitelisting or blacklisting) can be applied to ensure that only a restrictive set of parameters (e.g., only certain form fields with defined value ranges) may pass through nevisProxy. Predefined profiles allow detection of common attack patterns such as cross-site scripting (XSS) or SQL injection.

URL/Form signing

nevisProxy offers advanced protection against cross-site request forgery (CSRF) and injection attacks by supporting URL and form signatures. Links and forms appearing in HTML content can be rewritten on the fly.

Backend protection

Flexible output rewriting can be applied to prevent information leakage, such as credit card numbers or exception stacks. Backend-specific error pages can be overridden by generic ones to avoid information leakage.

Secure session handling

A secure random cookie or the TLS session is used to securely bind a session to a client. The session bindings are renegotiated periodically. Backend session cookies can be stored in the session and are prevented from reaching the client.

Logging

nevisProxy writes log data which may be used to auditing purposes or fraud detection.

HTTP support

nevisProxy can deal with all RFC-compatible2 HTTP traffic (and as such supports any RFC-compatible browser). Supported HTTP standards:

• Front end: HTTP/1.0, HTTP/1.1, HTTP/2, Websockets
• Back end: HTTP/1.0, HTTP/1.1, Websockets

nevisProxy does not support HTTP/0.9.

Nevis integration

Deployed as part of the Nevis architecture, the secure reverse proxy nevisProxy is one of three main actors. The other two are the authentication server nevisAuth and the application server or servers (content providers).