Risk
1/14/2010
12:36 PM
David Berlind
David Berlind
Commentary
Connect Directly
Facebook
Google+
LinkedIn
Twitter
RSS
E-Mail
50%
50%

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 th

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...

Gmail Defaults To HTTPS

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 dberlind@techweb.com 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)

Comment  | 
Print  | 
More Insights
Register for Dark Reading Newsletters
White Papers
Flash Poll
Current Issue
Cartoon
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2014-0103
Published: 2014-07-29
WebAccess in Zarafa before 7.1.10 and WebApp before 1.6 stores credentials in cleartext, which allows local Apache users to obtain sensitive information by reading the PHP session files.

CVE-2014-0475
Published: 2014-07-29
Multiple directory traversal vulnerabilities in GNU C Library (aka glibc or libc6) before 2.20 allow context-dependent attackers to bypass ForceCommand restrictions and possibly have other unspecified impact via a .. (dot dot) in a (1) LC_*, (2) LANG, or other locale environment variable.

CVE-2014-2226
Published: 2014-07-29
Ubiquiti UniFi Controller before 3.2.1 logs the administrative password hash in syslog messages, which allows man-in-the-middle attackers to obtains sensitive information via unspecified vectors.

CVE-2014-3541
Published: 2014-07-29
The Repositories component in Moodle through 2.3.11, 2.4.x before 2.4.11, 2.5.x before 2.5.7, 2.6.x before 2.6.4, and 2.7.x before 2.7.1 allows remote attackers to conduct PHP object injection attacks and execute arbitrary code via serialized data associated with an add-on.

CVE-2014-3542
Published: 2014-07-29
mod/lti/service.php in Moodle through 2.3.11, 2.4.x before 2.4.11, 2.5.x before 2.5.7, 2.6.x before 2.6.4, and 2.7.x before 2.7.1 allows remote attackers to read arbitrary files via an XML external entity declaration in conjunction with an entity reference, related to an XML External Entity (XXE) is...

Best of the Web
Dark Reading Radio