Nmap Security Scanner
*Intro
*Ref Guide
*Install Guide
*Download
*Changelog
*Book
*Docs
Security Lists
*Nmap Hackers
*Nmap Dev
*Bugtraq
*Full Disclosure
*Pen Test
*Basics
*More
Security Tools
*Pass crackers
*Sniffers
*Vuln Scanners
*Web scanners
*Wireless
*Exploitation
*Packet crafters
*More
Site News
Site Search:
Exploit World
Advertising
About/Contact
Credits
Sponsors:
edgeos



Security Basics: StartTLS (was: Email Encryption Between Servers)

StartTLS (was: Email Encryption Between Servers)

From: Bear Giles <bgiles_at_coyotesong.com>
Date: Wed, 02 Apr 2003 15:18:06 -0700

I don't understand why so many people are pushing VPN solutions.
They have their place, but in this case it's driving a screw with
a hammer.

The two key words in your requirements are:

1) email

and

2) HIPAA

The reason I'm emphasizing the latter is because you don't just
want encryption, you want to be able to provide proof that you
used encryption. It also means (if I understand HIPAA correctly)
that you're not just worried about privacy loss because somebody
is sniffing network traffic, you also need to pro-actively take
steps to avoid handing off mail to an unauthorized MTA pretending
to be an authorized party.

Fortunately there's already a standard solution to this problem:
use a MTA that supports the "STARTTLS" extension. I'm not
familiar with Exchange, but I'm sure it (or an add-on) supports
it. All of the standard Unix MTAs support it - sendmail, postfix,
qmail, etc.

In a nutshell, STARTTLS gives you TLS (SSL) encryption during your
email session. It does not require either the senders or
receivers do anything special, it just encrypts the traffic when
talking to another STARTTLS-enabled MTA. Most if not all MTAs
allow you to log the fact that the message was encrypted into the
header ("Received: from example.com[192.168.1.1] using Blowfish
(128 bits)"), to say nothing of your MTA logs. This can be used
to prove due diligence, if it ever becomes an issue.

You can use self-signed certificates, or you could buy them from a
trusted third party. Given the nature of your problem, you
probably want to verify the peer certificate. This isn't a
problem with self-signed certs, you just need to exchange them
with your peers at some point.

Finally, you can set up most if not all MTAs to *require* a valid
cert before you'll talk to them. This ensures that your MTA won't
fall back to an unencrypted channel if there's a problem.
Strictly speaking it's a violation of the RFC, but it's widely
practiced in situations like this.

Taking a further step back, don't let the fact that you're running
Exchange blind you to other MTAs. I've heard that many sites have
dramatically improved their network environment by moving their
Exchange servers fully within their firewall, and relaying all
mail through a Unix MTA sitting in their DMZ. N.B., this MTA is
set up as a inside-to-outside and vice versa relay only - it
should not perform any local mail delivery. Depending upon how
much spam- and virus-filtering you want to perform on this
gateway, even ancient boat anchors (e.g., P-100s) are more than
sufficient.

Bear

-------------------------------------------------------------------
SurfControl E-mail Filter puts the brakes on spam,
viruses and malicious code. Safeguard your business
critical communications. Download a free 30-day trial:
http://www.securityfocus.com/SurfControl-security-basics
Received on Apr 03 2003

[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]
edgeos