https://googledata.org Everything Google: News, Products, Services, Content, Culture Tue, 25 Oct 2011 23:56:45 +0000 en hourly 1 http://wordpress.org/?v=3.2.1 https://googledata.org/google-online-security/an-update-on-attempted-man-in-the-middle-attacks/?utm_source=rss&utm_medium=rss&utm_campaign=an-update-on-attempted-man-in-the-middle-attacks https://googledata.org/google-online-security/an-update-on-attempted-man-in-the-middle-attacks/#comments Tue, 30 Aug 2011 03:59:00 +0000 Chris Evans https://googledata.org/?guid=9d5153fbab7044a5e77ddc56d3c2fb6e Posted by Heather Adkins, Information Security Manager

Today we received reports of attempted SSL man-in-the-middle (MITM) attacks against Google users, whereby someone tried to get between them and encrypted Google services. The people affected were primarily located in Iran. The attacker used a fraudulent SSL certificate issued by DigiNotar, a root certificate authority that should not issue certificates for Google (and has since revoked it).

Google Chrome users were protected from this attack because Chrome was able to detect the fraudulent certificate.

To further protect the safety and privacy of our users, we plan to disable the DigiNotar certificate authority in Chrome while investigations continue. Mozilla also moved quickly to protect its users. This means that Chrome and Firefox users will receive alerts if they try to visit websites that use DigiNotar certificates. Microsoft also has taken prompt action.

To help deter unwanted surveillance, we recommend that users, especially those in Iran, keep their web browsers and operating systems up to date and pay attention to web browser security warnings.

Update Aug 30: Added information about Microsoft's response.

Update Sept 3: Our top priority is to protect the privacy and security of our users. Based on the findings and decision of the Dutch government, as well as conversations with other browser makers, we have decided to reject all of the Certificate Authorities operated by DigiNotar. We encourage DigiNotar to provide a complete analysis of the situation.

]]> https://googledata.org/google-online-security/an-update-on-attempted-man-in-the-middle-attacks/feed/ 0 https://googledata.org/uncategorized/trying-to-end-mixed-scripting-vulnerabilities/?utm_source=rss&utm_medium=rss&utm_campaign=trying-to-end-mixed-scripting-vulnerabilities https://googledata.org/uncategorized/trying-to-end-mixed-scripting-vulnerabilities/#comments Thu, 16 Jun 2011 18:37:00 +0000 Chris Evans https://googledata.org/?guid=987a0330048c18858459b4a88294cb99 Posted by Chris Evans and Tom Sepez, Google Chrome Security Team

A “mixed scripting” vulnerability is caused when a page served over HTTPS loads a script, CSS, or plug-in resource over HTTP. A man-in-the-middle attacker (such as someone on the same wireless network) can typically intercept the HTTP resource load and gain full access to the website loading the resource. It’s often as bad as if the web page hadn’t used HTTPS at all.

A less severe but similar problem -- let’s call it a “mixed display” vulnerability -- is caused when a page served over HTTPS loads an image, iFrame, or font over HTTP. A man-in-the-middle attacker can again intercept the HTTP resource load but normally can only affect the appearance of the page.

Browsers have long used different indicators, modal dialogs, block options or even click-throughs to indicate these conditions to users. If a page on your website has a mixed scripting issue, Chromium will currently indicate it like this in the URL bar:



And for a mixed display issue:



If any of the HTTPS pages on your website show the cross-out red https, there are good reasons to investigate promptly:

• Your website won’t work as well in other modern browsers (such as IE9 or FF4) due to click-throughs and ugly modal dialogs.
• You may have a security vulnerability that could compromise the entire HTTPS connection.

As of the first Chromium 14 canary release (14.0.785.0), we are trialing blocking mixed scripting conditions by default. We’ll be carefully listening to feedback; please leave it on this Chromium bug.

We also added an infobar that shows when a script is being blocked:

As a user, you can choose to reload the website without the block applied. Ideally, in the longer term, the infobar will not have the option for the user to bypass it. Our experience shows that some subset of users will attempt to “click through” even the scariest of warnings -- despite the hazards that can follow.

Tools that can help website owners
If Chromium’s UI shows any mixed content issues on your site, you can try to use a couple of our developer tools to locate the problem. A useful message is typically logged to the JavaScript console (Menu -> Tools -> JavaScript Console):

You can also reload the page with the “Network” tab active and look for requests that were issued over the http:// protocol. It’s worth noting that the entire origin is poisoned when mixed scripting occurs in it, so you’ll want to look at the console for all tabs that reference the indicated origin. To clear the error, all tabs that reference the poisoned origin need to be closed. For particularly tough cases where it’s not clear how the origin became poisoned, you can also enable debugging to the command-line console to see the relevant warning message.

The latest Chromium 13 dev channel build (13.0.782.10) has a command line flag: --no-running-insecure-content. We recommend that website owners and advanced users run with this flag, so we can all help mop up errant sites. (We also have the flag --no-displaying-insecure-content for the less serious class of mixed content issues; there are no plans to block this by default in Chromium 14).

The Chromium 14 release will come with an inverse flag: --allow-running-insecure-content, as a convenience for users and admins who have internal applications without immediate fixes for these errors.

Thanks for helping us push website security forward as a community. Until this class of bug is stamped out, Chromium has your back.

]]> https://googledata.org/uncategorized/trying-to-end-mixed-scripting-vulnerabilities/feed/ 0