Section – Application

Session handling

Airlock Gateway supports four different modes of session handling.

 
Info

To choose the best option, see article Choose/switching to best session handling mode.

The modes are sorted descending in terms of functional scope and supported security features:

Mode

Description

Enforce session

Requests are aggregated into sessions.

  • For requests without a session, a new session is created.
  • For requests with a session, the session is reused.
  • For requests with a session, the idle time is reset.

This is the recommended mode.

Use available session

Sessions are optional.

  • For requests without sessions, no sessions are created.
  • For requests with a session, the session is reused.
  • For requests with a session, the idle time is reset.

Use available session (no refresh)

Sessions are optional.

  • For requests without sessions, no sessions are created.
  • For requests with a session, the session is reused.
  • For requests with a session, the idle time not reset.

Sessionless

Session handling is disabled.

  • No sessions are created and existing sessions are ignored.

This mode may improve resource usage for the delivery of anonymous stateless content, such as image directories or static web repositories on the cost of traffic traceability and other disadvantages.
We strongly recommend using e.g. the Use available session mode instead which also comes without additional resource requirements but can at least preserve existing sessions.

 
Notice

Data acquisition and retraining of the Anomaly Shield application should always be carried out if a configurational change of the gateway influences the traffic. I.e., this is required if the session handling mode is changed.

Send load balancing cookie

If enabled, load-balancing information is sent to the client in a load-balancing cookie. Uncheck this option if no load balancing is needed and no cookie should be generated for this purpose. See also load balancing.

Compress response traffic

Specifies whether Airlock Gateway should compress the output on the fly for the client browser (if supported and requested by the browser).

The compression is limited to content that is known to be compressible, e.g. HTML pages. See article HTTP compression.

To mitigate the BREACH attack, the decision of whether to compress a response is based on the HTTP referer header. The following HTTP responses will not be compressed:

  • First page accessed by the client (landing page)
  • Pages called from bookmarks or typed-in URLs
  • Refreshed pages
  • Pages requested by special HTTP clients not sending a referer header
  • Resources like images, JavaScript, CSS are sourced from foreign domains.

Enable Control API

Specifies whether this service is allowed to use Control API via the control cookie mechanism. Normally, only the authentication application should be allowed to use the back-end control API of Airlock Gateway.

Send environment cookies

Specifies whether this service should receive the Airlock Gateway environment cookies that contain useful information about the connection to the client. Please refer to the environment cookie page for a detailed list of the Airlock Gateway environment cookies.

Encrypted cookies

Select Use regular expression and define a regular expression for cookies that should be cryptographically encrypted before being sent to the client. All cookies that have names that match the regular expression are encrypted and digitally signed with a secret key derived from a passphrase when sent to the client. They are decrypted and verified when sent to the back-end service. Because the pass-phrase-based key is used, such cookies are valid over several sessions and can also be persistent on the client's machine. Such cookies protect the application from manipulated cookie contents and hide the content from the user. 

Passthrough cookies

Select Use regular expression and define a regular expression for cookies that should be passed in plain format to the client. Passthrough cookies are not recommended because they are often a carrier for cookie poisoning-based web application attacks that can result in buffer overflows etc.