Google Chrome
Google has warned of a change in approach to handling mixed content on pages opened via HTTPS. Previously, if there were components on open pages with HTTPS loaded without encryption (using the http: // protocol), a special prompt was displayed.
Now, for the next versions of the browser, it was decided to block the loading of these resources default. Therefore, it will be ensured that the pages opened via "https: //" contain only resources loaded through a secure communication channel.
It is observed that currently Chrome users open more than 90% of the sites using HTTPS. The presence of inserts downloaded without encryption creates a threat of security breach through the modification of insecure content in the presence of control over the communication channel (for example, when connecting via open Wi-Fi).
The mixed content indicator is recognized as ineffective and misleading, as it does not offer an unequivocal assessment of the security of the page.
Currently, the most dangerous types of mixed content, like scripts and iframes, are already blocked by default, but images, sound files and videos can still be downloaded via “http: //”.
By substituting images, the attacker can substitute cookie tracking actions, try to exploit vulnerabilities in image processors or commit a forgery, replacing the information presented in the image.
The introduction of the blockade is divided into several stages. In Chrome 79 (which is scheduled for December 10), A new setting will appear that will disable blocking of specific sites.
The specified settings will be applied to mixed content already blocked, such as scripts and iframes and will be activated through the menu that appears when you click the lock symbol, replacing the previously proposed indicator to disable the lock.
While for Chrome 80 (expected on February 4) a blocking scheme will be used for audio and video files, which involves automatic replacement from http: // to https: // which will keep it working if the problem resource is also available via HTTPS.
Images will continue to upload unchanged, but in case of downloading via http: // on https: // pages for the entire page, an indicator of an insecure connection will be initiated. For automatic replacement with https or block images, site developers will be able to use updated-insecure-requests-and block-all-content-mixed CSP properties.
The launch of Chrome 81, scheduled for March 17, will use AutoCorrect from http: // to https: // for mixed image downloads.
In addition, Google announced integration into one of the next versions of the Chome browser, a new component of passwordcheckup, previously developed as an external plugin.
The integration will lead to the appearance in the full-time password manager Chrome tools to analyze the reliability of the passwords used by the user. When you try to enter any site, the username and password will be verified against the database of compromised accounts with a warning in case of problems.
Validation takes place on a database that covers more than 4 billion compromised accounts that are presented in leaks of user databases. A warning will also be displayed when trying to use trivial passwords such as "abc123" (Google statistics 23% of Americans use these passwords), or when they use the same password on multiple sites.
To preserve confidentiality, when accessing the external API, only the first two bytes of the hash are transferred from the connection from the login and password (the Argon2 algorithm is used for the hash). The full hash is encrypted with a user-generated key.
The original hashes in the Google database are also additionally encrypted and only the first two bytes of the hash remain for indexing.
To guard against determining the content of the compromised accounts database by enumerating with random prefixes, the returned data is encrypted relative to the generated key based on the verified login and password link.
Source: https://security.googleblog.com