Gmail Traffic Now Encrypted By Default, But Will Organizations Heed The Shift?

Kudos to the folks at Gmail who, in defaulting to a secure browser setting (as opposed to the previous insecure default) for sending and retrieving email, have decided to help users who may not know enough to help themselves. The new default (see screenshot below) tells the browser to access the Gmail service over HTTPS instead of the prior default, HTTP. This significant shift by Google is a reminder that there's probably more you can do to secure your organization's data and communications.HTTP is the underlying protocol to the Web and HTTPS is the secure version of it; the one that sends and receives transmissions between a browser and the Web servers it's connecting to in encrypted form. In the same way that many online storefronts rely on HTTPS to hide sensitive information such as credit card data from prying eyes (people who have access to the physical or wireless network over which the data is being transmitted), Gmail has always relied on HTTPS for its login process to ensure that user IDs and passwords are securely transmitted.

The move by Google comes on the heels of a coordinated attack on certain Gmail accounts in China which in turn is unfolding into a huge drama on the geopolitical and international business stages. According to New York Times blogger Riva Richmond:

Sam Schillace, an engineering director at Google Apps, said the shift to default HTTPS was not prompted by the attacks and, to the best of his knowledge, would not have averted them. The move had been in the works for some six months, during which time Google engineers did extensive testing and made numerous technical fixes to enable a smooth transition.

Back in June 2009, Google posted a blog noting how, at that time, they were contemplating the idea of defaulting to HTTPS but how it was also looking into the potential impact on user experience.

Prior to transmission, encrypting what would otherwise appear as "clear text" to would-be snoopers requires more of everything. It puts a heavier load on the PC and it can take more network traffic to complete the transaction given how encryption can increase the transmission's total network payload. And then, there's the effort it takes for the machine on the other end to decrypt the transmission. Between all of these hits on performance, reliance on HTTPS can slow down the user experience. Whether it does so measurably in a way that makes a big difference to the end user's productivity depends on the application. continued below...

For email (and Gmail specifically), I've never felt as though reliance on HTTPS was a hindrance to my productivity. Although the option to default to HTTPS became a part of Gmail's feature set in 2008, the option to securely connect a browser to Gmail's servers over HTTPS has always been available to Gmail users.

Long before it became an option in Gmail's settings, I switched my bookmarks for Gmail to use HTTPS instead of HTTP at the beginning of the URL. When accessing Gmail from a computer other than my own, I always remembered to hand-type HTTPS into the URL. Only once, at a Gartner Conference (of all conferences) did the usage of HTTPS prevent me from accessing my Gmail (it also prevented me from accessing the corporate intranet since our virtual private network was HTTPS-based). Mid-conference, Gartner corrected the problem by opening up the standard HTTPS port 443 in the conference network's firewall and other than that one experience, relying on HTTPS as never slowed me down.

Speaking of virtual private networks, one thing to consider before accepting the default to HTTPS is whether a user's traffic is already encrypted by virtue of being on VPN. For example, my computer spends about 95 percent of its time connected to a corporate network over a VPN. All of the traffic going over any WiFi network that I connect to is already encrypted. This doesn't eliminate the need to connect to Gmail over HTTPS. But being on a VPN greatly reduces the risk of connecting to Gmail (or anything else for that matter) over HTTP. That said, once that traffic enters your corporate network (and from that point forward as it makes its way to Google's servers over the Internet), it is no longer encrypted. If prying eyes have access to the remaining part of "the circuit" going to Google, they will be able to decode any unencrypted transmissions without too much trouble.

Many years ago, when I predominantly tested hardware and software, I would often put that hardware and software on the corporate network and then I'd use the open source protocol analyzer Ethereal (comes with most distributions of GNU/Linux) to see how secure that hardware or software was. But in the course of determining how secure those products were, I got to see what other traffic was crossing the corporate backbone in clear text. Let's put it this way: you'd be very surprised if you did the same thing.

Fortunately, most local area networks rely on Ethernet switches these days (as opposed to hubs with shared buses). When switches are in use, it's not as simple as plugging your computer into the wall and seeing all the traffic. Most of those Ethernet connections are "private" connections and can only see communications that are intended for the connected PC (and other special network broadcasts). But if someone with nefarious intent has access to the corporate backbone, then that's a big weakness.

Given Google's move, the question that remains is how many IT people will take that as reminder to double check who in their organizations is using what Web-based services and whether they're connecting those services securely or not (if and where possible). Also, as a part of the consideration process when moving to cloud-based services, is someone double checking that HTTPS is an option for connectivity (if relevant) and does the service offer an option to encrypt any data you may be storing on its servers?

Additionally, what opportunities for additional encryption are being missed? For example, what data could be encrypted at rest (on hard drives, either network-based or in desktop and notebook PCs). A recent survey by Check Point Software Technologies revealed that "just 27 percent of respondents say their companies currently use hard disk encryption to protect sensitive data on corporate endpoints" and that "only 9 percent of businesses surveyed use encryption for removable storage devices, such as USB flash drives."

Google can only do so much to "force" its customers to compute securely. At some point, the responsibility for closing the remaining gap rests with IT personnel. If you haven't done your own encryption audit (both of your IT's security and your users' best practices), perhaps now is a good time to start.

How about you? Is secure access to Web services important to you and your company? Are you exercising all of your options to encrypt your data? Let me know by responding in the comments section below.

Dark Reading has published a new report on building a layered defense against unknown threats. Download the report now (registration required).

Also, I'm attending Black Hat. Maybe I'll see you there....

Register now for Black Hat DC, the largest and the most important security conference series in the world. It happens Jan. 31-Feb. 3, 2010, in Arlington, Va. Find out more and register.

David Berlind is the chief content officer of TechWeb and editor-in-chief of TechWeb.com. David likes to write about emerging tech, new and social media, mobile tech, and things that go wrong and welcomes comments, both for and against anything he writes. He can be reached at [email protected] and you also can find him on Twitter and other social networks (see the list below). David doesn't own any tech stocks. But, if he did, he'd probably buy some Salesforce.com and Amazon, given his belief in the principles of cloud computing.

Twitter: (@dberlind) My Facebook Page Flickr (davidberlind) YouTube (TechWebTV) FriendFeed (davidberlind) Del.icio.us (dberlind ) Me on LinkedIn Plaxo (davidberlind) Disqus (DavidBerlind) myGoogle Profile (David.Berlind)