The biggest trip-up is a growing number of incompatible systems trying to connect, and it is usually either an age or configuration issue.
To get to what we need to do, you need to understand why, so that we can achieve what we want to keep things working. The why this is happening, is directly due to the increasing computing power via the push of quantum computing on the cusp of decoding the older and existing encryption ciphers.
Quantum computing is evolving fast and we've been learning what types of problems it is best for. Asymmetric encryption is one it is doing well to crack, including ALL the existing ones currently used. Public Key Encryption (PKI) is the anchor of TLS (Transport Layer Security, formally SSL) so that our browsing (httpS) and authentication/ID lookup (ldapS) depend on. PKI is based on those asymmetric algorithms that clearly need to be replaced.
There are two parallel paths being taken to manage this.
- Shortening the key lifetime period
- Creating a new key algorithms and key exchange
Certificate / key lifetime:
If you manage certificates for any publicly visible web and ldap servers, and you don't want errors showing to your visitors, you have to get a certificate from a public CA (Certificate Authority). In the earliest days, you could get 10-year expiry, but it was soon found that the private keys do occasionally get exposed, after which, whom ever has it can decode everything it was used on. So started the path to reducing the Cert expiry/key lifespan in the age of manual certificate renewal and placement. Manual renewal and placement of certs have always been a bit of pain, so some automation was needed. To fill that need the Let's Encrypt project https://en.wikipedia.org/wiki/Let%27s_Encrypt started that now spans to now being the largest Certificate Authority through to the ACME protocol that is now the Internet Standard RFC 8555 https://www.rfc-editor.org/info/rfc8555/. Let's Encrypt automates 90 and shorter Cert lifespans easily.
The shrinking Certificate lifespan is enforced by the CA/Browser Forum agreements, where the browsers will only include CA links to those CAs that
A) conform to the current Maximum Certificate lifespan (going down every year to 47 days in 2029), https://www.ssl.com/article/preparing-for-47-day-ssl-tls-certificates/
B) has the tools to automate the certificate renewal and placement
For your certificates that are entirely internal from an internal CA, this doesn't directly apply, yet. It will change eventually, even if just newer software not being able to handle manual certificates anymore. Internal CAs will need mechanisms for overlapping root certs so that we don't have to manually do system wide re-certification process every time like some systems still have.
As the certificate life span shrinks, any system that has the wrong date will increasingly have issues connected to things, as a system that is more than the certificate life span out of sync fails any validation. Certificate validity date/time range gets important, otherwise we get failures for them being read as not valid.
I wrote up the tools to check these in use previously at https://blog.konecnyconsulting.ca/2026/08/checking-tls-certificates-in-use.html
Quantum resistant certificate algorithms and associated key exchange
The root of the cryptography are the cipher algorithms, and the keys that go with them. Asymmetric algorithm PKI for the server identity chain, and to negotiate/exchange the symmetric algorithm keys used for the bulk exchange, with frequent changing of those symmetric keys during sessions.
The symmetric algorithms in use are shown to still be strong and resistant to the new quantum computing. But the asymmetric algorithms in use appear to be readily figured out, i.e. those keys can theoretically be extracted with some experimental success already. The original Diffie-Hellman cipher algorithms have already been defeated by conventional computing and have already been in phase out for many years. RSA (Rivest–Shamir–Adleman) algorithms have been the mainstay for a long time, but they are the first that are starting to fall to those early quantum computers, and NIST has declared them deprecated and to be phased out in the government by 2030. EC (Elliptic Curves) are the newer, and already widely deployed algorithms, they too have shown they can be cracked by quantum computing, just not as readily as RSA. The next generation of algorithms aren't ready yet, but they are getting close, and path forward is established.
When a TLS client (web browser or LDAP ID lookup) connects to the TLS server (apache, IIS, AD, eDir), there is a handshake to negotiate which algorithm and cipher they will use, ideally the strongest possibly, but that has been an attack vector in the past, so key exchange mechanics are important. The current ones have been shown to be vulnerable to quantum computing cracking, so a new key exchange has been defined and is already being rolled out. This new ML-KEM Key Exchange is already live on many big websites and available to any client that supports it. Standard related software such as OpenSSL has supported it since version 3.5. If a client doesn't support ML-KEM Key Exchange, the server will fall back to the older ways until they are removed. Making sure your systems are updated to use ML-KEM Key Exchange is a big push now to be ready for the next steps, given how long it can take to get all software coded up to date, and then deployed.
There are two parts on the server side of TLS to manage on this migration.
1) The software and what ciphers and key exchange mechanisms it supports. This is on the developers to make sure they are rolling out the appropriate code to handle RSA for legacy systems until they are all dealt with, handle EC at the same time for the more updated clients and include running the ML-KEM Key Exchange.
2) The Certificates placed with those servers, and what certificates are in them. Current expectation is for the certificates to have both RSA and EC keys in them, so that the strongest can be used by the clients as we make sure they are all using the newest before we can remove the old ones. In the next year or so we should start adding the new ML-DSA Digital Signature keys once that standard is ratified.
To check what your systems are doing isn't quite as easy as the first part, as they are a part of the mechanisms that are non-trivial to decode at the packet level, nor do our standard clients expose those details.
https://testssl.sh/ so far appears to be THE tool to use. The system you run it on will impact tests depending on your version of OpenSSL
grab the most current version, 3.2.3 at time of this writing, and get it onto your work directory of a Linuxish system/vm and expand with
# tar -zxvf testssl.sh-3.2.3.tar.gz
cd to the new directory and run it in a large terminal session for lots of useful data.
# ./testssl.sh {targetFQDNorIP:port}
or with a URI
# ./testssl.sh https://testssl.sh/
(Note: standard port for HTTPS is 443, for LDAPS is 636, but to works against any TLS connection)
This will show you lots of useful information about that target system, with green being good, red and yellow for their appropriate bad/warning status.
The results can be overwhelming, but as you learn, it is so useful, and even gives you scores of things that are good (in green or can be changed to blue for the colourblind), warning (yellow), or a real problem(red)
The section of testssl.sh's results that start with "Testing server's cipher preferences" up until the "Testing server defaults (Server Hello)" header are the core for this issue.
What ciphers are offered, if it has a preference (good) or not (weak), and if the newer quantum ready key exchange is offered.
Ideally, we want to see the modern strongest Elliptic Curve offered, that we see starting with ECDHE-ECDSA- as well as still (for now) have the other older ones available until we are sure those older clients have been updated. We want to see TLS1.3 offered, and the only old one being TLS1.2 unless you are supporting really old systems out there.
For key exchange, under "..forward secrecy.." we want to see some KEMs offered like
KEMs offered X25519MLKEM768 (vs none)
WireShark can see some of the details at the start
of the negotiation. The challenge is that we only see a part of the
conversation before it shifts to encrypting the rest of the handshake, that you
can only read if you have the certificates/keys involved.
Summary: Things we need to be doing NOW
Make sure everything is synced in time to a central standard
Enable TLS v1.3
Enable ML-KEM Key Exchange
Automate certificate issuance
Glossary and useful links
PKI: https://en.wikipedia.org/wiki/Public_key_infrastructure
RSA: https://en.wikipedia.org/wiki/RSA_cryptosystem
EC: https://en.wikipedia.org/wiki/Elliptic-curve_cryptography
https://blog.konecnyconsulting.ca/2026/08/checking-tls-certificates-in-use.html
No comments:
Post a Comment