In the wake of Google’s revelation that its GMail service had been repeatedly attacked over the past year the search engine goliath announced it would be moving to HTTPS (HTTP over SSL) by default for all GMail connections. For users, nothing much changes except that all communication with GMail will be encrypted in transit using industry standard SSL, regardless of whether they ask for it by specifying HTTPS as a protocol or not. In the industry we generally refer to this as an HTTPS redirect, and it’s often implemented by automatically rewriting the URI using a load balancing / application delivery solution.

Widely regarding as a good idea, and I’m certainly not disagreeing with that opinion, SSL secures data exchanged between the client and the server by encrypting every request and response using a private/public key exchange. This is a Good Idea and the general advice that “you should do this too” is sound; protecting data in transit from prying eyes eliminates the possibility that someone with ill intent might “sniff” out data and steal a user’s e-mail messages. Given the number of small and medium businesses that rely upon GMail for business-related communication and that some of that communication might be considered confidential or sensitive, this simple security mechanism is certainly one that has a high value with minimal risk and costs associated with implementation.

But it’s not a panacea, especially where cookies are involved. Tony Bourke of Load Balancing Digest reminds us of the dangers of transmitting cookies in the clear in “Gmail Goes All SSL, and So Should You”:

While most webmail and other web applications do HTTPS for when a username and password is supplied, most do not use HTTPS for the rest of the interaction.

For webmail especially, this is critical.  Cookies are used as authentication tokens (so that username and passwords do not need to be re-supplied every time you ask for a web page), and if they’re intercepted, someone could potentially pretend to be you.

Cookie-based vulnerabilities have been used before to exploit GMail. One of the more (in)famous being a CSRF (Cross Site Request Forgery) that exploited the use of cookies for authentication. Jeremiah Grossman in “Advanced Web Attack Techniques using GMail” explains one technique, noting that Google addressed the vulnerability within days of discovery.

SSL, of course, does almost nothing to assist in addressing vulnerabilities related to cookies because SSL is designed to secure transmissions in flight, i.e. while it is on the network being transferred between the client and the server. The reason Google can so easily force a move to all SSL for GMail is because it requires no action on the part of the user. SSL encrypted transmissions are automatically handled by the browser and decrypted upon being received by the client so it can be interpreted and rendered for the user.

But that means cookies are still in the clear on the client-side and could be potentially exploited in a variety of ways, accidently via malware or intentionally through tampering. To truly secure cookies and prevent tampering and exploitation by malware cookies should be encrypted themselves.

C

Cookie encryption is more along the lines of field-level encryption. That is, the cookie’s data is encrypted in such a way as to prevent its contents from being viewed or manipulated on the client while other data is left “in the clear” on the client, alleviating the need for additional PKI (Public Key Infrastructure) support above and beyond that implemented by browser’s today to support SSL-enabled communication.

Cookie encryption allows the server or other application delivery intermediary to ensure only it can decrypt the data, and any tampering with that cookie is immediately noticeable by the device or application that encrypted it in the first place. Cookie encryption can be applied to cookies on the server side, from within the application or it can be applied at the network-side, using a network-side scripting capable intermediary. The latter allows you to apply encryption to cookies immediately to all applications without modifying application code, which can save time and money and remove the need to invoke encryption on the server which can chew up additional CPU resources that ultimately eat into response times and degrade application performance. The impact of field-level encryption, particularly on a small number of cookies, from within the application on CPU resources is likely minimal; thus implementing on the server or network-side simply becomes an architectural choice if the number of cookies is small.

Whether employing network or server-side scripting as a means to encrypt cookies the result is the same. The cookie, on the client side, appears to be jabberwocky. When the cookie is received by the intermediary or application, it is decrypted into something that actually makes sense.

The process is simply reversed on the response.

Cookie encryption isn’t rocket science at all and is a fairly simple security technique to implement. What may be a bit more complicated is the process of ensuring the cookie is valid – that is, that it hasn’t been manipulated or tampered with while on the client. This requires some application logic to go along with the decryption process, something that is more easily accomplished via an intermediary than in the application itself. The prevention of cookie tampering is one of the core functions of a web application firewall, and the use of such a solution allows essentially umbrella coverage of all applications for such attacks in a single, centralized location.

What’s important to remember is that simply adding SSL to a web application only secures data in transit. Cookies and other sensitive data will be human readable – and thus able to be manipulated or tampered with – on the client, and cookie encryption mitigates this risk.

D

Enabling SSL as a protection mechanism against prying eyes is absolutely a good idea and if Google’s decision to force all GMail connections to leverage SSL means more organizations will be following suit then Google deserves a round of applause for highlighting its decision. But let’s all take the additional step of encrypting cookies, too, especially when we’re storing authentication and authorization data in them for a variety of web applications.

Don’t stop at just enabling SSL; take the next step if you haven’t already and help keep your cookies to yourself.

Related blogs & articles:

• Gmail to get secure Net connection by default
• Gmail Goes All SSL, and So Should You
• Advanced Web Attack Techniques using GMail
• Encrypting Cookie Data with ASP.NET
• PHP: mcrypt_encrypt
• Encrypting Cookies with iRules
• HTTP cookie (Wikipedia)
• 9 ways to use network-side scripting to architect faster, scalable, more secure applications
• Web 2.0 Security Part 5: Strategies to CUT RISK