Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
ON THIS PAGE
 

SSL Proxy HTTP/2 Inspection with ALPN (TLS 1.2 and TLS 1.3)

Overview

ALPN (Application-Layer Protocol Negotiation) is a TLS extension that lets client and server agree on which application protocol to use inside the TLS tunnel (for example, HTTP/1.1 or HTTP/2). When a client connects using HTTPS, the TLS handshake happens first. During that handshake, the client and server use ALPN to agree on which protocol to use:

  • http/2 or h2 → Negotiate HTTP/2 ("h2") when the client and server support it and it’s standards-compliant.
  • http/1.1 → Fall back to HTTP/1.1 when HTTP/2 isn’t possible or allowed.

The SSL Proxy supports HTTP/2 only when it’s negotiated correctly via ALPN and meets security rules. You can:

  • Allow or block HTTP/2 globally (for all traffic).
  • Allow or block HTTP/2 per security policy (example: only for certain sites, users, or applications).

The SSL Proxy removes HTTP/3 (h3) by default and forces clients to fall back to HTTP/2 (h2), or HTTP/1.1. This feature enables the negotiation to use only supported protocols ( (HTTP/2 or HTTP/1.1)

When HTTP/2 is negotiated, SSL proxy applies applies different enforcement rules depending onTLS-version-specific enforcement for TLS 1.2 and TLS 1.3. You can confirm the negotiated protocol and enforcement actions by using SSL Proxy status output, counters, and syslog messages.

Benefits of SSL Proxy support for HTTP/2 through ALPN

  • Prevents HTTP/2 sessions from being established with TLS 1.2 cipher suites and behaviors that are not permitted for HTTP/2.

  • Provides predictable protocol fallback by removing unsupported ALPN options (such as h3 and optionally h2) so connections can continue using h2 or http/1.1 when available.

  • Prevents noncompliant HTTP/2-over-TLS behavior for TLS 1.3 by terminating sessions that attempt prohibited post-handshake client authentication.

  • Ensures consistent protocol-aware handling for TLS 1.3 by propagating the server-selected ALPN value, including when the selection is sent in encrypted handshake messages.

ALPN and Protocol Selection

When ALPN is enabled, the SSL proxy looks at the client’s TLS ClientHello and checks which application protocols (like h2 for HTTP/2 or http/1.1) the client supports. It then decides what to pass to the server.

  • If HTTP/2 is turned off (globally or in a specific security policy), the proxy removes h2 from the list of protocols before connecting to the server.
    • Result: the server will negotiate http/1.1 (or no ALPN) instead of HTTP/2.
  • If the client offers h3, the proxy removes it by default so the connection can fall back to h2 or http/1.1, if those are also offered.

Handling of Post Handshake Message in TLS1.3

When using TLS 1.3, the server announces the selected ALPN protocol (for example, HTTP/1.1 or HTTP/2) in the EncryptedExtensions message. The SSL proxy reads this value and uses it to process the connection correctly.

If the server selects HTTP/2 (h2):

  • The proxy enforces HTTP/2-over-TLS requirements.
  • Some TLS 1.3 features are not allowed with HTTP/2. In particular, post-handshake client authentication (where the server sends a CertificateRequest after the handshake) is not supported.
  • If the server attempts post-handshake client authentication over HTTP/2, the proxy treats this as an error and closes the connection.

Handling of Prohibited Ciphers in TLS1.2

With TLS 1.2, HTTP/2 has strict requirements about which cipher suites are allowed and about renegotiation.

  • If the client offers h2 but only uses TLS 1.2 cipher suites that HTTP/2 forbids:
    • The proxy removes h2 from the ALPN list before sending the request upstream.
    • If http/1.1 is also offered, the connection continues as HTTP/1.1.
  • If the server selects h2 but the final cipher/parameters are not allowed for HTTP/2, The proxy drops the session instead of allowing an invalid HTTP/2 connection.
  • If either side tries TLS renegotiation after h2 is negotiated, The proxy rejects it with a fatal alert (renegotiation is not allowed for HTTP/2).

Session Renegotiation

For HTTP/2 sessions, TLS renegotiation is typically used by servers to request a client certificate for authentication. The SSL proxy does not support client certificate authentication. When the server requests a client certificate during renegotiation, the proxy sends an empty (zero-length) certificate list. This causes the renegotiation to fail, effectively disabling SSL renegotiation for HTTP/2 sessions through the proxy.

If either the client or the server tries to start renegotiation, the proxy rejects it and sends an alert indicating that renegotiation is not allowed.

Configuration Options

Disable HTTP/2 At Policy Level or Global Level

When HTTP/2 is disabled, the SSL proxy removes h2 (HTTP/2) from the client’s ALPN list before sending the connection to the server. This makes the connection fall back to HTTP/1.1 (or another allowed protocol) instead of using HTTP/2.

HTTP/2 is off by default. You must enable it if you want the device to allow HTTP/2 via ALPN.

  • Enable HTTP/2 globally:
  • Disable HTTP/2 globally:

This setting affects all SSL-proxy traffic unless overridden by a policy.

Disable HTTP/2 only for Specific Traffic (per Policy)

If you want HTTP/2 allowed in general, but blocked for certain flows (for example, certain zones, subnets, or applications), you can do this with a security policy:

In the matching policy, add an action that disables HTTP/2 for that traffic:

  • For sessions matching this policy: SSL proxy removes h2 from ALPN (no HTTP/2 for that traffic).

  • For all other traffic: The global HTTP/2 setting still applies (on or off as configured).

Downgrading HTTP/3 to HTTP/2 or HTTP/1 (Stripping H3 ALPN)

Junos firewalls don’t support HTTP/3. To accommodate this, the SSL proxy automatically removes the h3 (HTTP/3) entry from the ALPN list sent by the client.

When a client includes HTTP/3 in ALPN, the SSL proxy:

  • Strips h3 from the ALPN list
  • Forwards only the remaining protocols (for example, HTTP/2 or HTTP/1.1) to the server

Following table provides ALPN list shared to the server based on client-supported protocols and HTTP/2 setting on SSL proxy.

Table 1: ALPN Based on Client and HTTP/2 Config
Client Supported ALPN List HTTP/2 ALPN List Shared to Server By SSL Proxy
H1 OFF H1
H1 ON H1
H2 OFF None
H2 ON H2
H3 OFF None
H1, H2 OFF H1
H1, H2 ON H1, H2
H1, H3 OFF H1
H1, H3 ON H1
H2, H3 OFF None
H2, H3 ON H2
H1, H2, H3 OFF H1
H1, H2, H3 ON H1, H2

Verification Commands

show services ssl proxy status

Use show services ssl proxy status to confirm whether ALPN is enabled and whether SSL Proxy is removing h2 as shown below.

Example:

ALPN-Ext-support : Enabled indicates the use of ALPN TLS extension in its ClientHello / ServerHello messages. With this enabled, the connection can automatically pick HTTP/2 if both sides support it.

Strip-ALPN-h2 indicates removing h2 from the ALPN list so that HTTP/2 is not negotiated, even if both sides support it. With this disabled means, the h2 protocol remains in the ALPN list.

Above output sample indicates:

  • ALPN support is on.
  • The system is not blocking/stripping HTTP/2 from ALPN negotiation.

show services ssl termination counters all

Use show services ssl termination counters all to quantify how often SSL proxy removed h2 from ALPN.

Example:

The proxy: strip h2 alpn indicates the number of sessions downgraded from HTTP/2 due to the removal of the ALPN ‘h2’ identifier during the TLS handshake.

See Also