I think we're almost at the point where public TLS endpoints never have to move their ephemeral private keys out of RAM. 6 days is pretty long in even modern cloud infrastructure lifecycles and it's unlikely that an endpoint will go long without TLS certificates on restart (2-3 minutes seems to be average for Let's Encrypt) which is fine for rolling restarts, and acceptable for a lot of DR scenarios.
This dramatically simplifies a lot of security assumptions because you can run stateless endpoints and not worry about encryption at rest or some of the bootstrapping issues. For example, only give an init container temporary credentials to modify DNS for ACME, or rely on HTTP01 or
TLS-ALPN-01.
More frequent renewals pose various architectural problems, but it makes “lawful” TLS intercepts harder to execute without going unnoticed.
TLS intercepts with CA signed certificates can and been carried out. The undertone in previous reporting indicates that the execution depends on a mechanism that doesn’t have 100% reliability across renewal cycles, and shorter lifespans will make that more difficult to carry out without ostensibly visible warnings to the user.
It’s a headache, but you are supposed to be monitoring Certificate Transparency logs for rogue certificates. Barring that, shorter validity is a way to address it.
The mechanism was physical MITM of the server's network connection - they can 100% reliably get certificates issued since the domain name "legitimately" points to the MITM device at that point.
TLS intercepts harder to execute without going unnoticed.
I would expect the opposite. Certs and their fingerprints changing every few days would numb people to TLS changes. MitM would only get noticed if the expected cert is presented at the application layer which is a thing in jabber from your link above, IF it is enabled which it was not and why that MitM went unnoticed for so long. LetsEncrypt is just a DV cert so a cert being issued by other org for the same domain would not raise eyebrows at all. AFAIK no other web daemons in wide use support things like OMEMO/SSL SCRAM though it would be awesome if everyone was hosting their own jabber instances.
In a semi-private forum the fingerprint can be in a pinned comment along with the curl command for members to fetch it but that would have to be updated every few days and someone would have to bother to verify it each time. Doing this weekly could lead to fatigue.
I think we're almost at the point where public TLS endpoints never have to move their ephemeral private keys out of RAM. 6 days is pretty long in even modern cloud infrastructure lifecycles and it's unlikely that an endpoint will go long without TLS certificates on restart (2-3 minutes seems to be average for Let's Encrypt) which is fine for rolling restarts, and acceptable for a lot of DR scenarios.
This dramatically simplifies a lot of security assumptions because you can run stateless endpoints and not worry about encryption at rest or some of the bootstrapping issues. For example, only give an init container temporary credentials to modify DNS for ACME, or rely on HTTP01 or TLS-ALPN-01.
More frequent renewals pose various architectural problems, but it makes “lawful” TLS intercepts harder to execute without going unnoticed.
TLS intercepts with CA signed certificates can and been carried out. The undertone in previous reporting indicates that the execution depends on a mechanism that doesn’t have 100% reliability across renewal cycles, and shorter lifespans will make that more difficult to carry out without ostensibly visible warnings to the user.
It’s a headache, but you are supposed to be monitoring Certificate Transparency logs for rogue certificates. Barring that, shorter validity is a way to address it.
https://notes.valdikss.org.ru/jabber.ru-mitm/
The mechanism was physical MITM of the server's network connection - they can 100% reliably get certificates issued since the domain name "legitimately" points to the MITM device at that point.
TLS intercepts harder to execute without going unnoticed.
I would expect the opposite. Certs and their fingerprints changing every few days would numb people to TLS changes. MitM would only get noticed if the expected cert is presented at the application layer which is a thing in jabber from your link above, IF it is enabled which it was not and why that MitM went unnoticed for so long. LetsEncrypt is just a DV cert so a cert being issued by other org for the same domain would not raise eyebrows at all. AFAIK no other web daemons in wide use support things like OMEMO/SSL SCRAM though it would be awesome if everyone was hosting their own jabber instances.
In a semi-private forum the fingerprint can be in a pinned comment along with the curl command for members to fetch it but that would have to be updated every few days and someone would have to bother to verify it each time. Doing this weekly could lead to fatigue.