In today’s information driven world, we’re constantly passing information back and forth. Whether this is a conversation, a database schema being transmitted or family photos that you’re trying to send someone, we’re all passing data around, and we’re doing it online. What’s the most widely used format for communicating with others online? Email. “Majority of users -- 84%, according to the National Telecommunications and Information Administration's report: A Nation Online, Feb 2002 -- connecting to the Internet for email or instant messaging services..

With the prevalence of emails as our chosen form of online communications, there are many things to take into account. Capacity, efficiency, and some would say most importantly, security, are all important focuses to facilitate reliable, usable and trusted email communications. In today’s world, security is even more of a concern as a fair amount of sensitive data gets passed around via email. Whether it be credit card numbers or private, personal information, we all want to keep our information to ourselves, and protect it from would-be snoopers.

One of the major ways that email security is being addressed is to offer, and in more and more cases enforce, encrypted email transactions. Soon the days of plain-text passwords and raw data being sent over the wire via email will be a thing of the past as the proliferation of client-to-server encryption continues.. This is an extremely good thing for your data’s security.

However, with encryption comes a cost, namely increased overhead to the already laden email servers that now have to try to perform massive amounts of crunching to decrypt/encrypt this newly encrypted traffic as necessary. This can be such a great increase in overhead that it can prove prohibitive in some cases, preventing the move to the more secure practice because of added costs for new/more servers to handle the additional load. There’s also the burden on administrators to configure the systems, let alone the additional systems they’ll have to manage now.

Enter F5. Here is yet another situation where we can help to extend the application layer via the network with powerful TMoS application fluency, and the flexibility of iRules. Why not let the network tier handle the decryption for you, and avoid putting any extra load on your mail servers? Better yet, let us enforce the policy as well, gently requesting users’ email clients to transmit with encryption and allowing you to decide what to do with those that aren’t able to transmit securely.

The following iRule is a great example of one way you can help keep your email secure without having to burden your email servers at all. It will enforce encryption via the LTM which keeps things not only secure, but fast and easily managed at a single point. The iRule even negotiates with the email client to try and initiate an encrypted transaction with those not configured for it by default. Handy? I think so.

when CLIENT_ACCEPTED {
    SSL::disable 
}

when SERVER_CONNECTED {
    TCP::collect
}

when CLIENT_DATA {
    set lcpayload [string tolower [TCP::payload]]
    if { $lcpayload starts_with "ehlo" } {
        TCP::respond "250-STARTTLS\r\n250 OK\r\n"
        TCP::payload replace 0 [TCP::payload length] ""
	TCP::release
	TCP::collect
    } elseif { $lcpayload starts_with "starttls" } {
        TCP::respond "220 Ready to start TLS\r\n"
        TCP::payload replace 0 [TCP::payload length] ""
        TCP::release
        SSL::enable
    } else {
        TCP::respond "530 Must issue a STARTTLS command first\r\n"
        TCP::payload replace 0 [TCP::payload length] ""
        TCP::release
        TCP::collect
    }
}

when SERVER_DATA {
    TCP::release
    clientside { TCP::collect }
}