Understanding how BIG-IP enforces TLS requirements on HTTP/2 Profile


For those new to HTTP/2 profile, RFC7540 section 9.2.1 specifies TLS requirements for HTTP/2 connections.

On BIG-IP, there's an option that is enabled by default which makes BIG-IP comply with above RFC requirements:

The above setting dictates whether BIG-IP should enforce TLS configuration requirements during client SSL profile configuration.

In this article, I will talk about such RFC requirements in the context of BIG-IP configuration..

BIG-IP requires Client SSL profile before adding HTTP/2 profile

BIG-IP does not allow us to add an HTTP/2 profile without adding a Client SSL profile first as HTTP/2 requires TLS:

TLS Renegotiation must be disabled on Client SSL profile

The other requirement is that we must explicitly disable Renegotiation on Client SSL profile:

In the above example, I first added a Client SSL profile (https-vip-client-ssl) to my virtual server (http_test) and then tried adding an HTTP/2 profile (custom_http2_profile) and it fails because TLS Renegotiation is enabled on my Client SSL profile.

After disabling TLS Renegotiation, I can now safely add my HTTP/2 profile to virtual server:

TLS Cipher Enforcement and TLS Compression

Do not use any of the cipher suites from Appendix A from RFC7540:

  • Roughly all ciphers that are not ephemeral and cipher mode CBC.
  • Ephemeral ciphers such as ECDHE are allowed.
  • You don't need to worry about making any changes here because BIG-IP will proactively either select the ciphers that are compatible with HTTP/2 from Cipher list (sent by client on Client Hello message) or an error (INSUFFICIENT_SECURITY) will be triggered.
  • However, it is worth pointing out that after a profile is applied to a virtual server, we do not allow removing compatible ciphers from Cipher List as seen below:

Regarding TLS compression, we do not support it anyway so nothing to worry about.

Final Remarks

I would personally leave Enforce TLS Requirements setting enabled to both comply with RFC and for security reasons. For more details, please check the TLS requirements section in RFC.

Published Jun 07, 2020
Version 1.0

Was this article helpful?

No CommentsBe the first to comment