Tim Taubert, a Mozilla engineer, writes about TLS, cryptography implementation and formal verification.
Commenters cite his posts on TLS session resumption, forward secrecy, TLS 1.3 handshakes and version intolerance, and recommend them.
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…
For those wondering how to create your own custom Tor onion adress, look no further than: https://timtaubert.de/blog/2014/11/using-the-webcrypto-api-to-generate-onion-names-for-tor-hidden-services/
And for those who think Protonmail are the only service with a custom address, think again, because Facebook has one too: https://facebookcorewwwi.onion/
You can find a tonne more at this list:
https://github.com/chris-barry/darkweb-everywhere/tree/master/rules
And staying on topic, Mailpile has their own .onion
https://raw.githubusercontent.com/chris-barry/darkweb-everywhere/master/rules/onion-mailpile.xml
Fair enough. TLS 1.3 might introduce a zero-RTT handshake (with some security trade-offs), but that's obviously going to take quite some time to get rolled out.
Highly recommend this blog post [1] for more.
[1]: https://timtaubert.de/blog/2015/11/more-privacy-less-latency-improved-handshakes-in-tls-13/
> An increasing number of businesses are legitimately intercepting encrypted traffic on their networks. It’s pretty much a necessity today.
This is blatant FUD right in the intro, trying to push F5's known bad TLS MITM hardware: https://timtaubert.de/blog/2016/09/tls-version-intolerance/
Interestingly I was researching TLS forward secrecy. And the recommendation seems to be to disable tls tickets. https://timtaubert.de/blog/2014/11/the-sad-state-of-server-side-tls-session-resumption-implementations/
If you want to use a standalone app then you can achieve it using NW.js
https://timtaubert.de/blog/2016/01/build-your-own-signal-desktop/