Imperva has modified the default behavior for new cloud WAF sites, now enforcing Server Name Indication (SNI)-only traffic by default. This shift is aimed at optimizing the utilization of TLS-related features, both those currently in place and those slated for the future roadmap.
This blog post will show why SNI-only mode is not just beneficial, but crucial, for harnessing the full potential of these features, along with sharing key insights from our comprehensive research on SNI traffic.
Understanding the Role of SNI
SNI is an extension of the TLS protocol within HTTPS. It empowers the client to specify the desired hostname during the TLS handshake, enabling servers to differentiate between multiple domains sharing the same IP address. SNI became an important foundation for modern web security, especially in the context of hosting services, load balancers, and CDN architectures.
When the server gets the hostname from the client in the SNI extension, it can customize the TLS handshake to the needs of this hostname. For example, it can provide the right certificate, negotiate the cipher suite according to the cipher selection template, and use mTLS if configured to do so.
SNI-Only Mode in the Context of Imperva Cloud WAF
When using Imperva Cloud WAF to safeguard your website, the platform assumes the role of the server for end-user interactions, culminating in the termination of HTTPS/TLS connections. Each website within Cloud WAF is configured as a discrete “web site” associated with a unique CNAME. Notably, multiple site CNAMEs resolve to a common IP address, forming what we term a “site group.” It’s important to understand the impact of not configuring a site in SNI-only mode. For certain HTTP clients, connecting to its IP address via TLS will be treated uniformly:
- A single default site group certificate will be presented. This certificate contains the subject alternative names (SANs) from all sites in the site group. Renewal of such a large certificate could be harder to perform.
- A default cipher and TLS version template must be used. There is no way to customize the cipher selections and TLS versions used per site.
When a cloud WAF site is not configured to be in SNI-only mode, some TLS features may not work, or will work in an inconsistent way (e.g., their behavior on SNI connection will be different than the behavior in non-SNI connection). This was our motivation for changing the default policy for the site to support SNI-only traffic.
The Imperative of SNI-Only Mode
Enabling “SNI only” mode is crucial for the optimal functioning of several TLS-related features, including:
- Customer site certificate: A customer can upload their own certificate to a cloud WAF site, if they choose to. This certificate will be presented in the HTTP incoming connections with SNI support, but will not be presented in connections without SNI support. The latter will use the default Imperva-generated site group level certificate because at the TLS handshake, the cloud WAF proxy does not know which domain is targeted. This behavior is not ideal for customers.
- Cipher selection template: Customers who need to change the cipher and TLS version selection template of a site can do this today by approaching Imperva Customer Support. This is not a self-managed change and will require some back-end configuration. Some customers miss the fact that such configuration changes affect only connections which support SNI. HTTP clients connecting without SNI support will negotiate the ciphersuite using the default Imperva cipher and TLS version template; not the template configured for the site. We are about to release a new feature that will allow customers to self configure the desired cipher and TLS version template using the API and UI. This way, customers will no longer need to ask support for help. To prevent confusion and use this feature, the cloud WAF site must be configured to SNI-only mode.
- 3. mTLS enforcement: Mutual Transport Layer Security (mTLS) is configured at the site level. When configured in a mandatory mode (client certificate is mandatory) the cloud WAF proxy will not accept non-SNI traffic to this site because by the time it realizes which site the connection is headed to—it understands this only after decrypting the TLS layer and getting to the host header of the HTTP protocol—the TLS handshake is over without the mTLS part. This is another example of inconsistent behavior. When the site is configured with SNI-only mode, the feature works consistently.
Configuring SNI-only Mode
By now, we hope you understand the benefits of configuring cloud WAF sites to run in SNI-only mode. As we said at the beginning, this has become the default mode for newly created sites. If you want to change this mode for existing cloud WAF sites, you can do this via the UI by going to the delivery screen under the “CDN” tab in the console navigation bar. Make sure the checkbox labeled “Support Non-SNI Clients” is disabled (see visual below)
Before making this change, you may wonder if moving to SNI-only mode will block some of your end users. For this reason we’ve done extensive research. Below are the highlights.
- Our extensive research reveals that only 1.2% of active customer sites experience more than 1% non-SNI requests.
- Delving further into this fraction, a striking revelation emerges: 90% of non-SNI traffic comes from bots, of which, half of those bots are imposters that try to hide behind legitimate user agents, and half are legacy python bots. The remaining 10% (0.12% of overall traffic) is attributed to legacy browsers.
- Consequently, blocking non-SNI traffic yields minimal repercussions for legitimate end-users, while concurrently mitigating a substantial portion of bot activities.
Charting the Future Roadmap
At Imperva, our commitment extends beyond the present, with ongoing investments geared toward enhancing TLS and cryptography supportability. These new capabilities rely on the fact the site is configured to support SNI only traffic. Upcoming features in our roadmap include:
- Imperva Generated Site Certificates: A feature that allows customers issuing dedicated certificates for configured domains in a cloud WAF site. This will allow for reduced exposure of our customers’ domains and better alignment with security best practices.
- Self-Service Cipher Selection: Recognizing the importance of configuring TLS versions and ciphers, we are poised to introduce a user-friendly UI, Terraform, and API to facilitate this process.
Conclusion
Embracing SNI-only mode within Imperva Cloud WAF is not merely an operational choice; it’s a strategic imperative for unlocking the full spectrum of TLS-related features. The negligible impact on legitimate users, coupled with our commitment to an evolving roadmap for enhanced supportability, underscores our dedication to empowering your digital future securely. In an era where web security is not an option, SNI-only mode stands as a cornerstone in fortifying your online assets.
Contact a security expert today to learn more about how you can protect yourself with Imperva Cloud WAF today!
Try Imperva for Free
Protect your business for 30 days on Imperva.
