As you can see this post was published in 2019.
We’ve had pretty much everything about you go south.
Probably the most revealing thing, and the only one in years that led to some kind of reaction, where the Snowden revelations.
No, one of the main issues is that even after such a major incident, there are still email server is out there which allow for unencrypted sending/receiving of email.
The same applies for instant messaging services in the organization.
Sure, the NSA, and several other highly funded intelligence services will be capable of decrypting email sent back-and-forth between users; but I’m crafting them is a pretty good idea!
Just to give you a visual: sending an unencrypted email as like sending a postcard. Only on this postcard there are organizational secrets, which better not be made available to the public.
Further, sending an encrypted email isn’t only at risk of interception, but also much more easy to manipulate after it has made its way to the recipients.
Now, I am pretty straightforward and issuing advice; and the advice here is to systematically disallow, categorically, the sending and receiving of an encrypted email to and from your servers.
This works within an organization of course, but there will be cases where you have to communicate with customers, and other representatives of organizations which are not so technically advanced.
So we have to differentiate first of all between the differences of cryptography possibilities.
Number one is always the connection to the server, which should always be encrypted. This would be possible through methods like TLS.
The second, and more prominent example would be the encryption of the content of the email itself which can be achieved through things like PGP.
Having made that very important determination, we can move on to further dissect the problem.
The TLS connection from client to server is not a problem at all.
In fact, you can shut down on encrypted connections to an email server by a client, and a lot of Times the user wouldn’t even know it.
Client side email applications have become so good that they can self determine what type of connection to server requires, and along with that which security requirements are to be set on the client computer.
It becomes more difficult when we get to the actual content encryption of an email, which is the more interesting aspect considering that the recipients machine requires the same method of cryptography/decrypting the message.
In this case, the server doesn’t care… An email with an encrypted content will be delivered the same way that an encrypted email will be delivered.
Only in the case of the encrypted email, the server will be delivering gibberish; and storing gibberish.
If you need more help on this issue, please feel free to call me!
