Posted by Chrome Root Program, Chrome Security Team

What is the Chrome Root Program?

A root program is one of the foundations for securing connections to websites. The Chrome Root Program was announced in September 2022. If you missed it, don’t worry – we’ll give you a quick summary below!

Chrome Root Program: TL;DR

Chrome uses digital certificates (often referred to as “certificates,” “HTTPS certificates,” or “server authentication certificates”) to ensure the connections it makes for its users are secure and private. Certificates are issued by trusted entities called “Certification Authorities” (CAs). The collection of digital certificates, CA systems, and other related online services is the foundation of HTTPS and is often referred to as the “Web PKI.”

Before issuing a certificate to a website, the CA must verify that the certificate requestor legitimately controls the domain whose name will be represented in the certificate. This process is often referred to as “domain validation” and there are several methods that can be used. For example, a CA can specify a random value to be placed on a website, and then perform a check to verify the value’s presence. Typically, domain validation practices must conform with a set of security requirements described in both industry-wide and browser-specific policies, like the CA/Browser Forum “Baseline Requirements” and the Chrome Root Program policy.

Upon connecting to a website, Chrome verifies that a recognized (i.e., trusted) CA issued its certificate, while also performing additional evaluations of the connection’s security properties (e.g., validating data from Certificate Transparency logs). Once Chrome determines that the certificate is valid, Chrome can use it to establish an encrypted connection to the website. Encrypted connections prevent attackers from being able to intercept (i.e., eavesdrop) or modify communication. In security speak, this is known as confidentiality and integrity.

The Chrome Root Program, led by members of the Chrome Security team, provides governance and security review to determine the set of CAs trusted by default in Chrome. This set of so-called “root certificates” is known at the Chrome Root Store.

How does the Chrome Root Program keep users safe?

The Chrome Root Program keeps users safe by ensuring the CAs Chrome trusts to validate domains are worthy of that trust. We do that by:

• administering policy and governance activities to manage the set of CAs trusted by default in Chrome,
• evaluating impact and corresponding security implications related to public security incident disclosures by participating CAs, and
• leading positive change to make the ecosystem more resilient.

Policy and Governance

The Chrome Root Program policy defines the minimum requirements a CA owner must meet for inclusion in the Chrome Root Store. It incorporates the industry-wide CA/Browser Forum Baseline Requirements and further adds security controls to improve Chrome user security.

The CA application process includes a public discussion phase, where members of the Web PKI community are free to raise well-founded, fact-based concerns related to an applicant on an open discussion forum.

We consider public discussion valuable because it:

• improves security, transparency, and interoperability, and
• highlights concerning behavior, practices, or ownership background information not readily available through public audits, policy reviews, or other application process inputs.

For a CA owner’s inclusion request to be accepted, it must clearly demonstrate that the value proposition for the security and privacy of Chrome’s end users exceeds the corresponding risk of inclusion.

Once a CA is trusted, it can issue certificates for any website on the internet; thus, each newly added CA represents an additional attack surface, and the Web PKI is only as safe as its weakest link. For example, in 2011 a compromised CA led to a large-scale attack on web users in Iran.

Incident Management

No CA is perfect. When a CA owner violates the Chrome Root Program policy – or experiences any other situation that affects the CA’s integrity, trustworthiness, or compatibility – we call it an incident. Incidents can happen. They are an expected part of building a secure Web PKI. All the same, incidents represent opportunities to improve practices, systems, and understanding. Our program is committed to continuous improvement and participates in a public Web PKI incident management process.

When incidents occur, we expect CA owners to identify the root cause and remediate it to help prevent similar incidents from happening again. CA owners record the incident in a report that the Chrome Root Program and the public can review, which encourages an understanding of all contributing factors to reduce the probability of its reoccurrence in the Web PKI.

The Chrome Root Program prioritizes the security and privacy of its users and is unwilling to compromise on these values. In rare cases, incidents may result in the Chrome Root Program losing confidence in the CA owner’s ability to operate securely and reliably. This may happen when there is evidence of a CA owner:

• knowingly violating requirements or obfuscating incidents,
• demonstrating sustained patterns of failure, untimely and opaque communications, or an unwillingness to improve elements that are critical to security, or
• performing other actions that negatively impact or otherwise degrade the security of the Web.

In these cases, Chrome may distrust a CA – that is, remove the CA from the Chrome Root Store. Depending on the circumstance, Chrome may also block the certificate with a non-bypassable error page.

The above cases are only illustrative, and considerations for CA distrust are not limited to these examples. The Chrome Root Program may remove certificates from the Chrome Root Store, as it deems appropriate and at its sole discretion, to enhance security and promote interoperability in Chrome.

Positive Ecosystem Change

The Chrome Root Program collaborates with members of the Web PKI ecosystem in various forums (e.g., the CA/Browser Forum) and committees (e.g., the CCADB Steering Committee). We share best practices, advocate for and develop new standards to promote user security, and seek ecosystem participant feedback on proposed initiatives. Collectively, ecosystem participants contributing to these working groups are protecting the Web.

In June 2022, we announced the “Moving Forward, Together” initiative that shared our vision of the future Web PKI that includes modern, reliable, agile, and purpose-driven architectures with a focus on automation, simplicity, and security. The initiative represents the goals and priorities of the Chrome Root Program and reinforces our commitment to working alongside CA owners to make the Web a safer place.

Some of our current priorities include:

• reducing misissuance of certificates that do not comply with the Baseline Requirements, a CA’s own policies, or the Chrome Root Program policy,
• increasing accountability and ecosystem integrity with high-quality, independent audits,
• automating certificate issuance and strengthening the domain validation process, and
• preparing for a “post-quantum” world.

We believe implementing proposals related to these priorities will help manage risk and make the Web a safer place for everyone.

However, as the name suggests, we can only realize these opportunities to improve with the collective contributions of the community. We understand CAs to be an essential element of the Web PKI, and we are encouraged by continued feedback and participation from existing and future CA owners in our program.

The Chrome Root Program is committed to openness and transparency, and we are optimistic we can achieve this shared vision. If you’re interested in seeing what new initiatives are being explored by the Chrome Root Program to keep Chrome users safe – you can learn more here.

Don’t download software from non-reputable websites and sketchy links – you might be in for more than you bargained for

The post The real cost of a free lunch – Week in security with Tony Anscombe appeared first on WeLiveSecurity

Posted by Sarah Jacobus, Vulnerability Rewards Team

As technology continues to advance, so do efforts by cybercriminals who look to exploit vulnerabilities in software and devices. This is why at Google and Android, security is a top priority, and we are constantly working to make our products more secure. One way we do this is through our Vulnerability Reward Programs (VRP), which incentivize security researchers to find and report vulnerabilities in our operating system and devices.

We are pleased to announce that we are implementing a new quality rating system for security vulnerability reports to encourage more security research in higher impact areas of our products and ensure the security of our users. This system will rate vulnerability reports as High, Medium, or Low quality based on the level of detail provided in the report. We believe that this new system will encourage researchers to provide more detailed reports, which will help us address reported issues more quickly and enable researchers to receive higher bounty rewards.

The highest quality and most critical vulnerabilities are now eligible for larger rewards of up to $15,000!

There are a few key elements we are looking for:

Accurate and detailed description: A report should clearly and accurately describe the vulnerability, including the device name and version. The description should be detailed enough to easily understand the issue and begin working on a fix.

Root cause analysis: A report should include a full root cause analysis that describes why the issue is occurring and what Android source code should be patched to fix it. This analysis should be thorough and provide enough information to understand the underlying cause of the vulnerability.

Proof-of-concept: A report should include a proof-of-concept that effectively demonstrates the vulnerability. This can include video recordings, debugger output, or other relevant information. The proof-of-concept should be of high quality and include the minimum amount of code possible to demonstrate the issue.

Reproducibility: A report should include a step-by-step explanation of how to reproduce the vulnerability on an eligible device running the latest version. This information should be clear and concise and should allow our engineers to easily reproduce the issue and begin working on a fix.

Evidence of reachability: Finally, a report should include evidence or analysis that demonstrates the type of issue and the level of access or execution achieved.

*Note: This criteria may change over time. For the most up to date information, please refer to our public rules page.

Additionally, starting March 15th, 2023, Android will no longer assign Common Vulnerabilities and Exposures (CVEs) to most moderate severity issues. CVEs will continue to be assigned to critical and high severity vulnerabilities.

We believe that incentivizing researchers to provide high-quality reports will benefit both the broader security community and our ability to take action. We look forward to continuing to work with researchers to make the Android ecosystem more secure.

If you would like more information on the Android & Google Device Vulnerability Reward Program, please visit our public rules page to learn more!

Why do people still download files from sketchy places and get compromised as a result?

The post You may not care where you download software from, but malware does appeared first on WeLiveSecurity