Shulou(Shulou.com)06/01 Report--

Hilbert graph of hash algorithm (provided by Ian Boyd) the official Google blog announced that the security instructions for SHA-1 certificates will be gradually reduced in Chrome browsers. But what is interesting is that Google.com currently uses a certificate signed by SHA-1, but the certificate will expire within 3 months, and Google will use a certificate signed by SHA-2 from 2015. At present, the SHA-1 algorithm has not found a serious weakness, but the cost of forging certificates is getting lower and lower.

Overview

Most secure websites are using an insecure algorithm, and Google has just declared that this will be a long-term emergency. About 90 per cent of websites encrypted with SSL use the SHA-1 algorithm to prevent their identities from being impersonated. When you visit the URL, make sure that you are visiting the authentic Facebook instead of sending your password to the person who uses it. Unfortunately, however, the SHA-1 algorithm is very fragile, as it has been for a long time. The security of the algorithm decreases year by year, but it is still widely used on the Internet. Its replacement, SHA-2, is sturdy enough to be widely supported. Google recently announced that if you are using Chrome, you will notice that browser warnings for a large number of secure websites are constantly changing.

The first warnings of changes in Chrome for sites with certificates valid until 2017 will appear before Christmas and become more stringent over the next six months.

In the end, even sites with SHA-1 certificates valid for 2016 will be given a warning. By launching a series of warnings, Google is declaring a long-term emergency and urging people to update their sites before things get worse. This is a good thing, because it's time for SHA-1 to retire from history, and people don't pay enough attention to the potential risks of SHA-1. If you have a website that uses SSL, you can use the SHA-1 test gadget I created to test your site, which will tell you what to do. Even if you don't have a website, I still recommend you to read it. In the following blog post, I will explain how SSL and SHA-1 work together on the site, why it is as urgent as Google said, and what the browser is taking. Equally important, the security community needs to make the certificate replacement process less painful and cumbersome, because the security upgrade of the website does not have to be so urgent and hasty. FreeBuf Science Popularization: secure hashing algorithm and SHA-1 secure hashing algorithm (English: Secure Hash Algorithm) is an algorithm that can calculate a fixed-length string (also known as message digest) corresponding to a digital message. And if the input messages are different, they have a high probability of corresponding to different strings; SHA is one of the five secure hashing algorithms certified by FIPS. The reason why these algorithms are called "security" is based on the following two points (according to official standards):

1. It is very difficult to deduce the original input message from the message digest.

2. It is also difficult to find two different groups of messages corresponding to the same message digest. There is a high chance that any change to the input message will result in a very different message summary. SHA (Secure Hash Algorithm) is a series of cryptographic hash functions designed by the National Security Agency (NSA) and issued by the National Institute of Standards and Technology (NIST).

Introduction to SHA-1

To understand why replacing SHA-1 is so important, first put yourself from a browser's point of view. When you visit a website that is used, the website presents a file (similar to our *) to the browser, that is, an SSL certificate. This certificate is used to do two things: encrypt the connection to the site and verify the true identity of the site. Any certificate can be used to encrypt the connection. But in order to verify that you are visiting a real Facebook (not a fake), your browser must somehow determine whether the certificate is trusted, and then show you a small green lock. To complete the verification, your browser finds out whether the website's certificate is issued by an authority (certificate issuing authority, "CA" for short). CA usually issues certificate files to websites for a fee. Your browser trusts certificates created and guaranteed by more than 56 CA (root CA), such as Verisign, GoDaddy, U.S. Department of Defense, and thousands of intermediate CA authorized by 56 root CA. As you might expect, this is a very flawed system, but it is the actual situation.

The content displayed when you click on the green lock in front of the URL in Chrome the CA of this site at that time was Comodo and was purchased through Namecheap. When a site's SSL certificate claims to have been issued to the site by a CA, your browser needs to do another key test: does the certificate itself prove this fact? In general, the Internet proves the facts through mathematics. When a certificate is issued, CA provides the certificate by signing the certificate with a private key. To some extent, only the real CA can complete the signature (unless the private key is lost, , I often lose the key), and the browser can verify the signature. But CA doesn't actually sign the original certificate: it first runs "one-way hashing" algorithms (such as MD5, SHA-1, SHA-256) to compress the certificate into a unique field.

The one-way hashing algorithm for certificate fragments in Chrome browsers can compress information: for example, if you run the 3.2MB version of War and Peace through SHA-1, you will get: baeb2c3a70c85d44947c1b92b448655273ce22bbMD5file.com

The result of (an interesting online hash calculator) is similar to that of SHA-1, where an one-way hash algorithm is used to produce a unique irreversible data block (originally slug, meaning warhead). You can no longer reverse the content of "War and Peace" from aeb2c3a70c85d44947c1b92b448655273ce22bb (that is, hash operations are irreversible). Equally important, no other file can produce the same data block (that is, the fingerprint is unique). Even a small part of the content modification will lead to great changes in the results of the SHA-1 operation, so it is difficult to find the relevance before and after. If two files go through the same hash operation to generate the same value, this phenomenon is called a "collision". Collision is theoretically possible, but the probability is so low that it is considered impossible in reality. When the browser encounters a certificate, it calculates the SHA- 1 value of the certificate information and compares it with the original SHA-1 value specified by the certificate. Because of the uniqueness of the SHA-1 result, if the two values are the same, the browser is convinced that the certificate provided is the same as the certificate issued by CA and has not been tampered with. If you design a certificate, you can collide with the certificate of the target site, and then trick CA into issuing the certificate to you. Eventually, you can use this certificate to impersonate the target site, and even browsers can't tell the authenticity from the fake. Details: if you want to know the details of the signature algorithm and SSL certificate, Joshua Davis has an extremely detailed explanation, the link is as follows:

Http://commandlinefanatic.com/cgi-bin/showarticle.cgi?article=art012

SHA-1

In 2005, cryptographers proved that SHA-1 cracked 2000 times faster than expected. But cracking is still extremely difficult and expensive. But as computers become faster and cheaper, it's only a matter of time before we stop using SHA-1 on the Internet. Later, the Internet continued to use SHA-1. In 2012, Jesse Walker wrote an assessment of the cost of forging an SHA-1 certificate. The assessment refers to the price of Amazon's Web service and Moore's Law. At the time, Walker estimated that a SHA-1 collision would cost $2000000 in 2012, $700000 in 2015, $173000 in 2018 and $43000 in 2021. Based on these figures, Schnell suggests that criminal syndicates will be able to forge certificates by 2018, and scientific research institutions will have this ability by 2021. Walker's assessment and Schnell's inference are widely cited in the planning and debate about the replacement of SHA-1. A group made up of mainstream CA, the CA Security Council (CA Security Council), recently used Walker and Schnell's conclusions to complain about Google's timetable. CA regards the assessment results as a sharp weapon of rebuttal, saying that "this kind of violence will not actually happen until 2018". I find that the position taken by the CA Security Council is almost as childish as a cartoon. They just seem to be covering up the problem because they are well aware of the inconvenience caused by the accelerated replacement process (to put it bluntly, time and money). Walker and Schnell's assessment was before the Snowden incident, before people figured out that the government was also the enemy. Based on their assessment, it costs less than $2000.000 to forge a certificate in 2014, a sum that many A-list stars can afford. How can we be sure that they will do so? Because they already did. Anyway, giving me so much money, I didn't do such a stupid thing.

Kaspersky Lab monitors computers that have been infected with the flame virus. Researchers discovered the famous flame virus in 2012. The Washington Post reported that this was a cooperation between the United States and Israel to gather intelligence from Iran and obstruct Iran's nuclear weapons program. A leaked NSA document seems to confirm this view. The Flame virus relies on a forged SSL certificate to achieve the collision of a MD5 (SHA-1 's predecessor). Worryingly, it used a method that was little known at the time, even though MD5 had been studied for years. The hint of this event is that we should assume that the most dangerous vulnerabilities are unknown. There is an interesting story about MD5. Because, like SHA-1, MD5 was discovered to be vulnerable a long time ago, and like SHA-1, the time it takes to remove MD5 from the Internet is surprising. In 1995, MD5 was first revealed to be theoretically vulnerable and became more and more vulnerable over time, but until 2008, MD5 was still used by some CA.

Viewing through chrome://settings/certificates in Chrome although this is a critical situation, Chrome still could not remove its support for MD5 until 2011-16 years have passed since MD5 was first proved to be unreliable. There is a unique challenge in changing signature algorithms on the Internet: anyone's certificate can be forged as long as the browser supports SHA-1. You can use a SHA-1-signed forged certificate to impersonate a SHA-2-signed certificate, because the browser will only look at the SHA-1-signed forged certificate and does not know that there is a "real" certificate or that the certificate should be signed with SHA-2. (in short, in order to impersonate the certificate of the target site, the information of the forged certificate is exactly the same as the certificate of the target site, except that the signature algorithm is changed to SHA-1.) in other words, the only way to prevent the forgery of certificates using SHA-1 is for the browser to remove support for SHA-1.

Response of each browser

Microsoft is the first to announce plans to deactivate SHA-1, and Windows and IE will no longer trust SHA-1 certificates after 2016. Mozilla made the same decision. Although Microsoft and Mozilla made it clear to users that the problem existed, neither indicated that the user interface would be changed. On the other hand, Google recently made an explosive announcement that because SHA- 1 is too fragile, Chrome browsers will display a warning to users: "We plan to use the Https security indicator in Chrome to emphasize the fact that SHA-1 does not meet the original design requirements." We are taking a quantifiable approach, gradually downgrading the security indicator and gradually advancing the schedule. "two weeks ago, Google's Ryan Sleevi first announced the expected strategy of Chrome. It is recommended that you read the complete discussion process, the specific link is as follows: https://groups.google.com/a/chromium.org/d/msg/security-dev/2-R4XziFc7A/NDI8cOwMGRQJ you will find a lot of CA and large-scale website operators show up and try to debate with Ryan Sleevi because Ryan Sleevi tells them to stop issuing fragile certificates now, not until next year. This is a bold move launched by Google, which is also accompanied by huge risks. The main reason why the browser signature removal algorithm is so difficult is that when the browser tells the user that an important site is at risk, the user thinks there is something wrong with the browser and then changes the browser. Google seems to be betting that users trust Chrome's security and like Chrome enough to accept the inconvenience caused by the plan. After all, it is the first one to eat crabs, salute to Google! Opera expressed support for Google's plan. The Safari team is watching (commonly known as "onlookers") but does not take a stand.

Guidance and suggestion

To help with the migration, I set up a small site, www.shaaaaaaaaaaaaa.com, to check if your site uses SHA-1 and if it needs to be updated.

The number of the letter An is an unpredictable large prime (why the author chose a number puzzles me, maybe you can tell me the answer! You need to submit a new certificate request and ask your CA to issue a new certificate using SHA-2. Use your existing private key: openssl req-new-sha256-key your-private.key-out your-domain.csr where the-sha256 flag will use the SHA-2 signature CSR, but CA can decide whether to issue you a certificate signed with SHA-2. I have been following the problems and solutions related to obtaining SHA-2 certificates from different CA. If the problems you encounter are not mentioned on the website, please give feedback here and I will update the website in time. You may update all SHA-1 intermediate certificates because they also need to be verified by digital signatures. This means that you have to track whether your CA issued an SHA-2 intermediate certificate and where it was sent. I have also been tracking the location of SHA-2 intermediate certificates issued by different CA. If you find something not mentioned on the site, or if your CA does not have an intermediate certificate, please give feedback here. If you have a site but other companies control the certificate, you can send an email to their customer service. Send Google announced the connection and ask about their schedule. Of course, I also need some help, if you like, check the open questions on the website to help me. SHA-1 root certificates: you don't have to worry about the SHA-1 root certificates that come with your browser, because their integrity is not verified by digital signatures.

Conclusion

This plan to retire SHA-1 should have been started a long time ago. All the troubles caused by the escalating pressure should be directed to CA, rather than making Google a scapegoat, because CA has long been unable to take effective measures. For individuals, obtaining a certificate should be as easy as buying a domain name, installing it should be as easy as opening a website, and replacing it can be automated. These ideas provide some very clear business opportunities and the need for open source tools. For organizations, frequent certificate rotation is a priority in the design and updating of their infrastructure. Organizations that have done well in this work should speak widely and share the results of their work. At the same time, website operators should update their certificates and take advantage of emergencies that do not exist at the Heartbleed level to re-examine their SSL configurations and turn on configurations such as "forward secrecy".

This article comes from 87 Technology Network (http://www.qu87.com/), original address: http://www.qu87.com/news/?26859.html

87 Technology Network Technology

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.