My business sometimes receives emails from our clients that are sent through a "secure" third-party inbox. The client send the message through this third-party service. The third party creates an inbox for me and stores the message there. The third party then sends me an email at my normal address with a link to access the message in the "secure" inbox.

Some examples of providers of this service are Symantec Web Email Protection and Citrix sharefile.com. We collect a lot of payroll information and it seems like many payroll companies like paycor.com use this technique to send payroll data. Paycor appears to send these message through a Cisco service that appends "securemail03" to the front of the domain. You can see the login page here:

https://securemail03.paycor.com

My question is, how is this supposed to make the email more secure? If I accidentally forward an email sent directly to me, one email is possibly exposed to people who weren't supposed to see it, but if I accidentally forward the link to my "secure" inbox, anyone who gets the link has access to all of the messages in my "secure" inbox. What am I misunderstanding?

To clarify, these are not Spam or phishing messages we receive asking us to log in on a fake Dropbox or Google Drive page; they are legitimate emails. Additionally, these are not large emails that are too big to send as an attachment. I don't want answers dealing with other benefits of sending the email through a third-party inbox; I just want to know what the security benefits are.

  • These services are actually less secure than a regular email with GPG/SMIME encryption. If you really care about security, then you should use GPG/SMIME and don't bother with these jokers. Setting expiry date does not prevent the receiver from making a copy of the message. – Lie Ryan Mar 3 '15 at 3:28
  • 1
    @LieRyan I added a digital signature to my mail for about a year and I'm the only one who's ever used it. I often get "I couldn't open your p7s attachment." – Chloe Mar 3 '15 at 4:04
up vote 1 down vote accepted

The level of security offered by many of these services varies greatly. As usual, there is no such thing as 100% seure. It is all about levels of security and ensuring the level you select is adequate for the level of risk your exposed to.

The problem with email is that it pre-dates network security concerns. When the SMTP protocol was defined, we had a much higher level of trust and security just wasn't a significant concern. This means that all subsequent attempts to make it more secure involve bolting on additional functionality rather than building on to a base which incorporated security from the ground up.

There are three broad areas where email security is a problem. Most secure email solutions are only able to deal with two of these areas and the thirds is frequently overlooked completely.

  1. SMTP Protocol. Essentially, this is a plain text protocol with an underlying assumption of trust. There have been extensions developed which now encrypt the data, but this is not necessarily enforced. When email was first developed, the networks involved were not as stable or reliable as they are now. To handle this, SMTP was defined with a robust routing approach which could handle networks which were often unavailable or had changes in topology. Many people don't realise that when you send an email from one person to another, your message doesn't necessarily go straight from your mail server to theirs. It is possible that the message will be relayed through a number of intermediate mail servers before reaching its final destination. To make it even worse, you cannot know exactly which mail servers the message will be routed through and therefore, cannot guarantee the level of integrity of the servers involved. Even when you request encrypted extensions, there is no guarantee that all the servers involved will honour that request. While the increased stability and improved connectivity of the Internet has reduced the frequency of mail going through unknown servers and while more servers are configured in a more secure way, there is still no guarantee - essentially, you are relying on the integrity of systems you have no insight into and trusting in the skills of unknown administrators etc.

  2. Client protocols. Even if you are able to guarantee that the mail servers are secure and that all SMTP traffic is being encrypted, you then have to consider how the clients are retrieving the messages i.e. POP or IMAP. Nearly all reputable providers now provide POP/IMAP over SSL/TLS, you cannot guarantee the recipient of your mail is doing so. For backwards compatibility, many providers will still support unencrypted POP/IMAP. Then there is the issue of where the messages end up being left. If you are using POP, then most likely, the message will be downloaded to your client machine and removed from the server (though this is not guaranteed). If you are using IMAP, then the message is most likely left on the server. Does the server use encrypted mail boxes? Probably not and if they do, then probably all the mail is encruypted with the same key and even if it isn't, most likely the sys admins on the system have access to the key.

  3. Client mail storage. This is the most often overlooked area of concern with respect to email. When you send a message, does your client keep a copy of the message on your hard drive? Is that copy encrypted? Often, it does keep a copy and rarely is it encrypted. Likewise, when you retrieve the mail from the server and store it in your inbox, is it encrypted? Probably not. Most compromises occur on client machines i.e. virus/malware and email is frequently a rich source of information.

Very few of the secure mail solutions are able to address all the possible security risks. They frequently focus on addressing the SMTP weaknesses by requiring those sending mail to connect directly to their server and for clients retrieving mail to connect directly to their server. This eliminates the risks associated with SMTP mail routing. The provider has control over all servers involved and therefore can have increased guarantees over how things are managed. In addition, they will enforce good client (both sender and receiver) security, usually be ensuring connections are encrypted and often by providing enhanced authentication, such as personal certificates, multi-factor etc. They will often reduce risks by providing ways to ensure messages are safely deleted after user set grace periods and will ensure that the messages are only stored in encrypted formats. In some cases, they will provide the mailbox owner with encryption keys so that only the owner is able to decrypt the messages and even the sys admins can't read them. However, none of these services can ensure security on the client end - what the sender does with messages they send and what the receiver does with messages once they recieve them.

So, if specialist providers can do this, why don't all providers just do this and we can all have secure mail? Part of the problem is that often the approach does not scale well. However, the real problem is with mail routing. The basic SMTP protocol simply does not provide the ability to specify which mail hosts you willl allow your message to be routed through.

Are secure mail services worthwhile? Well, depending on the service,, yes they can be, but this really depends on your level of risk and therefore needs to be assessed on a case by case basis. There simply is no guaranteed secure mail solution apart from encrypting the data yourself.

So why don't we just encrypt the data ourselves? The main reason is that its too hard to manage. If you encrypt your mail, you need to communicate the decryption key to your recipient. Both you and your recipient need to be setup to handle encrypted mail and you have to manage lots of keys. In some cases, where the risks warrant it, going to this degree of effort is justified, but for most cases, it is more effort than its worth and certainly not a good general solution. The real answer is to develop a whole new email protocol which incorporates security as a fundamental design goal. However, getting everyone to move to such a new protocol and ensuring the millions of servers and clients are updated to support it is a huge task. It is also unlikely to occur as I suspect email is being subsumed by other modes of communication. Although still fundamental in the enterprise, I've observed a significant drop in use by the next generation - talk to a few kids and you will find they hardly ever use email, preferring SMS and IM instead. Even the enterprise is seeing a move towards more collaborative style comms with things like Lync, IM, direct file sharing etc.

The piece you're missing is that with these services (at least in my experience) you are required to create a login credential to access the secure service mail box the first time you use that particular service for that particular sender. Further, the sender (who contracted with the service) can set time limits for the items so that they become unavailable to anyone (including the intended recipient) after a specified period of time.

When you access emails via these services, your access is through TLS. (So is the sender's access if their "side" is configured correctly).

Compared to normal email the sender's information is more secure.

  1. Its not bouncing around "in the clear" over all sorts of potentially malicious email relays.

  2. It is (presumably) encrypted in place in the "service provider" system.

  3. The recipient has to utilize a log in credential to retrieve the message and then does so only over TLS encrypted transport.

  4. The messages can be made to expire.

  5. The service provider logs IP address and other details of each "access" of the information within the secure service portal.

My experience is that these services are inconvenient and take away some of the quick back and forth that makes email worthwhile. But there can be no doubt that they are more secure than vanilla email.

  • Thanks for that. To clarify, if both the sender and the receiver are using SSL or TLS to access their "normal" inbox, does that give their "normal" email the same benefits as #1, #2, and #3 in your list, leaving only #4 and #5 as the benefits to the "secure" inbox? Obviously, that's only if it is known that the receiver is using SSL or TLS. – browly Mar 2 '15 at 23:46
  • 1
    @browly, no, if you use SSL/TLS to access your email (say, IMAP over SSL/TLS), then you don't get the benefits of #1 or #2; only of #3. The way you access your email only affects how you get the email from your mail provider -- it doesn't affect how the email bounces around between mail relays (#1) or whether the email is stored in encrypted form or not (#2). – D.W. Mar 2 '15 at 23:51

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.