WorryFree Computers   »   [go: up one dir, main page]

Posted by Ryan Sleevi, Software Engineer

This post updates our previous notification of a misissued certificate for google.com

Following our notification, Symantec published a report in response to our inquiries and disclosed that 23 test certificates had been issued without the domain owner’s knowledge covering five organizations, including Google and Opera.

However, we were still able to find several more questionable certificates using only the Certificate Transparency logs and a few minutes of work. We shared these results with other root store operators on October 6th, to allow them to independently assess and verify our research.

Symantec performed another audit and, on October 12th, announced that they had found an additional 164 certificates over 76 domains and 2,458 certificates issued for domains that were never registered.

 It’s obviously concerning that a CA would have such a long-running issue and that they would be unable to assess its scope after being alerted to it and conducting an audit. Therefore we are firstly going to require that as of June 1st, 2016, all certificates issued by Symantec itself will be required to support Certificate Transparency. In this case, logging of non-EV certificates would have provided significantly greater insight into the problem and may have allowed the problem to be detected sooner.

 After this date, certificates newly issued by Symantec that do not conform to the Chromium Certificate Transparency policy may result in interstitials or other problems when used in Google products.

 More immediately, we are requesting of Symantec that they further update their public incident report with:
  1. A post-mortem analysis that details why they did not detect the additional certificates that we found.
  2. Details of each of the failures to uphold the relevant Baseline Requirements and EV Guidelines and what they believe the individual root cause was for each failure.
We are also requesting that Symantec provide us with a detailed set of steps they will take to correct and prevent each of the identified failures, as well as a timeline for when they expect to complete such work. Symantec may consider this latter information to be confidential and so we are not requesting that this be made public.

Following the implementation of these corrective steps, we expect Symantec to undergo a Point-in-time Readiness Assessment and a third-party security audit. The point-in-time assessment will establish Symantec’s conformance to each of these standards:
  • WebTrust Principles and Criteria for Certification Authorities
  • WebTrust Principles and Criteria for Certification Authorities – SSL Baseline with Network Security
  • WebTrust Principles and Criteria for Certification Authorities – Extended Validation SSL

The third-party security audit must assess: 
  • The veracity of Symantec’s claims that at no time private keys were exposed to Symantec employees by the tool.
  • That Symantec employees could not use the tool in question to obtain certificates for which the employee controlled the private key.
  • That Symantec’s audit logging mechanism is reasonably protected from modification, deletion, or tampering, as described in Section 5.4.4 of their CPS.

We may take further action as additional information becomes available to us.

Posted by 
Adrienne Porter Felt, Chrome Security Engineer and Warning Wizard
Emily Schechter, Safe Browsing Program Manager and Menace to Malware
Ke Wang, Safe Browsing Engineer and Developer of Defense

You’re browsing the web, checking out the latest news on your favorite band, when suddenly you see a red warning screen: “The site ahead contains malware.” These warnings aren’t new—since 2006, Google Safe Browsing has shown them when you navigate to an unsafe site. The warnings protect you from harms caused by unsafe sites, such as malware infections and phishing attacks. But it hasn’t always been clear why a specific website triggers a warning, and you may want to learn more.

To demystify these warnings, we’re launching a Site Status section in the Transparency Report. The next time you come across a Safe Browsing warning, you can search for the blocked website in the Transparency Report to learn why it’s been flagged by our systems.

The new Site Status section of the Transparency Report replaces our previous Safe Browsing diagnostic page. It includes a clearer interface and simpler explanations of the issues, such as details for sites that host unwanted software. We’ve added it to the Transparency Report so that the Safe Browsing section of the report is a one-stop shop for information to help you understand what Safe Browsing is and how it works.

If a favorite website shows up as “dangerous,” it’s often due to user-uploaded bad content or a temporary malware infection. The Site Status will return to normal once the webmaster has cleaned up the website. To help speed up this process, we automatically give the webmaster a heads-up about the problem via Search Console; if you use Google Analytics, we’ll also warn you there if your site has malware on it. (Webmasters, check the help center to learn how to remove malware from your websites.)

We’re constantly working to keep users safe and informed online. Visit the updated Site Status section in the Transparency Report to experience it yourself.

Posted by Lucas Garron and Chris Palmer, Chrome security team

Sometimes, websites try to use HTTPS to be secure and get it mostly right, but they have minor errors. Until recently, Chrome marked this security state with a yellow “caution triangle” badge on the page security icon in the URL bar.

Starting with version 46, Chrome will mark the “HTTPS with Minor Errors” state using the same neutral page icon as HTTP pages.
There are two reasons for this:
  1. This change is a better visual indication of the security state of the page relative to HTTP.
  2. Chrome users will have fewer security states to learn.

(Not) Warning About Mixed Content

This change will mainly affect HTTPS pages that contain certain mixed content, such as HTTP images.

Site operators face a dilemma: Switching an HTTP site to HTTPS can initially result in mixed content, which is undesirable in the long term but important for debugging the migration. During this process the site may not be fully secured, but it will usually not be less secure than before.

Removing the yellow “caution triangle” badge means that most users will not perceive a warning on mixed content pages during such a migration. We hope that this will encourage site operators to switch to HTTPS sooner rather than later.

Fewer Security States

This change will reduce the number of page security states in Chrome from four to three.

We have to strike a balance: representing the security state of a webpage as accurately as possible, while making sure users are not overwhelmed with too many possible states and details. We’ve come to understand that our yellow “caution triangle” badge can be confusing when compared to the HTTP page icon, and we believe that it is better not to emphasize the difference in security between these two states to most users. For developers and other interested users, it will still be possible to tell the difference by checking whether the URL begins with “https://”.

In the long term, we hope that most sites on the internet will become secure, and we plan to reduce the icon to just two states: secure and not secure. The change announced in this post is a small step in that direction.