Web Protection - SSL/TLS
- Last UpdatedOct 13, 2024
- 8 minute read
Web Protection - SSL/TLS
This topic describes how Imperva handles secure communication.
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 you to prove that you are the owner of the domain you are adding to Imperva using one of the 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: Imperva will provide you a TXT record with a unique DNS entry to add to your domain DNS zone.
- CNAME validation: When you add the DNS record, select CNAME for the Record type. This can be done per site or for your entire account. For more details, seeAutomatic Domain Validation for Imperva-Generated Certificates.
- Meta tag validation: Imperva will automatically validate your domain by injecting an HTML meta tag in the following scenarios:
- Onboarding a new site using the 1-step option. For more details, see Onboarding a Site – Web Protection and CDN, Configure SSL for a new site.
- During the certificate renewal process. For more details, see Revalidate Your Imperva Certificate
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.
GlobalSign Atlas Certificate Authority (CA)
Imperva-generated certificates are issued by GlobalSign.
-
Certificates expire 6 months after creation.
-
SANs expire 12 months after validation.
Imperva begins the renewal process 90 days before a certificate expires, which includes email notifications. The exchange between the old certificate and the new one happens 3 days before the expiration date of the certificate. Any SAN that is not verified before the exchange is dropped from the new certificate that is issued.
SNI values
When an Imperva proxy connects to the origin server, it sends the same SNI value that appears in the Host header initially sent by the client. This value does not change when CNAME is used in a data center configuration, as detailed in Load Balancing Settings. If you rewrite the Host header, the SNI value changes automatically. For details on how to rewrite a Host header, see Create Rules, Rewrite Request Header.
Custom 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:
-
The website's custom certificate.
-
The Imperva-generated certificate.
-
A custom certificate from another website in any 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.
Does Imperva add latency to SSL termination?
We employ the following advanced techniques, designed to speed up the process and minimize latency:
Session resumption |
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 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. |
OCSP stapling | 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 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 | HTTP/2 enables a client to send multiple simultaneous requests over a single SSL connection. The result is that the HTTP/2 enabled clients do not need to open as many connections as HTTP/1.x clients. |
Optimized hardware | Imperva servers are optimized to run encryption related workloads by offloading some of the encryption workload to hardware. |
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, and 1.0 are supported for connectivity between clients (visitors) and the Imperva service. TLS 1.2 is the minimum supported version, by default.
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.
- 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:
- Enable the Support All TLS Versions option for the account. For details, see Account Settings.
- 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 Customize Website TLS Configuration.
Using the API:
Use the following endpoints in the Cloud Application Security v1/v3 API Definition.
- Use the Modify Account Configuration operation in the Account Management API.
- Use the Set support for all TLS versions operation in Site Management API.
Supported cipher suites
For the full list of cipher suites supported by Imperva, see Supported Cipher Suites.