True, it does not destroy the entire purpose
if and when the STEK is securely and properly rotated. But to call this PFS stretches the truth in ways that boring crypto never does.
The number of real-world cases where PFS is reduced exactly to the non-PFS state by the existence of session tickets with fixed STEKs is not only non-zero, but rather I would venture a guess it is staggeringly large.
E.g. Configuring Session Tickets [1]
While Apache offers the SSLSessionTicketKeyFile directive to specify a key file that should contain 48 random bytes, it is recommended to not specify one at all. Apache will simply generate a random key on startup and use that to encrypt session tickets for as long as it is running.
The good thing about this is that the session ticket key will not touch persistent storage, the bad thing is that it will never be rotated. Generated once on startup it is only discarded when Apache restarts. For most of the servers out there that means they use the same key for months, if not years.
To provide forward secrecy we need to rotate the session ticket key about daily and current Apache versions provide no way of doing that. The only way to achieve that might be use a cron job to gracefully restart Apache daily to ensure a new key is generated. That does not sound like a real solution though and nothing ensures the old key is properly overridden.
...
Nginx, too, provides no way to automatically rotate keys. Reloading its configuration daily using a cron job might work but does not come close to a real solution either.
...
HAproxy does not allow configuring session ticket parameters. It implicitly supports this feature because OpenSSL enables it by default. HAproxy will thus always generate a session ticket key on startup and use it to encrypt tickets for the whole lifetime of the process.
[1] - https://timtaubert.de/blog/2014/11/the-sad-state-of-server-s...
Note that's from 2014 -- has it changed since then?
