Vulnerabilities / Threats

9/15/2016
05:00 PM
Connect Directly
Facebook
Twitter
RSS
E-Mail
50%
50%

Google Chrome To Flag Non-HTTPS Logins, Credit Card Info 'Not Secure'

The move is part of a larger Google push to lock down Web traffic using encryption between the browser and Web server.

Google's Chrome 56 browser as of January 2017 will flag as "not secure" any non-HTTPS sites that transmit password and credit-card information.

Hypertext Transport Protocol Secure (HTTPS) combines the Web's lingua franca hypertext transport protocol with encryption from Transport Layer Security (TLS) or Secure Sockets Layer (SSL) to guarantee the authenticity of a website, protect communication between client and server, and obviate man-in-the-middle attacks.

Currently, Chrome delivers HTTP connections with its neutral indicator, which Google says doesn't reflect the real lack of security in HTTP environments. "When you load a website over HTTP, someone else on the network can look at or modify the site before it gets to you," Chrome Security Team member Emily Schechter wrote in a Sept. 8 blog post. HTTPS usage is on the upswing and that more than half of Chrome desktop page loads are now served over HTTPS, she wrote.

Google Chrome is the most widely used browser in the world, with approximately 54% of the combined desktop and mobile user segments as of August, according to Net Market Share.

Google is also a member of the Let's Encrypt consortium, a certificate authority that aims to lock down the Web via HTTPS. The certificates are available for free and are easily configured, according to the Internet Security Research Group, which provides the certificate service. 

Without giving any timeframes, the vendor says it will also label HTTP pages "not secure" in Incognito browsing mode, where users may believe they have greater privacy than they actually do.

"Eventually, we plan to label all HTTP pages as non-secure, and change the HTTP security indicator to the red triangle that we use for broken HTTPS," Google says.

It's unclear how much this flagging will affect user behavior or increase online security, since as Google itself acknowledges, users don't view the lack of a green-lock secure icon in their browser bar as a warning. Users also get saturated by frequent security warnings.

Generally, when the Chrome team makes a user-visible security and/or privacy change, they do their homework well in advance of shipping, according to Jeremiah Grossman, chief of security strategy for SentinelOne.

"Google likely has solid data that this change will have the necessarily motivational impact to get more website owners to switch to HTTPS," Grossman says. "No Website owner wants to have their visitors presented with some type of scary warning about using their website, so this encourages them to upgrade."

Where does that leave makers of other popular Web browsers? Mozilla says that its Firefox Developer Edition has had similar security warnings since January, "displaying a struck-through lock icon when there is a password field on a non-secure site," according to a Mozilla spokesperson. As a result, Mozilla reports a 20% reduction in presentation of password fields on non-secure pages since January, the spokesperson adds.

Apple did not respond to a request for more information about securing its Safari browser.

Related Content:

 

Terry Sweeney is a Los Angeles-based writer and editor who has covered technology, networking, and security for more than 20 years. He was part of the team that started Dark Reading and has been a contributor to The Washington Post, Crain's New York Business, Red Herring, ... View Full Bio

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
White House Cybersecurity Strategy at a Crossroads
Kelly Jackson Higgins, Executive Editor at Dark Reading,  7/17/2018
Lessons from My Strange Journey into InfoSec
Lysa Myers, Security Researcher, ESET,  7/12/2018
What's Cooking With Caleb Sima
Kelly Jackson Higgins, Executive Editor at Dark Reading,  7/12/2018
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2018-14339
PUBLISHED: 2018-07-19
In Wireshark 2.6.0 to 2.6.1, 2.4.0 to 2.4.7, and 2.2.0 to 2.2.15, the MMSE dissector could go into an infinite loop. This was addressed in epan/proto.c by adding offset and length validation.
CVE-2018-14340
PUBLISHED: 2018-07-19
In Wireshark 2.6.0 to 2.6.1, 2.4.0 to 2.4.7, and 2.2.0 to 2.2.15, dissectors that support zlib decompression could crash. This was addressed in epan/tvbuff_zlib.c by rejecting negative lengths to avoid a buffer over-read.
CVE-2018-14341
PUBLISHED: 2018-07-19
In Wireshark 2.6.0 to 2.6.1, 2.4.0 to 2.4.7, and 2.2.0 to 2.2.15, the DICOM dissector could go into a large or infinite loop. This was addressed in epan/dissectors/packet-dcm.c by preventing an offset overflow.
CVE-2018-14342
PUBLISHED: 2018-07-19
In Wireshark 2.6.0 to 2.6.1, 2.4.0 to 2.4.7, and 2.2.0 to 2.2.15, the BGP protocol dissector could go into a large loop. This was addressed in epan/dissectors/packet-bgp.c by validating Path Attribute lengths.
CVE-2018-14343
PUBLISHED: 2018-07-19
In Wireshark 2.6.0 to 2.6.1, 2.4.0 to 2.4.7, and 2.2.0 to 2.2.15, the ASN.1 BER dissector could crash. This was addressed in epan/dissectors/packet-ber.c by ensuring that length values do not exceed the maximum signed integer.