Encrypting Data in Transit

The headlines this week are that Microsoft has joined Google and Yahoo in plans to encrypt data over their internal networks. Edward Snowden revealed that the US National Security Agency (NSA) tapped data traveling in clear text from Google to Yahoo’s data center. These companies are trying to restore some confidence in the confidentiality of their data before their customers bolt or avoid signing up for their cloud services. Your customers, both internal and external, probably are asking you about that as well.

What is missing from media accounts is exactly how Microsoft and Google plan to encrypt data-in-transmit. Twitter says it will use perfect forward secrecy to add the additional security so that if a session key, derived from the private key and public keys, is compromised, then said session key cannot be used to read encrypted data. No one has explained yet–we promise to do so here in a future post–what exactly they mean by “compromised” and what is perfect forward security. There are lots of loose definitions out there on the Internet, but not much that dives into the details.

How do encrypt data-at-rest is well known. Disk drives and databases already have techniques for encryption. The connection to the databases can be encrypted too using a certificate and SSL (For example, an LDAP connection over SSL is called LDAPs.). Remote users can connect to the corporation network using IPSec over VPN, but mobile apps do not use VPN or should not be required to do so, because it is a burden on the mobile user to have to connect to both (a) the internet and (b) the corporate LAN, not to mention that VPN does not always work. For those remote users who are using browsers, traffic from the web server to the browser can be encrypted using the standard technique of SSL. Wi-Fi connections are encrypted or should be set up that way.

But what to do about encrypting data flowing from, say, the web server to the application? That is in clear text and subject to hacking.

One way to encrypt data on the internal network is to use MACSec Encryption. Cisco Catalyst 3750-X and 3560-X switches supports this. That encrypts packets between switches, but not all the way to PC connected to the LAN. Plus encrypting data across the network will defeat some security measures (malware detections) that you have put in place.

What about the hit on performance? It takes a millisecond or so to encrypt and decrypt data and much computing power. How is Google doing to do that on terabytes of data flowing through their network? You think they will put a guided tour of that online as they have with their current data centers?

What about the cost of additional hardware or software? What about key management? The problem with keys is if you lose them, there is no way to recover encrypted data, plus keys expire over time. For a lost key you could, of course, just set up again the network connection if you forget where you have written down the password to the private key. Forget to replace an expired one and you have a Tier I outage.

Companies generally don’t encrypt email except when the receiver and sender are on the same domain and using the same email client. For example, when Wells Fargo saved Wachovia from bankruptcy and the two companies merged, their employees could not send encrypted emails to one another because Wells Fargo used Microsoft Exchange (i.e., Outlook) and Wachovia used Lotus Notes. That situation lasted until the Wachovia domain was shut down and both operated as WellsFargo.com.

People no longer talk exclusively about perimeter security as the internal network has been shown to be prone to hacking. You cannot install public-facing firewalls and intrusion detection and forget about security concerns. Now companies need to think about encrypted traffic inside the data center or what is called data-in-transit. How to do that, at what cost, and at what hit on performance is still an evolving topic.