Cloud Application and Network Security

Cloud Application and Network Security

Cloud Application and Network Security 1

 Contents

Contents
SSL/TLS Certificates. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Cloud Application and Network Security

 Cloud Application and Network Security

Web Protection - SSL/TLS

This topic describes how Imperva handles secure communication.

In this topic:

• SSL certificates
• The SSL process
• TLS version support
• Supported cipher suites
SSL certificates
To support secure websites (HTTPS), Imperva must host a valid SSL certificate for the website domain. Imperva
supports two types of certificates for this purpose:

Imperva-generated certificate

As part of the activation process, Imperva requires that a secure website add its domain to an existing Imperva
certificate. This certificate will be presented to any visitor trying to access your website, indicating that the connection
is secure.

The Imperva certificate is used by default for both SNI and non-SNI supporting clients. Server Name Indication (SNI) is
a TLS extension that enables a client to indicate the hostname it wants to connect to at the start of the handshake
process. Many older browsers do not support SNI. If you choose to provide us with your existing domain certificate in
addition to the Imperva certificate, your certificate is used for SNI-supporting clients, and the Imperva certificate
continues to be used for non-SNI supporting clients.

The process for adding your domain to an Imperva certificate is triggered automatically from the Add Site wizard
when you first onboard your website to Imperva, or using the Add site API. This process requires that you prove that
you are the owner of the domain you are adding to Imperva using one of three available methods:

• Email validation: A validation email will be sent to one of the email addresses associated with your domain. A
list of email addresses is displayed during the process. If the addresses are no longer in use or you wish to use a
different one, contact Support to request the change. The requested email address must be listed in your
domain’s Whois record.
• DNS validation: You will be provided with a unique DNS entry to add to your domain DNS zone.
• Meta tag validation: You will be provided with a unique HTML string to be added to one of the URLs on your
website.

If you did not complete SSL validation during the onboarding process and your site is already onboard with Imperva,
you can validate domain ownership using the email or DNS methods.

Once you have chosen a validation method and completed the validation steps, Imperva automatically adds your
domain to the Imperva certificate and provides DNS instructions. This is the final step in setting up your domain on
Imperva.

Note: If your site uses certificate pinning, it is not recommended to use an Imperva-generated certificate due to
occasional changes that are required on the Imperva side, such as certificate renewals, updates, and migrations. If
you choose to use certificate pinning, upload a custom certificate instead.

Cloud Application and Network Security 3

 Cloud Application and Network Security

Original domain certificate (optional)

You may choose to add your existing domain certificate to Imperva in addition to the Imperva-generated certificate.
This can be done by uploading the certificate and private keys to Imperva via the Cloud Security Console. For details,
see Upload a Custom Certificate for Your Website on Imperva.

It is important to note that these uploaded certificates are presented only to SNI-supporting clients. A list of SNI-
supporting clients can be found here: https://en.wikipedia.org/wiki/Server_Name_Indication.

Which certificate does Imperva use?

The Imperva proxy first checks to see if a custom certificate was uploaded to the specific site. If one is not found, the
proxy looks at other sites in your account.

If the proxy identifies a certificate uploaded to another site in your account that has a SAN corresponding to the site in
question, then that custom certificate is used.

For example, suppose a custom certificate was not uploaded for your site support.example.com, but a certificate for
the wildcard domain *.example.com has been uploaded for another site in your account. The custom certificate for
*.example.com is used.

If you do not want the certificate for *.example.com used for your site, you need to upload a separate custom
certificate for the specific site.

If no matching certificate is located in any site in your account, the Imperva-generated certificate is used.

For websites onboarded to Imperva after October 20, 2021, the certificate selection method has changed. To optimize
the selection mechanism, the Imperva proxy now selects a certificate in this order:

1. The website's custom certificate.

2. The Imperva-generated certificate.

3. A custom certificate from another website in your account with a SAN corresponding to the website in question.
The SSL process
HTTPS traffic arrives at Imperva, where Imperva terminates the SSL connection. It decrypts the traffic, analyzes it, and
filters out malicious visitors and requests. The next step for legitimate requests is for Imperva to return a response to
the visitor from the cache, or forward the request on to the origin server if necessary. Imperva encrypts the traffic at
this point before sending it on.

All communication between visitors <--> Imperva (Connection A) is handled by the certificates stored in Imperva.
Communication between Imperva <--> your site (Connection B) is handled by the original domain certificate located
on your web server.

Cloud Application and Network Security 4

 Cloud Application and Network Security

Does Imperva add latency to SSL termination?

We employ the following advanced techniques, designed to speed up the process and minimize latency:

A normal SSL handshake requires 2 round trips (4

packets). Session resumption enables the client and
the server to complete an SSL handshake for
connections after the first connection (2nd, 3rd, etc)
in one round trip, by reusing some of the work done
Session resumption when the first connection was established.

Imperva supports both session identifiers and

session tickets for session resumption. Session
tickets are used if supported by the client.
Otherwise, session identifiers are used.

When establishing SSL connections, clients need to

verify the certificate presented by the server. One of
the checks the client makes is to ensure the
certificate was not revoked by its CA. In order to do
that, the client needs to contact the CA, which slows
OCSP stapling
down the connection process. OCSP allows the
server to check the revocation status of the
certificate and send it to the client as part of the
connection, so the client doesn't have to contact the
CA itself.
HTTP/2 enables a client to send multiple
simultaneous requests over a single SSL connection.
HTTP/2 The result is that the HTTP/2 enabled clients do not
need to open as many connections as HTTP/1.x
clients.
Imperva servers are optimized to run encryption
Optimized hardware related workloads by offloading some of the
encryption workload to hardware.

Cloud Application and Network Security 5

 Cloud Application and Network Security

When traffic arrives at Imperva, can Imperva decrypt it and send me clear traffic?

No. To provide data security and meet PCI requirements, encryption is required during all legs of the journey.

Can our origin server send clear traffic to Imperva and have Imperva encrypt it before sending it back to
visitors?

No, for the same reason.

Do Imperva and your origin servers need to use the same TLS versions and cipher suites?

No. The connection between visitors <--> Imperva, and the connection between Imperva <--> your origin server are
two separate connections. Each segment can use a different TLS version and cipher suite.
TLS version support
TLS 1.3, 1.2, 1.1, 1.0, and SSLv3 are supported for connectivity between clients (visitors) and the Imperva service. TLS
1.2 is the minimum supported version, by default.

Note: As of July 1, 2022 Imperva will no longer support the SSLv3 security protocol and the RC4 cipher.

These older versions have been deprecated across the industry.

To avoid any issues, please prepare for the change accordingly.

For the list of supported ciphers, see Supported Cipher Suites.

PCI-DSS v3.2 compliance

PCI-DSS compliance requires disabling the use of TLS 1.0 as of July 1, 2018. To comply with this requirement, and due
to the known vulnerabilities in TLS 1.1, Imperva has defined TLS 1.2 as the default minimum supported version. This
also applies to the Imperva Cloud Security Console and the Imperva API.

Connectivity between a website’s origin server and the Imperva service is the responsibility of the Imperva customer.

Opting out

A client with an unsupported TLS version will not be able to establish a connection to Imperva. The client (a browser,
for example) may show the following SSL error message: ERR_SSL_VERSION_OR_CIPHER_MISMATCH, and will not be
able to access the site.

If you need to keep supporting TLS v1.0 and TLS v1.1, you can opt out and choose to enable support for all TLS
versions, on a per site basis. Opting out means that clients will be able to establish connections to your site using TLS
v1.0, v1.1, and v1.2. This is not recommended. To remain PCI compliant, do not enable this option.

Choosing to enable the option to support all TLS versions may require migration of your sites to the new Imperva
service network, which offers additional security options, customization, and visibility. As a result, you may be
required to update the following:

• Update of the A-record for your domain to point to the new IPs provided by Imperva.

Cloud Application and Network Security 6

 Cloud Application and Network Security

• Revalidation of your Imperva-generated certificate/SAN for your opted-out sites: When possible, SSL certificates
currently in use will be moved automatically to the new platform. For certificates that cannot be moved
automatically, you will be required to revalidate ownership of your domain in order to issue new SSL
certificates. This typically requires that you add the relevant authorization string in a DNS TXT record to be
viewed by the CA. You will receive instructions on how to complete the revalidation.

Note: If you want to set TLS 1.1 as the minimum supported version for your site, contact Support.

To opt out of TLS 1.2 enforcement, enable support for all TLS versions:

From the Imperva Cloud Security Console:

1. Enable the Support All TLS Versions option for the account. For details, see Account Settings.
2. Enable the Support All TLS Versions option for each site that you want to support versions of TLS earlier than
1.2. For details, see Web Protection - General Settings.

Using the API:

1. Use the Modify Account Configuration operation in the Account Management API.
2. Use the Set support for all TLS versions operation in Site Management API.

For details, see Cloud Application Security v1/v3 API Definition.

Supported cipher suites
For the full list of cipher suites supported by Imperva, see Supported Cipher Suites.

Read More

• Web Protection - General Settings

Last updated: 2022-10-30

Cloud Application and Network Security 7