Optimizing Nginx HTTP/2 TLS : Basic Principles

We hope that most of the readers are using latest version of deb GNU/Linux (like Ubuntu 16.04 LTS) or latest CentOS which fully supports HTTP/2. In case you are using Ubuntu 14.04 or older Ubuntu, please read our old guide to upgrade your server to make compatible with HTTP/2. This Article on Optimizing Nginx HTTP/2 TLS is Basic Principles Will Also Help the Relatively New Users Who May Not Understand Various Phrases on Other Websites.

Previously Published Articles Related To Understanding of Basic Principles on Optimizing Nginx HTTP/2 TLS

We know that it is boring to see a list of hyperlinks. None loves to see a site-links like chart. But for easy, somewhat detailed instruction, information and cross checking, you probably at least read the sentences/phrases of the hyperlinks and click if unknown.

1. HTTP/2 (Article)
2. TLS (Article)
3. TCP (Article)
4. OSI Models (Article)
5. HTTPS Everywhere list (HTTP/2 compatible guide)
6. EV SSL Certificate (Article)
7. OCSP Stapling (HTTP/2 compatible guide)
8. OCSP Stapling Error Fix (HTTP/2 compatible guide)
9. Public Key Pinning (HTTP/2 compatible guide)
10. Content Security Policy (HTTP/2 compatible guide)
11. Installing Let’s Encrypt Free SSL Certificate (HTTP/2 compatible guide)
12. Nginx Configuration For TLS (non-HTTP/2  compatible guide)
13. Nginx Configuration For HSTS (non-HTTP/2  compatible guide)
14. Installing Nginx WordPress Percona MySQL on Ubuntu 16.04 LTS (HTTP/2  compatible guide)

The support for HTTP/2 was released with Nginx 1.9.5 except Server Push. It is not easy to answer whether HTTPS is slower than HTTP.

Optimizing Nginx HTTP/2 TLS : Goals

Latency is more big issue particularly on Cloud Servers than CPU load. So commonly the tips are about decreasing latency as well as avoiding call to remote server to check TLS certificate. Modern software based TLS implementation with ordinary server CPUs are enough to handle high HTTPS traffic load. Not perfectly setup HTTPS, as well as HTTP/2 TLS can really fry a dedicated server. Such bad, slow old settings are common to face as user when backend are of various social networks and payment gateways. What exactly we suggest is to use a GNU/Linux with the latest kernel, use the latest openssl, use the latest web server software, which is Nginx community edition in our case.

Optimizing Nginx HTTP/2 TLS : Phrases and Keywords

Get listed on HTTPS Everywhere – Deploy HSTS and get listed on HTTPS Everywhere list. As your domain will be listed on common browser’s source, chance of failure from client browser possibly will be lesser.

Try to Use Let’s Encrypt or Well Known CA – At this moment, Let’s Encrypt is more than enough for even small commercial websites over DV SSL certificate. Being F/OSS project, security, backdoors are regularly checked. If you are using GeoTrust’s DV SSL with longer expiration before Let’s Encrypt actually became usable, you can definitely trust. We want to point that – for paid option, EV SSL/TLS certificate is better.

RSA, Diffie-Hellman and Forward Secrecy – We already have written about Diffie-Hellman key. Diffie-Hellman key exchange and ephemeral sessions keys enables the perfect forward secrecy (PFS).

Switch to Application Layer Protocol Negotiation (ALPN) – Next Protocol Negotiation (NPN) is a TLS extension, which was developed as part of the SPDY. ALPN is a revised and IETF approved version of the NPN extension. ALPN is a successor to NPN.

Server Name Indication (SNI) – If you need to provide faster TLS+SNI workflow to all browsers and devices, then you need a dedicated IP address for domain and reverse DNS against the IP. A TLS tunnel can be established between two TCP peers where the client only needs to know the IP address of the other peer to make the connection and perform the TLS handshake. What will happen if the server hosts multiple domains with their own TLS certificate with the same IP address? It frankly does not work. Is not it obvious? Server Name Indication (SNI) extension in TLS protocol address this problem. This is what allows the client to indicate the hostname the client is attempting to connect as a part of TLS handshake.

TLS Session Resumption – TLS Session Resumption reduces the extra latency and computational costs of the full TLS handshake. It has two phased components – Session Identifiers (RFC 5246) and Session Ticket (RFC 5077).

Chain of Trust and Certificate Authorities – All browsers allow to click and inspect the chain of trust of connection, which actually based on the Site/Domain certificate, Intermediate certificate and Root CA certificate. You can click the lock icon of this webpage to understand. thecustomizewindows.com‘s certificate is signed by GeoTrust DV SSL Primary Intermediate Server. GeoTrust DV SSL Primary Intermediate Server certificate is signed by the GeoTrust Certification Authority. GeoTrust Certification Authority is a recognized root certificate authority to all browsers. Certificate Transparency project addresses flaws by providing a public log for monitoring and auditing of issuance of all new certificates.

Certificate Revocation – The issuer of a certificate will need to invalidate the certificate due to various possible reasons. It can be serious like the private key of the certificate has been compromised or just there is a superseding certificate or change in affiliation.

Certificate Revocation List (CRL) – RFC 5280 specifies a simple mechanism to check the status of every certificate.

OCSP Stapling – For various reasons, CRL and OCSP are suboptimal. We discussed about OCSP Stapling in details in separate guide.

TLS Record Protocol – TLS Record protocol identifies different handshake, alert or data via the “Content Type” field, securing and verifying the integrity of each.

Logical Steps to Optimize Nginx Configuration For HTTP/2 TLS

It is obvious, if we optimize all the points of above, or rather check to validate points of any standard test like SSL Lab, we can make our server’s HTTP/2 TLS connection faster without compromise in security. Deploying our web application over TLS will require some additional work, first within the application to migrate each resources to HTTPS to avoid mixed content and on the configuration of the infrastructure. Highest possible tuned TLS web application or webpage will add one extra roundtrip for negotiating the TLS connection. We need to configure session resumption, and enable forward secrecy to enable TLS False Start.

• First, we need to optimize the webpage or web application using general rules of Page Speed optimization. If a webpage is HTML and has very small CSS with only text, it will be always faster to load.
• Second, our server, DNS should have no bottleneck on networking or hardware resource.
• Third, our CDN should have no bottleneck exactly like our server.

Being either ready to use resource or configurable via Nginx config file, most of the above are quite easy to configure.

Problems : Head-of-line blocking, TLS records, and latency

TLS runs over TCP. TCP promises delivery of all the transferred packets. TCP suffers from head-of-line (HOL) blocking. In HOL one lost packet may hold all other received packets in the buffer until it is successfully retransmitted. Else the packets would be delivered out of order. This is a tradeoff for any in-order transport. For TLS there is an extra layer of buffering due to the integrity checks. If the server sends data in 16KB record chunks, then client must also read data 16KB at a time.

Sadly, most web servers do not provide any easy way to configure TLS record size and instead use the default maximum of 16 KB. That is a big chapter.