Skip to content

Emailing Your Doctor…

It seems here in BC, there are doctors conversing with their patients via email, instead of the more traditional in-person style meetings. I love the use of technology to make processes more efficient, and I am fully behind the use of email as a medium between doctors and patients. But the security of email leaves me shaking in my booties.

Many people don’t realize the insecurities in email. First, the connection to send and receive email is not encrypted by default. Certain hosting companies, like Joyent, require encrypted connections by default. Of course, this makes setting up email clients a bit trickier, hence why the average joe-sick citizen is not going to configure their client to use it. With the connection left unencrypted, anyone eavesdropping on the wireless signal or over a wired hub connection (like some cable companies use) will be able to pick up the username and password credentials for your email account. They can then get into your account, read your email, or send email from your name. Some people don’t see this as a privacy concern. I say those people need to wake up and listen to identity theft stories.

The second problem with email is that the transmission of the email content itself is not encrypted. If you solved the first problem I mentioned, that secures the connection and transmission of the email content between yourself and your hosting company. The second part of the transmission is between the hosting company and the rest of the Internet until it reaches the target host. The problem here gets a bit technical, but a simple explanation is that there is no one path to a target host over the Internet. Remember, the Internet was developed to withstand a nuclear war, so your data will travel is any direction as long as it makes its way to the host in a reasonable amount of time. When the data is traveling through the Internet, bouncing around different intermediary hosts, that data is unencrypted and anyone can view the data if they have the technical skill (it doesn’t take much). So all of your information sent between your doctor and yourself is now being broadcast to everyone on your continent. That’s not violating doctor-client confidentiality but it’s getting pretty close. If you don’t think this is a privacy problem, then why did you traditionally go to the doctor and speak to them personally in a small room with no one else around?

The solution to the second problem is difficult and requires a lot of technical skill, especially with today’s email clients. You need to configure your email client to encrypt and sign your messages with a digital certificate (also known as public key cryptography). The problem with this is two-fold: first is that the sender’s email client needs to configure correctly, which is often difficult to do because each client is configured differently. The second problem is that the receiver’s email client needs to be configured correctly to check the signature and decrypt the data with their own private key. If your eyes are going sideways now, just wait until you set it all up. Email cryptography is still too difficult for the average person to configure, so by default people are not going to use it. That is going to leave a lot of people with medical conversations out in the open.

Are those files exactly what you ordered?

…after all, how would you know?

Batch processing typically involves moving large data files (so called extracts) between systems. These data files include can include financial information, billing information, reports, blah blah blah. The thing I see very often is the verification and authentication of extracts…or rather, the lack of it. I believe in the Bruce Schneier school of learning, where one must be born with the security mindset, as it cannot be learned. As a result, I’m always seeing exploitable problems where others just see efficiency.

The problem I see currently with moving large data files around is that the files are never verified as being complete. Sure, the transfer protocol being used by the underlying operating system says that it does a completeness check, but what if the file was tampered before it was sent? Whether these files move into different directories or over the network, they must be checked each time for completeness and authenticity. A simple solution to all of this is to use checksums, which has been the solution for authenticating downloadable Internet files for many years.

So if checksums are such a simple concept and have been around forever, why don’t all companies use them? The first is money. It takes more development to put in extra checks around the transfer of files, which in turn means a higher cost to the company. Second is that there is a lack of security-mindedness in code development today. This isn’t just about checking that your code is safe from SQL injections, this is about making sure that no part of the system can be subjected to exploit.

Here’s a real-world example. Instead of thinking of transferring extracts between systems, let’s translate that to money between transferred between a bank’s branch offices to the central hub. Since digital money or sci-fi credit systems do not yet exist, the money must instead be transferred by armoured vehicles. So which is the best place for someone to exploit? The banks can have the most secure environment possible, but they must give up some of their security during transport. This is a reasonable risk because there are numerous verification protocols in place before the money leaves and after it has arrived at the central hub.

Bringing the example back into our problem at hand, there is an inherent risk to sending extracts to another directory or over the network. The target filesystem can fail, the network can be sniffed, the target machine can be a zombie. Secure communications can mitigate that (MITM attacks aside) but one can never be certain if the files sent are the exact match to the files received.

Just a little something…

Yet another blog, but this one is different. I will be talking about open source technologies, automation, security and all the other things that my company dabbles in. If you are living around the Vancouver, BC area, send me an email! If not, send me an email anyway!