Section – Application

GUI

Description

Session handling

Airlock Gateway supports four different session handling modes. To choose the best option, see article Choosing/switching to the session handling mode.

Minimum session idle timeout (seconds)

Defines the minimum session idle time of Airlock Gateway for this mapping. The value will be ignored if minimum session idle timeout is smaller or equal to the global session idle timeout setting.

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 session handling mode is recommended.

Use available session

Sessions are optional:

  • For requests without sessions, no sessions are created.
  • For requests with a session, the session is reused and 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 and 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 the Use available session mode instead. It has the same resource requirements while also preserving existing sessions.

 
Notice

Data acquisition and retraining of the Anomaly Shield application should always be performed after configuration changes that affect traffic, i.e., after changes such as a modification of the session handling mode.

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.