E-Mail Encryption Help

[Jeff Zylstra]

Maybe this is a subject for a blog, maybe not.  Anyway, we are sometimes forced to e-mail  insurance applications (as attachments) or plain text e-mails that contain social security numbers.   I know this is dangerous, but surprisingly both health and P&C insurance companies think nothing of this.  They don't seem to be interested in giving us an SSL encrypted website where we can upload these or some other facility, and most don't support ZIX Mail or other solutions (that are a royal pain).   Faxing is unfortunately NOT reliable with them, which is why we are e-mailing.

I'm wondering if I can talk them into getting an SSL certificate, so that can be used to authenticate that we are actually sending these confidential e-mails to them, and not someone else posing as them.  My limited knowledge of this indicates that we could do either SSL or TLS encryption if they had an SSL certificate.  My (again) limited research indicates that these are only about $150 a year for a cheap certificate from Comodo or other company.   I'm wondering if my assumptions and/or understanding is correct, and 

[Todd Arnold]

Hey Jeff,

ACT did a lot of pushing on the TLS topic in recent years.  Here's a link to a page that has a lot of TLS related links on it that you might find useful.  Good stuff:

http://www.iiaba.net/na/16_AgentsCouncilForTechnology/NA20070710103244?ContentPreference=NA&ActiveState=AZ&ContentLevel1=ACT&ContentLevel2=&ContentLevel3=&ActiveTab=NA&StartRow=0

[Mark]

Jeff, if their email server supports TLS and your server supports TLS, then the transaction can be encrypted.  Most servers now days support this, but I know there are some that do not have it turned on for whatever reason (though, maybe that has changed over the last year or two).

You can find out using nslookup and telnet to determine if TLS is supported or not.

[Ben Thoele]

The other way to tell if your partners are using TLS is to look at incoming email headers.  Unfortunately this doesn't tell you if email is encrypted on the sending side.

Received: from [209.85.213.170] (HELO mail-yx0-f170.google.com)  by
inbound.appriver.com (CommuniGate Pro SMTP 5.2.16)  with ESMTPS id 164224849
for xxxxxxxx@xxxxxxx.net; Tue, 18 Oct 2011 13:39:51 -0500


As you can see the hop between Gmail and Appriver was done using ESMTP with an S on the end, that tells me that it went secure.  SMTPS would also be secure but not ESMTP or SMTP.  Looking at email headers can also tell you which filtering appliances your partners are using which can be interesting.  Are they using Zixmail, Ironport, or an outsourcer? 

Make sure the hop between your spam filter and your email server is TLS if it goes across the web.  We had to have AppRiver change which server they had us on.  This will help you avoid state breach notification laws.

[Bloody Jack Kidd]

something like ShareFile may also work - whether you foot they bill or they do is the sticky bit.

http://www.sharefile.com/

[Mark]

The other way to tell if your partners are using TLS is to look at incoming email headers.  Unfortunately this doesn't tell you if email is encrypted on the sending side.

Received: from [209.85.213.170] (HELO mail-yx0-f170.google.com)  by
inbound.appriver.com (CommuniGate Pro SMTP 5.2.16)  with ESMTPS id 164224849
for xxxxxxxx@xxxxxxx.net; Tue, 18 Oct 2011 13:39:51 -0500


As you can see the hop between Gmail and Appriver was done using ESMTP with an S on the end, that tells me that it went secure.  SMTPS would also be secure but not ESMTP or SMTP.  Looking at email headers can also tell you which filtering appliances your partners are using which can be interesting.  Are they using Zixmail, Ironport, or an outsourcer? 

Make sure the hop between your spam filter and your email server is TLS if it goes across the web.  We had to have AppRiver change which server they had us on.  This will help you avoid state breach notification laws.

All good info.  Jeff, I think your first step woudl be to get an email server   We use MX Logic (instead of AppRiver) and my Exchange 2003 Server is set for TLS so it is secure between us ans MX Logic.  Exchange 2003 doesn't offer opportunistic TLS, so it's either on or off -- which is one reason why many organizations don't support it (they need to be on a newer Exchange to support both -- or, create a slightly complicated setup).

[Jeff Golas]

Are you sure about Exchange 03 and opportunistic TLS? I had it working fine last time I tried it (a year ago). Me and Kevin Crow created a TLS connector between our servers.

[Mark]

Are you sure about Exchange 03 and opportunistic TLS? I had it working fine last time I tried it (a year ago). Me and Kevin Crow created a TLS connector between our servers.

Well, I think you have to setup multiple SMTP virtual servers, but honestly I didn't dig too much into it since we filter outbound anyway.

In 2003, right-click a SMTP virtual server -> Properties -> Delivery -> Outbound Security: TLS Encryption is either checked or not.  That's why I mentioned the possible need for a "slightly complicated" setup.  I believe that it's opportunistic by default with newer versions of Exch.  That, or you just turn opportunistic on.  For those who haven't figured it out, opportunistic means that it will send via TLS when TLS is available and plain when it's not.

I'm satisfied with our setup because it is TLS between us and MX Logic, and they have opportunistic on their side, plus they let us force it by domain or email address and we also have their encryption option so we can encrypt specific messages with the portal access method that we all love to hate.

[Jeff Zylstra]

Agreed.  This is all good stuff.  Thank you, gentlemen.   I just want to make sure I understand some of this so I can talk intelligently (yea, I know  ) to the IT folks at the insurance companies.  I really can't believe that our primary health insurance carrier doesn't have something in place already, much less the company that doesn't allow us to do checking of credit scores via an SSL connection on their website. 

So, is an SSL certificate required on just THEIR end, or on BOTH ends of the e-mail? 

[Mark]

So, is an SSL certificate required on just THEIR end, or on BOTH ends of the e-mail?

Pretty sure both ends.  In an Exchange environment you would generally have this already for your Outlook Web Access (many people use a self signed certificate for that, but I recommend buying one at least from GoDaddy with their $12.99 coupon).

[Jeff Zylstra]

So, is an SSL certificate required on just THEIR end, or on BOTH ends of the e-mail?

Pretty sure both ends.  In an Exchange environment you would generally have this already for your Outlook Web Access (many people use a self signed certificate for that, but I recommend buying one at least from GoDaddy with their $12.99 coupon).

It's still worth it to me, so that I can say that I've done my part and that any data breach is most likely on someone else's end and not my end.  Thanks, Mark.

[Jeff Golas]

They have to have some kind of certificate - it can even be self-signed, and where it matters is how the opposite side deals with it. Some servers may be set to require a trusted cert, others may be loosely configured to trust anything as long as it's encrypted.

Opportunistic TLS basically means server A tries to talk to server B securely...if it can...it will, and if not, the email still goes through normal means. There's varying degrees of TLS enforcement from eh to STUPER MANDATORY and I'm pretty sure in Exchange you can tweak which one you want to use. (I'm going by memory so don't quote me exactly on this)..

First and foremost...in Exchange you can configure it with an SMTP connector so that any mail going to an address or group of addresses uses a  "smart host" - IE sends it directly to a particular email server rather than depend on MX records. In some or many cases you may need or want to do this because the MX records point to a service like Appriver or Messagelabs, and you want email coming or going to a domain to just go right from point A to point B. There's no need for an additional SMTP server or seperate IPs (unless you're using a particular email server host/domain name attached to your certificate).

Then you have the levels of TLS enforcment....

1. Mandatory TLS - connection between the two servers MUST be encrypted, and I believe the servers MUST trust the opposite server's certificate. Meaning, server A must have a root cert or a CA cert for the cert used on server B and vice-versa. (It may be possible to have mandatory TLS without the trusted cert just as long as the connection is encrypted).

2. Opportunistic TLS - Server A tries to talk to server B securely - if it happens, it happens. If not, the email goes through normal channels. I believe at this level though the cert must still be trusted if they talk securely.

3. Opportunistic TLS - Server A tries to talk securely to server B...if it happens it happens, and if server A doesn't have a root cert for server B, doesn't matter. (technically its still encrypted, but not establishing trust means a possible man in the middle attack).

[Mark]

Good explanation Mr. Golas.

[Jeff Zylstra]

Thank you, Jeff, Mark and everyone who responded.  TLS seems like a cheap, easy and unobtrusive way to make everyone safer.  I just hope that my companies can and will cooperate. 

[Mark]

I just hope that my companies can and will cooperate.

Good luck.  I didn't pursue the companies at all.  I just left it as is.