Navigating the rapid evolution of the encryption we use that is causing problems

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

Checking TLS certificates in use

In the efforts to secure communications over TCP/IP, we often have to deal with the certificates that are the keys to the process. Checking that the correct and correctly configured certificate (or cert for short) is the one running, is an essential troubleshooting/validation step. 

The best way where possible is to check the running cert on the running service. Especially that the correct cert that is being used.  Typically, we'd be looking at the dates that it is valid, the name (subject or common name), and the Subject Alternative Name (SAN)

For Web interfaces, a browser is the ultimate testing tool, with Firefox being the (currently in 2026) most consistent to work with, but the general concepts are the same with the others even if done differently.  If there is a problem stopping you from getting to the page, you just have to pause there, because the details are already available. 

Firefox:

For some issues, it will offer you to look at the cert below the scary sounding warning, if so, that is the easy option. Otherwise, if you've accepted the risk already or it is a good cert, you should see a little shield in front of the URL. The shield shows with a checkmark in it for good, or an Exclamation mark (Not Secure) if not.

Click on that shield, and in top right of that sub-window click on "Connection {not} secure" as the case may be.  Select "More site Information" at the bottom, and then View Certificate to see a page with all the details that you can 'print' for your records (usually to pdf or such)

Chrome (and related):

If there is a cert issue stopping you with the dreaded "Your connection is not private", click on the red "Not secure" in front of the URL, where you will see the option for Certificate details to click on, and then look at. The first tab has some useful basics, but often we need to look at the details tab to expand the fields you want to look at, such as to find the Extension of 'Certificate Subject Alternative Name'. The Export option saves an actual public key that can be looked at with tools such as openssl or KeyStore Explorer that we'll discuss further down.

If the cert is accepted as a secure one, click on the slider 'tune' button in front of the URL, click on "Connection is secure", click on the "Certificate is Valid" to see the Certificate details described above. 

Other options:

If you have to do this regularly, there is a GUI tool called  https://keystore-explorer.org/  KeyStore Explorer that works with most GUI. 

For our purposes, select 'Examine', 'Examine TSL/SSL', enter the target host and port, 

With the next page not directly showing the SAN, that is one of the Extensions, where if the cert has a SAN, you see the Extension, and clicking on it shows the value(s)

Linux Systems:

If you are on a Linux system (or can shell into), we can use https://en.wikipedia.org/wiki/OpenSSL openssl from the command line without an install. Other operating systems typically need an install.

 # openssl s_client -showcerts -connect {serverIP|FQDN}:443 |openssl x509 -noout -text |less

 # openssl s_client -showcerts -connect google.com:443 |openssl x509 -noout -text |less

While the default secured web traffic set to port 443, others can readily be used and often are used for administrative interfaces.  Also, there are many other services that use TLS to secure them, and this is where the openssl command and KeyStore Explorer are our most available options to look at them. 

Direct file examination:

 #  openssl x509 -in server.crt -text -noout

or with KeyStore Explorer, 'Examine' from the menu, 'Examine File', browse to the file to be examined.

There are other options and ways, this is just the primer as I found many who need these steps don't know them off of hand, so this is an effort to make it easy. 

Moderation of groups/forums

Keeping a group/forum civil and on track can be quite a challenge.

Moderators have a range of challenges dealing with keeping a group on a track:

• Posters who don't understand what a group/forum is about (its core focus) and post stuff way outside that focus.  Clutter. 
• Bad actors: those spammers/scammers trying to pull attention away to other things that have nothing to do with the group/forum, even if they make their post look superficially like it belongs. I've often seen these go to incompatible or even competing products/services, and beyond to straight out scams and malware. These bad actors are hoping that readers are careless, thinking that those links have been vetted already, and that all vetting is perfect.
• Posters who have a real question or concern, but provide insufficient information about it, assuming the other participants are mind readers. There are often several ways the issue or concern could be taken, so others have to ask clarifying questions back at you to better understand, and as part of vetting your post.  
• Posters who don't speak the same language/culture as the group default/majority.

Tips: 

• If posts get through without being held for review, they have NOT been vetted and can't be trusted like you might others you already know in the group. Look who posted it, and even there could be a masqueraded or compromised account. 
• Even if the content of a group/forum looks all good, and you see active moderation happening, bad stuff still sneaks in and can take some time to be cleared out. Making sure you report such content helps the moderators see it as they aren't in the group 24/7 (most are unpaid volunteers!).
• If a group/forum has lots of out of scope and/or junk content, that is probably a group without active moderation. If it is an area that you'd like to be cleaner and be a part of, try to moderate it by flagging bad content as moderators can't see it all. You might even be invited to help moderate, or you can even offer if there is even someone there who could grant you those technical permissions. 
• If your post is answered with questions, they are usually honest, and jumping back at them makes you appear more like the spammer/scammers. Bad actor posters will often use bullying approach to push their suspicious content through, inviting the wrath of the BanHammer (a range of control moderators have to pause or block bad actors).

Summary:
Groups/forums can be useful and fun, but as with any other human activity, we can have misunderstandings among honest caring people, and we can have bad actors trying to mess things up one way or another. So be ready for the occasional such misunderstanding, because none of us are perfect, whether flesh or artificial.  Being nice is just the least friction path forward, especially for those of us trying to keep the arena of conversation nice.

 

Security culture at work

When someone says that a business needs to have a security culture, it can be a challenge to understand what that is, but it is quite simple. A business must be security aware and that means everyone not just the IT department. Without a security culture many staff/management will ignore, complain about, and even bypass the technical security controls that get in their way.

A security culture starts from the highest level of management as they are the ones that are going to be setting the examples and providing the guidelines and policies that the rest of the business will be following. If senior management doesn’t have a security culture it is going to be extremely difficult to have it within a business.

If IT is trying to assist with developing a security culture it might help a bit, but it is still going to be a challenge without senior management buy in. IT can assist with the implementation of security training, such as awareness training but if senior management isn’t taking it themselves and setting guidelines about it, it doesn’t help the security culture within the company.

One of the biggest things that needs to be done is for senior management to develop polices that are enforceable with regards to the various security things that an individual needs to do to make sure that they are being secure when they are using company assets or even within the company property. These policies also need to be followed by the senior management otherwise they aren’t going to work.

So many senior managers think they are doing the right thing themselves, but so often they are proven that they are not aware that what they are doing is putting themselves and the business at risk. Seniors manage may have some security awareness, but given the speed of how the world is changing, they need to keep up with it. It is amazing how often we have heard that someone has left their laptop in their car, in their garage and they think it’s safe, but it really isn’t because garages can be broken into and devices that are in the car could be stolen. We have also been told that all laptop users turn off their laptops each night only to see that they just close the laptop and take it from location to location, is it locked, maybe not. The other thing with laptops is why are they sitting in the office overnight, turned on and logged on and not secured as this is another security risk. 

Senior management needs to set guidelines and policies that are enforcement so that employees understand that there is a cost for not following the policies. At first, it can be a warning of violating the policy, the second time could be some unpaid time away from the office and then depending on the policy that is being violated it could result in being terminated.

Overall, security is about having the people within the business that will support and follow the various policies and guidelines. For security to work well, it is only as secure as the weakest user and everyone needs to understand that.

 

Death by Power Point

How many of us have gone to a meeting or conference and suddenly, a power point presentation starts to be shown. There are so many people that try and put everyone on the slides instead of just those few key points.

Something that is very important to think about when you are preparing a power point presentation is how much information you should be putting on a slide. The less is more rules apply here because the less words you can put on a slide the better. Keep the slides to only the key points and not every word you are going to be saying during the presentation.

Here is an example of an about me done in two different ways and think about what would look better on a slide:

About Me

-          Small business co-owner

-          Project Manager

-          Bookkeeper

-          Enjoys crafting as a hobby

About Me

-          Small business co-owner of Konecny Consulting Inc

-          Project Management and have my CAPM, which is Certified Associate Project Manager

-          Enjoy crafting as a hobby and I enjoy doing a lot of the needle arts, such as knitting, cross stitch and others

As you can see, I have shown two different about me slides that I might use when I am giving a presentation myself. There is only one that I would use, and it would be the first one because those are the key talking points and I can add all the extra details when I am speaking. Besides keeping the words to a minimum, I would also try and keep the font that I am using very simple and easy to read.

When you are preparing a presentation, you must think about the background colour of your slides as well as the colour of the words on the screen. The lighter the background the better and try and stick with darker colours for the words. Do not try and put light colour words on a light background because that is extremely hard to read. Also, something else that you need to think about is all of those gif’s and flashing things that you add to your presentation. These can affect people in so many ways. Keep any gif as a quick thing and don’t leave it up on the screen for very long because you could be risking the health of someone else. Causing an attendee to collapse doesn't help your message.

After you have finished preparing your presentation, put it up onto your screen but then stand back from where you normally sit and see what the presentation looks like. Do you have to add more pages because of your talking points, or do you need to increase the size of your font so that people at the back of the room can see what you are trying to say.

Power point or any slide presentation system can be a useful tool but using it wisely is important. The keep it simple rule applies and if you are trying to show a screen shot on a slide, make sure that you aren’t showing the entire screen just what is key to what you are talking about.

Example:

To reboot your computer, go to the window button, click on it and then select the power button which is on the right of the window.

Trying to read that from a distance would be a real change especially if you have that at the top of the slide and the rest of the slide is blank. So, remember any presentation tool can be useful if used wisely and make sure you have done a spell check of the entire presentation before you give it as you wouldn’t want to be embarrassed because of some silly spelling errors. The last point I want to make is once you have completed your presentation have someone else look at it and see what they think because they might spot errors that you haven’t. 

Helping to keep yourselves safe on the interent

Here is an idea that you can share with your business, friends, and/or family to help keep everyone as safe as possible.

Subject: Keeping your work and personal data safe 

All our systems are increasingly under attack from growing hordes of bad actors (whom actively use automation to probe Everywhere/Everything).  There are some things we can all do to keep our data and identities safe from abuse, loss, and/or exposure.

A) Make sure that you are routinely restarting all your systems (phones, computers, tablets, etc.) at least once a week, so that the background patching can finish.  All patches require that the running software is stopped for the newer software to take its place. While some software can do this while we work, several key security sensitive parts can't do that without a full restart/reboot.

B) Make sure your Security Awareness training is complete, to help you keep clear of the ever-evolving scams facing us all, whether though work or personal communications, whether targeting the business or you personally. 

Your IT team is working all the time to make sure your systems and processes are as secure as they can get them. It is a never-ending game as the bad actors figure new ways to get at us and try to catch us in those slip ups in getting the safe things done in a timely manner. Please remember that just putting your device to sleep or closing your laptop is not restarting/rebooting your system.

As for all automation you may have setup, "Fire and Forget" is fine, provided you never actually forget. Check the automation regularly to ensure they are working. 

Tech versus non-tech terms

There are times that when you are listening to a group of people have a discussion you may think that they are talking a foreign language, but they are speaking English, just that they are using terms that don’t seem to make sense in the conversation. In some of these cases, it isn’t the word or term that they are using, it’s how it is understood by everyone that is part of the conversation. I do know that a lot of technical people have what seems to be a secret language that they speak, and it can be very confusion for those that are not directly related to a particular expertise.

I have decided to try and decode some of the words that I have been hearing and how they can be misunderstood by those around us. Now let’s have some fun and see how one acronym or term can mean a lot of different things, and it all depends on who is listening to the conversation.

DC

• Direct current
• District of Columbia
• Domain controller
• Data centre

Backup

• Extra help or support
• Copy of a file
• A situation in which something is not moving
• Music that accompanies the main singer or tune

SAN

• Storage Area Network
• SANS institute

Farm

• A plot of land that grows crops and livestock
• A group of computer systems in one or more cabinets.

These are just four examples of how a word or acronym can have more than one meaning and when you are in a conversation with a bunch of people it can be very confusing to listen to a conversation. One important thing to remember is when you are writing an email, or a document, and you use any of these terms it is important to ensure that everyone that may read the email or document understands the correct meaning of the term. Be careful of prejudging what "Everyone" knows.

It is very important to know the audience that you are writing something because even if they are in a different area of Technology, they may have an entirely different meaning for the same term. So, a term can have a lot of different meanings, and understanding how to communicate to the various people in an organization is very important. It is the translating infosec into regular IT and IT into regular business terms that is vital for good communication.