How to create a custom application for SSL traffic using the SNI field

This article discusses how PAN-OS can leverage the SNI (Server Name Indication) field to create a custom application.

What is SNI (Server Name Indication)?

SNI is an extension to the SSL/TLS protocol that indicates what hostname the client is attempting to connect to.
SNI inserts the requested hostname (website address) within the TLS handshake (the browser sends it as part of ‘Client Hello’), enabling the server to determine the most appropriate SSL certificate to present to the browser.

When to use SNI to create custom applications

In cases where the SNI field is consistent, it can be reliably used to identify the application.

A custom application can be defined and used to control the SSL traffic without the need for SSL decryption.

Example of creating a custom application

The following example shows how to create a custom application for YouTube where the SNI field is seen as www.youtube.com (as an example only).

Analyze the traffic for consistency of the SNI field in the Client Hello:

Navigate to Objects > Application > Add.

1. Define the general properties of the application:

2. Define the port and protocol as TCP and 443 respectively, since SSL uses protocol TCP and port 443 for communication.

Define the other Timeout settings as required:

3. The last and the most important part of application definition is to select the context as 'ssl-req-client-hello' and
    define the required pattern as seen in the client hello SNI field:

Note:

• We recommend analyzing the traffic thoroughly before creating an application signature to ensure reliability of the custom application.
• It is possible for the same web service to use different SNIs on different occasions, hence all possibilities must take that into consideration.
• The SNI field uses the hostname the client is attempting to connect to the server, hence any change in the request from the client may cease to match custom application.
• SSL Client Hello should be right after the 3-way handshake as per normal protocol packet flow. Sometimes there is custom SSL communication triggered from agents(not web browsers) which send some data prior to Client Hello. In this case the SSL decoder will not even come into play, app-id will be potentially identified as unknown-tcp. Captures needs to taken and pattern sent before the Client Hello needs to be used in pre-app-req-data context.