|Intro|  |News|  |Threats|  |Alerts|  |Papers|  |Events|  |Reading|  |Links|  |About Me|  |Powered-by...|
Fee, fie, foe, fum, I smell the password of someone who's dumb
[Back to Main]

It's universally realized in the security community that common e-mail protocols are un-encrypted and, as a result, send any authentication "in the clear".  This was generally believed to not be a great problem, since exploiting that weakness would require the attacker to be well positioned with access to an intermediate router somewhere along the lines.  This belief should be reexamined in light of some developing trends.

First, it has been assumed all along that you could trust the users in your own organization, but that assumption is very dangerous.  Some studies cite as many as 80% of all attacks as originating from "insiders".  Even setting aside your own employees, you have contractors, consultents, managed services personel, and temporary help to worry about.  It's some times believed that you don't have to worry about sniffing on switched networks, but ARP cache poisoning has proven to be very effective in turning switches back into "dumb hubs" for the sake of sniffing.

The above only deals with conventional wired networks, but have you considered WiFi (802.11a/b/g)?  Not only do you have to worry about officially supported WiFi segments that are rolled-out by your own IT department, but you have to consider rogue APs that could be setup by employees, or remote employees using laptops in coffee shops, cafes, or even in their own homes (WiFi is becoming incredibly popular with consumers).  Wireless is such a broad issue that we'll discussion it further in it's own section.

OK, so enough with the doom and gloom, what can be done?  A lot, fortunately.  For starters, all three common Internet e-mail protocols have standards for using encrypted transports (SMTP, POP3, and IMAP4).  I'm unfortunately very unaware of the existence or inexistence of any encryption methods for the native protocols used by Exchange, Notes, and Groupwise.  Knowing Microsoft, I would suspect that at least MAPI is not encrypted, but I'll need to do some more research to confirm that.

So let's concentrate on the three Internet protocols for now--actually, let's add a forth:  Webmail.  All of the previous have standards written for SSL/TLS session encryption.  That is to say, there are standard methods of encrypting all the information sent back and forth during a session, including authentication.

For SMTP it is supported by TLS/STARTTLS.  There is a dedicated port set aside (465/tcp) for SMTPS, but much more commonly is implemented as a function of ExtendedSMTP (ESMTP) over the standard port 25/tcp.  All the common clients that I'm aware of have support, including recent versions of Microsoft Outlook and Outlook Express.  POP3 has port 995/tcp, and IMAP4 has port 993/tcp.  The encrypted versions of these protocols generally are implemented over those two ports.  Webmail will of course have standard HTTPS as an option, it's covered slightly down the page.

Great, so there are encrypted protocols, now what?  Well conveniently enough, most major mail daemons support them.  Nearly all commercial products support TLS, plus the Open Source daemons such as Postfix, Sendmail, Qpopper, etc...  Check the documentation for you daemon and chances are, the most recent version will support TLS.  Even Microsoft's IMS connectors for SMTP, POP3, and IMAP4 support TLS and the Microsoft KB has articles for implementing them.  Setting up TLS/SSL requires generating and signing X.509 certificates and telling your daemon where to locate them when it starts up.

Last we have webmail, that can come in various shapes and sizes, from Microsoft on down to tiny Open Source projects.  If you're rolling out such a product, make certain that it requires SSL/TLS connections over port 443/tcp.  All major HTTP servers support it, so make sure your webmail product supports it, too.  Webmail is so frequently access from remote locations (coffee shops, cybercafes, airports, hotels, etc) that it should never be allowed unencrypted.

Once you have configured and tested TLS support in your daemon with the client(s) that your organization uses, you should request that IT make the client TLS settings standard for their Ghost image that they place on new workstations and laptops.  You should also ask your security team to require TLS connections in their policy, and agree on some date for cutting off support for cleartext protocol support.  Going forward, you should only use encrypted protocols, even on your LAN if possible, and certainly for all external or wireless access.

What if TLS just isn't an option (due to software not supporting it, or management not wanting to turn the network upside down with a client setting change)?  Well you still have options.  All external e-mail access should be restricted to VPN-only (you do have a corporate VPN, right?).  No employee should be able to connect from outside your wired network without using a VPN.

Obviously there is a huge industry for VPN software and hardware, some are easier to implement than others.  There are even several Open Source VPN projects, although extreme care should be taken to vet such a solution thoroughly prior to adopting it, as many serious flaws have been found in some of the Open Source VPN projects.  Some operating systems have native support for setting up IPSec tunnels, such as OpenBSD and FreeBSD.




This site © copyright 2003-2011 Brian Keefer.  Unauthorized republication is forbidden.