Introduction to SNI
IPv4 addresses are scarce. Therefore, virtual hosting is introduced to HTTP servers to allow multiple domain names to use the same IP address. The servers forward requests to different domain names (virtual hosts) based on different host fields in the requests.
If the IP address of the HTTPS server is shared by multiple domain names, the server does not know the specific host field that a client requests before a handshake is established. As a result, the HTTP server cannot forward requests to the specific domain name. To complete the handshake, the server must obtain the certificate for the domain name.
Server name indication (SNI) is designed to resolve this issue. SNI requires the client to carry the host field of the domain name to be accessed before a handshake is established. The server can then use the certificate of the correct domain name to establish a handshake and TSL connection with the client.
SNI was first introduced in 2004 and is now supported by all mainstream browsers, servers, and testing tools.
Reason why the clients must support SNI when you use Anti-DDoS Pro or Anti-DDoS Premium and WAF
An Anti-DDoS Pro, Anti-DDoS Premium, or Web Application Firewall (WAF) instance acts as a proxy and interacts with the real server (RS) to process HTTPS services. You must upload the certificates and private keys when you configure HTTPS protection. The number of IP addresses of the Anti-DDoS Pro or Anti-DDoS Premium instances and that of WAF instances are limited, it is impossible to assign a physical server to a domain name. Therefore, the Anti-DDoS Pro, Anti-DDoS Premium, and WAF instances must contain servers that are shared by multiple domain names. In this case, the client must support SNI to interact with the Anti-DDoS Pro, Anti-DDoS Premium, or WAF instance.
Solution
Servers
Configure your server to support SNI.
Clients
- We recommend that you use the latest version of Google Chrome or Mozilla Firefox.
- Do not configure Layer 7 website protection in Anti-DDoS Pro or Anti-DDoS Premium.
Instead, configure Layer 4 port forwarding.
Note Layer 4 port forwarding configuration cannot mitigate HTTP flood attacks.
- Supported desktop browsers:
- Google Chrome 5 and later
- Google Chrome 6 and later
- Mozilla Firefox 2 and later
- Internet Explorer 7 and later in Windows Vista, and Windows Server 2008 and later
- Konqueror 4.7 and later
- Opera 8 and later
- Safari 3.0 and later in Windows Vista, Windows Server 2008 and later, and Mac OS X 10.5.6 and later
- Supported mobile browsers:
- Android 3.0 Honeycomb and later
- iOS 4 and later
- Windows Phone 7 and later
- Supported servers:
- Apache 2.2.12 and later
- Apache Traffic Server 3.2.0 and later
- Cherokee
- HAProxy 1.5 and later
- IIS 8.0 and later
- Lighttpd 1.4.24 and later
- LiteSpeed 4.1 and later
- NGINX 0.5.32 and later
- Supported command line tools:
- cURL 7.18.1 and later
- GNU Wget 1.14 and later
- Supported libraries:
- GnuTLS
- JSSE (Oracle Java) 7 and later, which are only for clients
- libcurl 7.18.1 and later
- NSS 3.1.1 and later
- OpenSSL 0.9.8j and later
- OpenSSL 0.9.8f and later, which are configured with flags
- Qt 4.8 and later