SHA-1 to SHA-2 Migration Guide Web-application attacks represented 40 percent of breaches in 2015. Cryptographic and server-side vulnerabilities provide opportunities for cyber criminals to carry out ransomware attacks that can cost enterprises millions of dollars in remediation. According to Cisco, more than 60 percent of Internet traffic uses TLS for encryption. And close to 10 percent of malware used TLS to hide in the encrypted traffic. This number will increase as the overall use of encryption in traffic increases. The SHA-1 hashing algorithm, which is weak against advances in cryptographic attacks, is being deprecated and must be replaced with SHA-2 as soon as possible.
Why do we need to migrate from SHA-1 to SHA-2? SHA-1 has been vulnerable for years The first weakness in SHA-1 was documented in 2002, but the weakness could not be exploited then as the processing power required to mount an attack was too expensive at that time. Since 2013, companies such as Microsoft and Google have been endorsing the deprecation of SHA-1 certificates from their trust stores. Earlier this year, security researchers from Google and CWI successfully generated a collision attack against SHA-1 that produced two different PDF files with the same SHA-1 signature. As a result, the move to SHA-2 has become urgent. Certificates on both internal and external servers need to be migrated to SHA-2 as soon as possible. This affects all types of certificates, regardless of your validation method. 2015 2016 2017 Application having SHA-1 signed certificates will be treated as secure, but with minor errors Certificate Authorities will stop issuing SHA1-based certificates SHA-1 certificates will no longer be accepted even if they have not yet expired Figure 1: Year based SHA-1 impact SHA-2 is significantly stronger In 2002, SHA-2 became the new recommended hashing standard. The encryption hash used in SHA-2 is longer, significantly stronger, and not subject to the same type of vulnerabilities that SHA-1 is. This also means that decrypting (or hacking) SHA-2 certificates requires much more logic and computing power than it does for SHA-1. Although SHA-2 is constantly attacked, its weaknesses are minor, and in crypto-speak, it's considered strong and far superior to SHA-1. 2
SHA-1 security warnings are bad for business Beginning with version 56, Google Chrome will mark all SHA-1 signed HTTPS certificates as unsafe. Other browsers plan to do the same, and browser security warnings can impact your customer confidence and brand. An end user with low technical knowledge will feel insecure with the web application and leave, resulting in revenue loss for the business. https:// https:// https:// Figure 2: Browser warnings Hashing Algorithm - Overview Hashing algorithm is used to verify if the received message has come from the alleged source and has not been altered. Hashing algorithm is for authentication and not for encryption and the hash function output cannot extract the input message. Hash functions are implemented in SSL certificates during the process of creating digital signature by Certificate Authority. A key aspect of cryptographic hash functions is their collision resistance no two inputs have same output. 3
Next step: migrate immediately SHA-1 to SHA-2 migration planning Although a migration has the potential to cause major problems, this solution guide will help you understand the steps involved in a successful migration. As with any activity, you will need to have the right people and the right tools in place for this migration. Since SHA-1 certificates will be used across teams in an organization, the migration team should include people from different teams, such as security, network operations, and IT administration, to enable a smooth transition to the recommended standard. 6-step migration plan The following six steps will help you plan and deploy SHA-2 SSL certificates. SHA-1 signed certificate 1 2. 3 4 5 6 Inventory Impact SHA-1 Enforceable Discovery Validation Assessment Analysis Migration Policy Creation SHA-2 signed certificate Figure 3: 6-Step migration plan Step 1: Discovery of all SHA-1 certificates The first step is to identify SSL certificates that have a SHA-1 based digital signature across the infrastructure. It is essential that every certificate that has SHA-1 (all certificates in the chain of trust, including intermediate) is tracked down irrespective of the nature of the server (internal or external). Step 2: Inventory assessment of existing certificates Assess the certificates within the discovered inventory. Group and prioritize them according to the organization s requirements, such as replacing SHA-1 certificates on mission-critical and public-facing applications before updating certificates on internal servers. Step 3: Impact analysis of SHA-1 migration Involve every key stakeholder who might be affected by this update and keep them involved in the process. Once the plan is in place, the migration team should do an impact analysis to assess system compatibility with the certificates to be updated. Split multi-domain certificates, such as 4
wildcard certificates, into multiple certificates for supporting legacy applications that do not support the updated signature. All external-facing legacy systems that do not support the SHA-2 algorithm must be upgraded. In the case of legacy systems that are being internally used, use the SHA-1 at your own risk and schedule a phase-out at your convenience. Step 4: SHA-1 to SHA-2 migration After impact analysis, update certificates in the prioritized order. The updated certificates can be reissued, renewed, or purchased from the vendor(s) of your choice. If necessary, the intermediate certificates should also be updated to complete the trust chain. Before replacing the existing SHA-1 certificates with the updated certificates on your servers and trust stores, make a backup of your old as well as new certificates in a secure place. Manual migration can be tedious and error-prone, but make sure each step is documented and accounted for. Step 5: Validation of migration Perform a detailed migration report on the whole process to validate and ensure successful completion. Share the status and progress of the migration plan with the key stakeholders. Step 6: Enforceable policy creation The migration team should create policies to guide the migration process and ensure standardized SHA-2 deployment across the infrastructure. No SHA-2 support for certain devices? After step 3, you might have a list of non-compatible devices that do not support SHA-2 (such as Windows Server 2003). If it is an external server, it is mandatory to upgrade your device to support SHA-2. If it is an internal server, you can still use self-signed SHA-1 certificates at your own risk. If you need to procure certificates from a third-party vendor, you can make use of certain CAs that issue SHA-1 certificates from their non-public CAs, such as IntranetSSL from GlobalSign, since major CAs have stopped issuing SHA-1 certificates from their public root. After being issued new certificates, you will need to push this root to all browser and system applications that need to connect with this server. But this support by browsers will not be long-lasting and you need to start thinking about upgrading your legacy systems. 5
Factors that can void your migration Beyond the initial success of your migration, there are things that can void your effort, including: Using deprecated algorithms: You need to ensure that certificates with a SHA-1 signature do not reappear in your infrastructure. Insiders may have opportunities to misuse their privilege and introduce vulnerabilities into the system. Not enforcing strict policies: If there are no strict policies governing individuals and restricting them from introducing deprecated certificates into the system, then the actual purpose of a migration is lost. You need to regularly validate your certificates to ensure success. Using free certificates: Free certificates can introduce rogue certificates in the system. These undocumented installations usually bypass policies. SHA-1 migration with AppViewX s Certificate Lifecycle Automation solution Manual migration of certificates in a complex, multi-vendor environment can be time-consuming and prone to errors. And, when dealing with hundreds or thousands of certificates in a multi-vendor environment, it becomes difficult to juggle between disparate systems to get your certificates updated, installed, and running. Without proper access controls and policy enforcement post-migration, new vulnerabilities can creep in and your whole update can potentially be undone. This is why the best practice is to use a certificate management and automation tool to simplify not just your SHA-1 transition but any PKI update requirement that you may have in future. AppViewX s Certificate Lifecycle Automation solution provides the functionalities you need to automate the entire six-step migration process and accelerate your SHA-1 update while ensuring the visibility you need to keep your certificates secure. Discovery Discover certificates and keys in your applications, servers, and non-servers through different modes, such as IP, subnet, and devices managed in AppViewX. This module is essential for capturing all certificates with weak signatures that require an update. 6
Inventory After the discovery process, an inventory is built automatically. The inventory lists all the server, intermediate, and root certificates along with the necessary configuration details. Certificates can then be segregated according to the required signature algorithm. This provides a single repository of vulnerable certificates and an easy way to identify and map certificates with weaker signatures. Reports If you need to provide visibility into vulnerable certificates and impacted applications or servers to key stakeholders, the AppViewX Platform s reporting provides a complete picture of the certificate ecosystem. The number of vulnerable certificates can be identified with certificate expiration status. Validation If you need to provide visibility into vulnerable certificates and impacted applications or servers to key stakeholders, AppViewX Platform s reporting gives the user a complete picture of the certificate ecosystem. The number of vulnerable certificates can be identified in the environment with certificate expiration status. 7
Renewal The AppViewX Platform can automatically connect with the respective certificate authorities to acquire the updated certificates. Once the new certificates are in place, users can renew vulnerable certificates in two ways, depending on need: Individual migration: In production environments, the AppViewX Platform enables users to renew certificates one by one for better control and less impact. Bulk migration: During maintenance windows, the AppViewX Platform allows users to renew certificates in bulk using a simple provisioning template. Policy Creation Your progress can be undone at any time if weak certificates find their way into your environment. This is where the policy module in the AppViewX Platform helps. It allows users to enforce policies to ensure that recommended algorithms are followed, and this can be made mandatory as required. Strong certificate parameters can be defined to ensure that any future requests meet organizational standards. 8
Conclusion All software has vulnerabilities, so attacks are inevitable. But the amount of time you take between identifying a vulnerability and patching it is crucial. Never take a vulnerability for granted and never put off an update because of its complexity. You shouldn t wait for external entities like browsers to set the timeline for your update. It is your security at stake and you are responsible for its mitigation. In addition, manual processes can be error-prone, and an undocumented or mislabeled certificate-or even a small mistake in the manual validation of your SHA-1 migration on the part of your team-can nullify the entire process. By following this guide and using the right automation tools, a successful migration does not need to be complex and time-consuming. Learn More An automation tool can help you achieve unlimited possibilities with limited resources. To learn more about AppViewX solutions, please visit https://www.appviewx.com/solutions/certificate-lifecycle-automation/. White Hat Web Applications Security Statistics Report 2016 Cisco 2016 Midyear Cybersecurity Report https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html?m=1 About AppViewX AppViewX is revolutionizing the way NetOps and SecOps teams deliver services to Enterprise IT. The AppViewX Platform is a modular, low-code software application that enables the automation and orchestration of network infrastructure using an intuitive, context-aware, visual workflow. It quickly and easily translates business requirements into automation workflows that improve agility, enforce compliance, eliminate errors, and reduce cost. AppViewX is headquartered in Seattle with offices in the U.S., U.K., and India. To know more, visit www.appviewx.com. AppViewX Inc., 500 Yale Avenue North, Suite 100, Seattle, WA 98109 info@appviewx.com www.appviewx.com +1 (206) 207-7541 +44 (0) 203-514-2226 2018 AppViewX, Inc. All Rights Reserved. 9