中文
Every month, we take a moment to share the expertise of our team, and answer a number of great questions we’ve received from both our customers and open source users. These questions range from how to use our products in a variety of use cases to how to effectively integrate third‑party tools and platforms with NGINX.
These answers come from our experts including technical architects, systems engineers, and our award‑winning customer support specialists.
Does NGINX Plus work with Diffie‑Hellman?
Yes. For those who don’t know: Diffie‑Hellman is a protocol used to create a secret key shared by two parties (this operation is commonly referred to as the SSL/TLS “handshake”). The two parties then use the key to encrypt subsequent communication between them.
A more precise answer is that NGINX Open Source and NGINX Plus work with Diffie‑Hellman in the sense that they use the OpenSSL software installed on the local host when handling SSL/TLS‑encrypted traffic, and many OpenSSL cipher suites incorporate Diffie‑Hellman as the protocol for public‑key exchange (indicated by DHE, ECDH, ECDHE, or EDH as the first element of the cipher suite’s name).
The Diffie‑Hellman protocol is mandatory in TLS 1.3, which is supported in NGINX Open Source 1.13.0 and later, and NGINX Plus R17 and later. To control which cipher suites NGINX and NGINX Plus accept from clients, use the ssl_ciphers directive (HTTP, Stream).
Does NGINX Plus support DTLS streaming?
Yes, NGINX and NGINX Plus can stream and proxy DTLS traffic to a backend; however, they cannot terminate it. (As background, DTLS is Datagram Transport Layer Security and provides the same protection for datagram‑based traffic like UDP that SSL/TLS does for HTTP and TCP.) To handle DTLS traffic, configure the udp parameter to the listen directive in the stream{} context. Note that you cannot also configure the ssl parameter in this case. For more on SSL/TLS, see the NGINX Plus Admin Guide.
Is it possible to cache content using a timestamp?
The first factor to consider is that NGINX and NGINX Plus respect the Cache-Control:max-age and Expires headers set by the origin server. So if you control the origin server, setting those is headers is the recommended way to control how long content remains in the cache.
If you don’t control the origin server (or want to override the headers), there are a few ways to set how long NGINX and NGINX Plus keep content in the cache. By default, they discard cached content that has not been accessed for 10 minutes, whether or not the origin server has set an expiration time in a header. To change the time period, include the invalid parameter to the proxy_cache_path directive. The setting applies to all cached data.
With the proxy_cache_valid directive, you can set caching time for responses that have particular status codes (200, 301, 404, and so on). You can set this timeout on a per‑server or per‑location basis as well as globally.
NGINX Plus users can also remove specific cached content on demand, by enabling cache purging.
There are literally dozens of tunable cache parameters, some of which might affect how long content remains in the cache. Check out the detailed guide to caching on our blog, and our ebook, High‑Performance Caching with NGINX and NGINX Plus. NGINX Plus customers with specific questions can consult our support team.
I’d like to add the NGINX ModSecurity WAF to my NGINX Plus subscription. Do I have to change license keys?
Yes. You need to install an additional license key for the NGINX ModSecurity WAF. For instructions, see the NGINX Plus Admin Guide, which also explains how to configure a simple rule and set up logging.
To use the NGINX ModSecurity WAF with NGINX Open Source (no license key required), follow the instructions on our blog. For more, download our eBook for both NGINX and NGINX Plus users, ModSecurity 3.0 and NGINX: Quick Start Guide.
Ask Us!
Got a question for our Ask NGINX series? Leave a comment below or get in touch with our team, and we’ll be happy to help!
