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.

 

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. 

The risk of inactive/off-line systems

 The risk of inactive/off-line systems if just turned on and used

In our fast-paced world with cyber warfare going on, from nation states jockeying for the secrets of other nations with zero day hacks, to the many criminals looking for every way to get value out of everyone they can, software is constantly being patched to try and keep ahead. With so many people and businesses not patching, even old bugs are being probed all the time, and getting attacked. Using unpatched systems is a huge risk, sometimes even if just a few weeks, or sometimes days, out of date.

There are many reasons why a system might be unused for a while. They aren't just sitting there for no reason, but generally in one of the following paths

• Primary user on extended vacation or other extended leave.

• Pending deployment, with an active plan to do so.

• In reserve, with not active plan, other than to be available if needed. Perhaps on an eventual path to be decommissioned.
  

• On the way to being decommissioned and disposed.

If there is any intention of bringing a system into active use with little warning, they must be kept up to date, otherwise they represent a security risk as breachable/hackable defects are found but not patched. These machines would need to be regularly (every week or two) brought online and the full patch process run (Not just the few obvious ones, but the whole patch management process). This does not mean for all the system in reserve inventory, just enough for quick deployments (loaner or replacement) and the next ones are brought up to ready from extended off-line status.

Or

Any system that has been off-line for an extended time, is a huge safety risk to us if it is just deployed, until it has been through a few restarts, with time in between for the patch process to see what is needed and deployed. After the OS has gotten its patches, open the primary apps, and go to their ‘Help’ ‘About’ menu to check for any updates there. Browsers and email clients are a big target and the front lines of many cyberattacks.

If a system is on the path to likely being decommissioned, but we are just keeping it around "Just in case" then pull it out of any active monitoring systems it might be a part of, as those usually have a licensing cost you can free up, and they usually alarm/bug someone when they haven’t “called home”. Essentially some effort to ‘Mothballing’ the device, just like the Navy does with their ships, Air-forces often do with planes, or even clothes kept in the attic for that ‘maybe some day we might need this again’

There is a very active cyberwar going on, nation states juggling for control to avoid bullets, through all the criminals trying to get at what every they can grab. This has been accelerating at a rapid pace, and we can not rest on "it won't hit us" as we are all being actively probed all the time.

To be safe or as safe as possible, it is important that you keep your systems (both personal and business) as up to date as possible before and when actively using them.

Moving a GroupWise System

Through the life of a typical GroupWise system, it will likely move platforms at some point. No fancy migrations needed as all the database changes get done in place.

This could be hardware replacement, changing virtualization types, to hitting the limits of the OS at the time of the original installation. After all, you can only upgrade a box so much before there become issues with the OS. Even when you otherwise love that OS, a new install gains you so many of the advantages of it that are blocked in just upgrading it in place. Any GroupWise system of any real age has likely been moved a few times, such as from NetWare to NetWare to OES to OES

For this document, I will stick to current (late SLES15 era) and most common GroupWise hosting OS, with pure SLES or OES (built on SLES). Assuming GroupWise is the only application on the system so that the old box can be retired, and running an incremental copy of some sort. Imaging the data such as moving/copying a virtual drive can be done as well. This is for any and each server with a Domain and/or PostOffice on it. A GroupWise upgrade can be a part of this process if desired, but is assuming at least a GroupWise 2014 or greater source system.

This process allows you to build the new server in advance, and get the bulk of the files copied over in advance without downtime as those OFFILES are bulky, don't change much, and take a while (possibly many hours) for that initial copy. You are typically just looking at a couple of hours of downtime for the final move, under an hour if all goes smoothly.

Pre-migration is a good time to make sure your GroupWise maintenance is running properly, also check the results and files that are not part of the GroupWise system are removed from the GroupWise folders.

Build the new system with a different IP from the old server and a separate logical drive for GroupWise, either as NSS or XFS. Both are excellent options, both needing specific settings made, ideally at creation. NSS needs Salvage turned off, XFS (or any DB safe Linux type) mount points need the noatime and nodiratime set for optimal performance.

• Install GroupWise, but do NOT configure it!

• Restart the server at least once before the final migration to really finish that install.

• Copy the data with either rsync or dbcopy. rsync is very native with any Linux and is worth knowing for all platforms. I find it is the faster and easier of the two. It does every file that has ended up in the source (junk included) and doesn't get you restorable db files if the GW Agents are running, which is not a problem with such a migration. DBCopy requires a mount point to the new location to work, only does GroupWise files, is slower, and doesn't delete files. A script of the combination of them make for a decent low budget backup. Example in the Community.  

• Both tools can and the one you choose should be used incrementally, with a primary full copy of both the Domain and PostOffice folders, making sure the size at the destination is about what you see on the source. Identify any notable differences, as there may be issues to take care of. You can/should do this in the days leading to the actual flip outage of a couple of hours. If different versions, it tends to be best to use the newest dbcopy if you are using it, otherwise the direction of copy doesn't matter much.

• the rsync command that works well on SLES/OES with the only preparation of having the destination folder created. Alter the folders to match your system, and user if applicable. The command will want the password for root on the destination system or other if you changed it.
  
  
• # rsync -avh /grpwise/ root@xx.xx.xx.xx:/grpwise/ --delete

• Easy comparison tools:

• # du -h --max-depth=1 /GWdomain|GWpostoffice (the PO will take a while due to OFFILES)

• or install and use ncdu from GWdomain|GWpostoffice folders

• Is your GroupWise system the same IP as the server it is on, this is where we will change that. It makes these moves so much easier, is mandatory if you were to go to cluster services (where I learned this trick), and is how the containerized future of IT generally works.

• On the new server, make sure the /etc/hosts file has the GroupWise agents as FQDN entries as needed for GroupWise since 18.4, and that they match what you have in the agents' settings.

• On the new box, make sure the GroupWise agents ports are all open on the Firewall. Firewalls on servers are becoming less and less an option in the whole Zero Trust path of things.

• Firewall ports references

• https://www.novell.com/documentation/groupwise18/gw18_guide_admin/data/adm_appndx_port_numbers.html

• https://support.microfocus.com/kb/doc.php?id=7009520

• on MTA system: 7100, 7180, 9710

• on POA system: 1677, 8301, 7181, 7101, 7191, 9711,

• on GWIA system: usually an MTA set and 25, 9850

• For the final migration, make sure the source server's agents are shutdown, and preferably can't be turned back on

• # rcgrpwise stop

• # systemctl disable grpwise.service

• Perform the final sync.  With rsync, just repeat the command above.

• While that final sync is running, copy the following files to the new system.

• /etc/opt/novell/groupwise/gwha.conf

• /opt/novell/groupwise/agents/share/gwdva.dva

• /opt/novell/groupwise/certificates/*

• # scp /etc/opt/novell/groupwise/gwha.conf root@DestinationServer:/etc/opt/novell/groupwise/

• # scp /opt/novell/groupwise/agents/share/gwdva.dva root@DestinationServer:/opt/novell/groupwise/agents/share/

• # scp -r /opt/novell/groupwise/certificates/* root@DestinationServer:/opt/novell/groupwise/certificates/

• Once the sync is complete, remove the secondary IP from the source server if already using such, or down that server.

• Add the secondary IP to the new server

• # systemctl status grpwise.service

• may not be enabled yet. enable it and start it

• Test system, can you send & receive email, and manage the system

• A reboot to make sure it all behaves is a good thing as well.

If this feels overwhelming, and you are in Canada, please reach out to us, as we can help. For other feedback and comments, post a comment below. 

Is your email system ready to keep delivering email as the spam wars escalate?

Google's new restrictions on the email they will accept starting February 1st 2024 are just good practices we should be following.  But what are they really, and how can we make sure they are in place?

This applies to any sending email system, whether on your own servers, or hosted in the cloud such as with Microsoft or Google, to be successfully delivered. 

The pieces have all been here for a while as good optional settings, but now Google is just the first enforcing them:

1. The IP address of the server(s) your mail comes from must-have a reverse lookup.  PTR
2. The server must have a functioning encryption running.  STARTTLS
3. You must have published where your domain's mail is coming from.  SPF
4. Your server has to sign the message (like a wax seal).  DKIM
5. You have to publish your domain's alignment rules for #3 & #4, and where to send reports. DMARC

Note:

#3 & #4 are either/or for low volume senders, but both must be there for high volume senders.

#5 is mandatory for large volume senders.

It is a good idea to get all of them working, as inevitably, we will need to have this for all systems. #5 is the part that ties SPF and DKIM together to close the loop holes the spammers found in them. 

How to check:

Much of this is checked in DNS, checking the header/source of an email from the system, and talking directly to your mail server from another "mail server".  

• You can see if your system is good to go, or if you have problems by sending an email to a Gmail account you can log into. For each message in Gmail, you can check much of the status of a message that was sent to you, as to how the sending system was working or not at the new levels, at the time the message was sent.
• in Gmail, open the message,  then from the message 'more' stacked dots, select "<> Show original" 
• This view will show any results for any SPF, DKIM, or DMARC settings that are in place. If doesn't show, then that protection level doesn't yet exist for that internet domain or mailserver (i.e. it needs to be added).
• To check if it was encrypted, Ctl-F(search) for TLS, and there should be at least one (such as TLS1_3 or TLS1_2) for the connection from the sending server to Gmail's first server in.   

Summary:

Google is just the first, Yahoo! and AOL have committed to doing the same thing very soon, and Microsoft won't be far behind (looks like they may just be letting the others take the heat for being more secure)

These are also all good things to check and filter at your inbound / receiving mail systems.

Offering:

Would you like someone from outside your organization to validate how ready your organization is for these upcoming changes. Konecny Consulting for $99CDN + HST (payment via credit card) will do this checking for you. To engage with us please complete the contact form and we will get back to you. This offer is available to organizations within North America.

 

 

Google making major changes to email acceptance requirements

Will your email be blocked by Google, or are you ready for the changes they are making? Google will be blocking emails from weakly configured systems as of February 1^st, 2024. Make sure your system isn’t one of them that will be blocked.

Starting February 1st, Google will be imposing requirements on any emails being sent to a Gmail account.  They are asking for you to have some basic email system hygiene in place for your mail system.  If you are at all responsible for your own domain (the part after the @ symbol, such as username@gmail.com), then you must pay attention, whether you have an email server in your own data centre, or your email is hosted such as with 365 or Google.

Two other large email systems (Yahoo! and AOL) have already stated they are following in Google's footsteps, Microsoft is expected to follow before long.

These are Googles new requirements as of February 1st, 2024, and your email administrators need to make sure they are in place:

• All your outbound email servers must now do TLS encryption.  Without this, your email can be intercepted and read, or worse. There are still so many systems running without this, as it is Not a default on most of the ones you setup yourself.  Most hosted solutions do have this already, but not a bad thing to check.
• For systems with lower send rate, you need at least one of SPF and/or DKIM setup and working correctly.
• For systems that sometimes send more than 5,000 messages a day to Google Mail servers (including their customer domains they are hosting), then you must have both SPF AND DKIM working correctly AND DMARC setup.

 The most basic SPF and DMARC records you can setup for you domain is (in standard BIND notation):

@ TXT "v=spf1 a mx ~all"

_dmarc TXT "v=DMARC1; p=none; rua=mailto:{emailAddress2processReports}"

That SPF record is NOT guaranteed to work, as it must identify your email server(s). That DMARC record is very safe with an email address that does accept mail. Checking DKIM requires a proper analysis of those DMARC reports, though some spot checking can be done looking at the source header of received messages. 

For more details of Google’s current requirements, including the other 'little' details, read their "Email sender guidelines." https://support.google.com/a/answer/81126

Expect Google and others to increase their requirements in the future, such as the number of messages per day trigger point to be reduced, as well as requiring DMARC enforcement (not just reporting).

Yes, this can seem overwhelming. If you would like some assistance checking to see if your email system is ready for this major change, we may be able to assist you. Please reach out to us and we can discuss this with you.

Let Sleeping Services Be

AKA, latest scam attempted on me, with most of the caller's fumbles of his script left out.

A call claiming to be my ISP (never used it for home internet, but the phone number had been with them at one point, so others may have a match claiming your ISP based on who your phone has been with), that they had a failure on their server and that there 70% services stopped, and we need to fix them. 

Caller: How many devices do you have using the internet?  

Me: (quickly count the list) I have 15 IPs active today as seen on WhoIsConnectedSniffer (software I have running on my computer most of the time), but some of them should never get to the internet.   

Caller:  Then I need you to get in front of your computer.

Me:  OK, since that is where you caught me, where did you think I had WhoIsConnectedSniffer running?  yes I am there.

Caller: confused sounding

(a bit of back and forth with this drone in a call centre, to get him back on track of the scam to see where it is going)

Caller:  Do you see the Windows key?  Hold it down and press R

Me:  Ah, you want the Run prompt, OK, I am there.

Caller:  type in msconfig   and then press the OK button

Me: (I know this first bit is safe, so I proceed) Oh, it looks a bit different since I last looked this way, I see the Tabs: General, Boot, Services, ...

Caller:  OK, need you to click on Services, now see how many are stopped. 

Me:  Yes, I see many of  them stopped and that is the normal amount I expect there.

Caller: Then we need to remote into your computer to fix these stopped services as part of the service you paid for.

Me: But those services aren't needed, in fact some of them really shouldn't be running most of the time, rather like one doesn't leave their car running in the garage when they aren't driving it.

Caller:  But you paid for this service, so we need to restart them for you.

Note: This goes on back and forth for nearly 5 minutes until a meeting reminder gets me to wrapping up.  I could have so dragged him along for ages if I had the free time.

Me:  I have several ways to prove you are a scammer. 

• I'm not with the ISP you claim to be, though I have worked with them.
• It is normal for Windows to have stopped services as many are use only occasionally and the system knows how to trigger them on when needed, or are only on when the applicable hardware is turned on, example: the Bluetooth support service is stopped because I don't currently have Bluetooth turned on. 
• Clearly, as someone who mainly works on Linux servers, I still know way more about Windows than you do. 

Caller:    Ahh..ahh....ahhh..........

The line goes dead.  He was clearly very new at this, or was just following the script in front of him. 

Summary:

If you ask a question and they immediately re-ask their question, it is almost certainly a scam. 

Stopped Services on your computer is a normal thing, just like your microwave or shower are not running much of the time.  A server failure at your ISP is not going to impact the services on your computer, as, if necessary, a reboot of your system is all you should need.  Never let one of those callers remote into your system, as that is a disaster waiting to happen.  What exactly they will do varies, bit it won't be in your interest. 

Wired is Better

The debate is not wired vs wireless, but wired vs Less power|bandwidth|security

Cables can be a frustration at times for many people, so being without them feels so freeing, . . to a point.

To go without wires/cables for signal still requires power, and if you don't have a wire to provide that, you certainly have batteries involved that have their own frustrations to deal with.

The Batteries.  

Replaceable or built in rechargeable?

How fast are they drained?

•  Fast enough, you get the replace or recharge process down pat?   They last long enough that you might not recognize the odd symptoms of the system for a bit before it clicks that it is time to do something with the batteries. (mouse in the middle of an epic gaming session, or keyboard in the middle of trying to write down that perfect award-winning idea)
• And for built-in rechargeable, at least until they can not hold a charge anymore.

Yes, there is wireless power transmission tech being developed, but:

•  Extra cost to have and to power
• extra energy inefficiently spread in the form of non-ionizing radiation through you. We are many years away from any chance of proving them safe. Are you volunteering your body as a test bed?

The bandwidth you can put through radio (wireless communications) is about the same as a few strands of wire or fibre in a cable. And the space of radio waves is shared.  So if you try and pack a room full of active Wi-Fi sharing systems, you generally will get less bandwidth to each than if they were wired connections. Especially if there are many other nearby users of those radio frequencies. How many Wi-Fi Access Points do you see near you? You are sharing bandwidth with them and anything else that might be using those particular frequencies that you can't see, such as Bluetooth on 2.4GHz and microwaves that are really noisy in that space.

Security is typically less with wireLess.  There are so many more ways of intercepting wireless(radio) traffic, most without any indications of such an interception. Encryption can be defeated, it is anything but perfect. The end points of any wireless system can be readily attacked from a distance in a whole range of tactics in addition to any possible wired attack vectors. 

Example:  With some USB dongles they can be used to take over the computers they were plugged in to.  When did you last update your dongle's firmware? 
Is your dongle subject to MouseJack or KeyJack attacks?

Personal health, a potential issue with adding more radio waves going through your body and those you may care about nearby.  Radio waves are a form of Radiation. While not the really nasty ionizing radiation of fission of big atoms like Uranium, it is still energy that we didn't evolve with. We are already seeing evidence of harm from cellphone radio waves.

So where ever you can, a wired/cabled/fibred connection is generally more reliable, secure, energy efficient, lower cost (especially over product lifetime), less resources used to make and operate, less impact on the surrounding environment. While there are always exceptions, they are just exceptions to a rule, not an invalidation of this point.

Wireless things have their place, but like everything in life, there are trade-offs along the way.  Make them deliberately rather than letting marketing brainwash you down any particular path as they won't tell you the hidden costs or risks. 

Glossary: 

Wire - single strand of an electrical conducting metal. One is almost never enough

Fibre/Fiber - a single strand of optical fibre, usually plastic, that carries light as the signal medium.

Cable - a bundle of wires or fibres in a protective bundle. i.e what we usually see.

Paying it forward

For a lot of people, graduating from college can be a time when they say that they are done with education, and they aren't going to think about college ever again.

Well Darlene has proved that yes you can graduate from college but education never stops. She has also shown that paying it forward to the next generation of business students is also important. Darlene has over the last couple of years been mentoring students through the Ten Thousand Coffee program at Centennial College. She enjoys getting to know the students and new graduates and is always willing to share her knowledge and experience with them.

Recently, Darlene was interviewed for the blog "It Started at Centennial" for her journey from being a student at Centennial College to now being a Mentor.

Security Awareness Training Issues

Issues we've seen of some Security Awareness Training that limit its effectiveness, and ideas on how to improve them.

Does your solution suffer from these issues?

Training notifications resemble spam in a few ways (sense of urgency, a link) in addition to being overly annoying, and that is likely why we have seen them blocked, labelled Junk/spam, and otherwise ignored.  
   

* The notifications don't give the assignee an idea of how long the training will take.  For busy staff, especially those who have to track every hour (or less, as is the case for many professional service people) as billable,  this makes it very hard to schedule in to their plans.  Therefore, making it more likely for them to defer until they have a larger block of time and ability to listen to content to make sure they can complete in one go.   
      To Fix:  List the estimated time to complete, can it be paused or must it be completed in one go,  if Video, with or without Audio, just a slide-deck, or something else.
   

* Training is presented very piecemeal. Each element/training has its own mail stream, such that a busy person, in crunch time, can build up several queued training assignments and end-up with multiple nagging messages a day.  Junk mail handling is the easiest way to get them out of the way, cluttering up the key production communication tool of email.
      To Fix:  Consolidate those nag messages in some fashion.  A default should be One a day, with options both administratively and end user to set preferred time and timings to better reflect the local conditions of The Work (the reason the business exists, the training is a secondary support function that won't be allowed to wag the dog).

 

* Training alerts are currently oblivious to work schedules, even the most standard one of Monday to Friday.  The alert nag is based on X calendar days, not even X business days, so that trainees are getting alerts on off business hours. 

 

* If an assignee has been able to disconnect from email (weekends, vacations, collapse from overdoing a crunch, etc..), then they get a flood of those nags mixed in with all the other built up demands on their time leading to the nags being added to the rest of junk mail handling.

 

* If an assignee is trying to use a weekend to get The Work done during a normally quiet time, it's an interruption during a normally quiet time, again off to junk mail handling or similar in favour of The Work.

 * If an assignee is only paying attention to email on a weekend for emergencies (because normally a quiet time, vendors who send their marketing on weekends get down voted!)  Then any training alerts will only add up to frustration at the training and be invited to junk mail handling process.
      To Fix:  Default to X Business Days, not X Calendar Days for the training reminders, with those as clearly separate options.  And the Business Days needs to reflect the local Statutory and common Holidays, configurable would be nice to add business specific days that are reserved for things other than such secondary functions.   Bonus would be for a way to include(sync?) people vacation schedules to pause the training timers over peoples' scheduled time off.  Perhaps this could be the way to include Business and/or regional specific off days.
      
Related to the off hours notifications the system currently does, is that these notifications do trip up against a new legislative trend to protect employees personal time (that whole work/life balance thing).  Ontario is the first of the pack to have such legislation and off hours notifications put organizations based here in a rough spot, and we may well be forced to find other training providers that respect the Right to Disconnect.  
https://www.ontario.ca/document/your-guide-employment-standards-act-0/written-policy-disconnecting-from-work 

Why SSL(TLS) is a must for all websites.

What is SSL/TLS?

They are the evolving encryption tools that are the difference between a web page (via HTTP) that can be clearly Intercepted and ALTERED, and a page (via HTTPS) that is both encrypted with a chain of trust that makes it extremely difficult to view and even more difficult to alter in any way.  If you want to know more, you can read more here. 

To answer the questions of:

 - Why are some browsers making so much noise about why your unSSLized site is so untrustworthy?

 - Why your unsecured site is so low on the search engines?

Reason #1, the big one.

If your website doesn't have a proper TLS/SSL encryption in place, then if someone can intercept a person's browsing, it is easy to inject whatever hostile code is desired. It could be to just change what is showing on the page (this site hacked!), to silently injecting the latest ransomware or worse. 

You want your readers to get the message you so carefully crafted, not something else. You don't want them to equate you with putting malware on their system.

Reason #2
There is a pile of constant malicious scanning going on all the time, and just forcing your site to HTTPS causes a good portion of it hitting your site, to just go away.  One of my sites was getting many dozens a month of links from very dubious sites before I forced a switch to SSL, then they just went away.

There is then the whole Cyberwar part it of, where you could be caught in the middle of the big boys playing, as what was clearly happening as a part of a real hot war with the Russian Invasion of Ukraine as written up at the Internet Storm Center   where an entire block of IP addresses are redirected to another set of servers away from Twitter for a portion of the world.  Just too many ways for Man-In-The-Middle attacks.

So assuming you:

 - Don't want your readers scared away by the browser warnings

 - Don't want your readers to get used to a bad security practice because you taught them to

 - Don't want your readers' devices to become part of a hostile bot-net and/or worse.  

 - Would like (love?) your content to be more readily found by having a higher position in the search engines.

To get there

 This is done on the web-server itself, where you either pay for a certificate or use a free certificate service such as Let's Encrypt.  First you want to make sure your site works with the certificate so that you can get that lock in front of your URL (aka address) in the browser, and then you want to set it so that all attempts to come in unencrypted (port 80) get flipped/redirected to encrypted (port 443)

If you built your server, it is time to go RTFM for this as it is well documented for all Web-servers, as well as many others have written about the process. Your favourite search engine can also point you to resources.

If you are using a more typical hosted service, there is a very good chance the ability is sitting there in your control panel, just waiting to be turned on. Automatic free encryption has been a part of CPanel for a couple of years now (my hosters turned it on automatically for me), and a quick search shows that many of the others have a similar feature.  So take a look at your control panel, use the knowledge base most hosters setup, or even contact your support to see how good they are. 

There will be attempts to up-sell you to a higher grade of certificate.  If you just have a basic, low volume static site, then there is no real value in the "enhanced protections".  If you are gathering anything beyond comments and email addresses, such as e-commerce orders, then an actual purchased certificate makes some sense.  If you do go with a purchased certificate, make sure your hoster manages it and the update/renewal process, that they should have, is automated as certificates only last a year or less.

Do you require any assistance in securing your systems? Perhaps we can help.

Firefox's DNS settings

Managing Firefox's DNS settings rather than them controlling you.

Firefox does a few things intending to make your browsing experience better, but this isn't without its own issues.  This article is about the things Firefox does with DNS, some of the issues with what they do, and how to manage some of it. Some basic understanding of DNS required.

Firefox for starters, adds its own level of DNS that it even exists makes life more challenging to troubleshoot problems:

• It has its own layer of cache that, by default, remembers a given DNS lookup for 60 seconds. Clearing your host's DNS cache does not clear this one, and I've seen it remember failures, which is the straw that pushed me to learn all of this.

• It looks up all the links on a page when you load the page. So if a page has many links like I have in my bookmark pages or my client site admin pages, then it actually slows things down in addition to effectively advertising what page you were on to whoever might be watching DNS traffic.  Never mind all the additional traffic/packets to sieve through when troubleshooting.

Recently, Mozilla has added a new feature that will tunnel the DNS traffic over HTTPS through to their own DNS servers, aka DoH.  While good to protect the otherwise easy to read DNS traffic from prying eyes, it does mean that Mozilla/Cloudflare gets to see all your browsing DNS traffic.  Cloudflare is the current provider of this service for Firefox, and it is a changeable setting.  This makes it a question of which do you trust more, your local DNS path or Mozilla/Cloudflare?  Mozilla's stated intention is to have DoH be the default in the future, and they are 'just testing,' and now they are giving unsure messages of it given the push-back. ZDNet article on the downsides of DoH.  A way of blocking Firefox DoH

To see and possibly edit the settings for these, we need to get under the hood where we can do damage if we fumble finger anything.  So the first thing you want to do is backup your Firefox profile.  You can (and should periodically do) backup the entire profile as per Mozilla Support.

•  I make a point of clearing my Firefox cache beforehand to keep the backup size manageable.
• The file that gets touched in the following is the prefs.js, so making multiple copies of this as you edit your settings is a good thing.

Steps to see/edit Firefox DNS configuration:

• Type "about:config" in Firefox's address bar and press the Enter key.  
• Accept the warning/risk and be very careful here.
• On older Firefox (or newer after clicking on "Show All") : Scroll down to the network.dns....  selections about 3/4 the way down,  where a capital 'I' is ahead of the lowercase 'd' (ASCII sort rather than alphabetic sort)
• On Firefox starting with version 71 you get a prompt where you enter 'dns' for one set of below and then replace with 'trr' for the rest.

The settings of note are:
network.dns.disablePrefetch
   I set this to true as it doesn't make much sense for my use having FF go and look up all the things on the pages when I only go to one of them at a time.

network.dnsCacheExpiration
network.dnsCacheEntries
network.dnsCacheExpirationGracePeriod
   Setting either expiration or entries to '0' (zero) stops Firefox from caching DNS entries, leaving that up to your OS and upstream DNS server(s). Setting all three to '0' (zero) makes sure Firefox's cache is not being used.

network.trr.mode 0
network.trr.uri https://mozilla.cloudflare-dns.com/dns-query
   This is for the DNS over HTTPS, where the mode is a 0 or 5 has it disabled, and the URI is where it goes for content.     For more about this setting or the easier/safer way to set them


Any changes appear to be immediate, so just close you're about:config tab and proceed as per normal. Some browsing may be faster; some may be slower, but either way, you are that much more in control of your surfing.

Update 2019-12-15  After first writing this, Firefox made some nice changes with version 71 on how the about:config page works and this is now included.   Further reading on the (Anti-)Competitive and Network Neutrality aspects of DoH that shows how for most of us DoH is more pain than gain with out much of the touted benefit.