Right, I think what I'm actually worried about is how an old system deals with the certificate authorities of two decades from now.
-
-
Replying to @sortiecat
Ideally there's a chain of trust from its ancient CA roots to whatever ones are used decades from now.
1 reply 0 retweets 0 likes -
Replying to @RichFelker @sortiecat
If not, then you have no option but to add new root CAs or manually accept the new certs without the system being able to validate them.
1 reply 0 retweets 0 likes -
Replying to @RichFelker @sortiecat
"Just fallback [automatically] to http" is in no way a better option, and completely defeats the purpose of having https.
1 reply 0 retweets 1 like -
Replying to @RichFelker
No the fallback must be explicit (edit config file). It just has to work, and will keep working, unlike crypto schemes disappearing from TLS
2 replies 0 retweets 0 likes -
Replying to @sortiecat
I think you're imagining a threat that doesn't exist, but maybe I'm missing something.
2 replies 0 retweets 0 likes -
Replying to @RichFelker @sortiecat
I'm not aware of any good reason for server implementations to remove ciphers from the (non-authenticated) client's choice of ciphers.
1 reply 0 retweets 0 likes -
Replying to @RichFelker @sortiecat
You just need to protect against MITM downgrade attacks.
1 reply 0 retweets 0 likes -
Replying to @RichFelker
Removing support for old TLS versions and cipher seems like a good thing to me. But that only happens on the client then?
1 reply 0 retweets 0 likes -
Replying to @sortiecat
Unless server is using TLS to authenticate the identity of the client (client certs), server has no reason to disallow old versions/ciphers.
1 reply 0 retweets 0 likes
If you are using TLS to authenticate identity (as a client does of the server), downgrade attacks are a threat to that.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.