Revision history [back]

There are several possible reasons why you do not always see decryped HTTP/2 traffic:

Your capture started while the TLS session was already established. Since the TLS handshake is not captured, Wireshark will be unable to decrypt it.
Disabling cache ensures that the browser performs a new request, but it will not ensure that new requests go through a fresh TLS handshake due to connection reuse. Connections are typically kept alive for some more seconds, the exact timing will depend on the Keep-Alive header. To ensure that the connection is closed, you can for example use the "File" -> "Work Offline" option in Firefox.
The network might cause packet re-ordering, resulting in out-of-order TCP segment. The default configuration of Wireshark does not handle this well, this breaks TLS decryption. Be sure to enable the Reassemble out-of-order segments option at the TLS protocol preferences (added in Wireshark 3.0). This and the above issue are the most common reason reasons why decryption could fail assuming correctly configured keys.
If the key log file is not created, ensure that the environment variable or command line flag is correctly set. If you are not using the latest version of Firefox, do so. Official builds of Firefox 65 to 67 had this functionality disabled.

See also:

The Wireshark wiki on TLS explains which preferences to control.
The Wireshark User's Guide on TCP Reassembly explains why out-of-order TCP reassembly is needed.

If you would like to do a live demo of HTTPS decryption and HTTP/2, you could also start a browser with a new browsing profile. That way, your normal browsing session can continue while you visit a specific site in the new browsing profile. See slide 8 of https://lekensteyn.nl/files/wireshark-tls-debugging-sharkfest19us.pdf.

There are several possible reasons why you do not always see decryped HTTP/2 traffic:

Your capture started while the TLS session was already established. Since the TLS handshake is not captured, Wireshark will be unable to decrypt it.
Disabling cache ensures that the browser performs a new request, but it will not ensure that new requests go through a fresh TLS handshake due to connection reuse. Connections are typically kept alive for some more seconds, the exact timing will depend on the Keep-Alive header. To ensure that the connection is closed, you can for example use the "File" -> "Work Offline" option in Firefox.
The network might cause packet re-ordering, resulting in out-of-order TCP segment. The default configuration of Wireshark does not handle this well, this breaks TLS decryption. Be sure to enable the Reassemble out-of-order segments option at the ~~TLS~~ TCP protocol preferences (added in Wireshark 3.0). This and the above issue are the most common reason reasons why decryption could fail assuming correctly configured keys.
If the key log file is not created, ensure that the environment variable or command line flag is correctly set. If you are not using the latest version of Firefox, do so. Official builds of Firefox 65 to 67 had this functionality disabled.

Upgrade to the latest Wireshark version. Sometimes there are bugs or missing features that could also prevent TLS decryption from happening in some edge cases.