The United States Department of Defense is still issuing SHA-1 signed certificates for use by military agencies, despite this practice being banned by NIST for security reasons nearly two years ago. These certificates are used to protect sensitive communication across the public internet, keeping the transmitted information secret from eavesdroppers and impersonators. The security level provided by these DoD certificates is now below the standard Google considers acceptable for consumer use on the web.
The Missile Defense Agency, the eventual successor to the "Star Wars" programme, uses one of these SHA-1 certificates on a Juniper Networks remote access device. The SHA-1 certificate was issued by the Department of Defense in February 2015, long after NIST declared this practice to be unacceptable.
The National Institute of Standards & Technology (NIST) is charged with "developing standards and guidelines, including minimum requirements, for providing adequate information security for all agency operations and assets", though its requirements "shall not apply to national security systems". Whilst these Department of Defense systems may or may not be considered national security systems, it is difficult to see why they would be subject to requirements any less stringent than those recommended by NIST.
The SHA-1 algorithm was first published in 1995 and is no longer considered secure. NIST’s decision to disallow SHA-1 signature generation after 2013 was originally due to concerns surrounding the cryptographic strength of the algorithm. Back then, it was thought quite likely that future advancements in computing technology and the discovery of new attacks would allow attackers to find SHA-1 hash collisions, and thus be able to impersonate any secure website with a seemingly valid SSL certificate. This prediction appears to have come true, with the latest research suggesting that the cost of using cloud computing resources to find a SHA-1 hash collision is now in the region of $75k, or perhaps even only a week’s use of the largest botnets.
The majority of SHA-1 signed SSL certificates issued for use on publicly-accessible websites within the past few months, and that are valid beyond the start of 2017, were issued to hostnames under the .mil sponsored top-level domain. This sTLD is used by agencies, services and divisions of the United States Department of Defense.
Many other SHA-1 certificates used by .mil websites are valid beyond the start of 2017, which means that Google Chrome already regards them as affirmatively insecure, crossing out the padlock icon:
The security of some of these sites is further undermined by their use of TLS 1.0 connections, even though most users’ browsers are likely to support later versions. TLS 1.0 is now considered weak and obsolete, with some standards bodies such as the PCI SSC mandating that it should no longer be used in new applications, and that existing applications must migrate to TLS 1.1 or later by June 2016.
But disabling support for TLS 1.0 is not always feasible, particularly as some older browsers such as Internet Explorer 8 do not support TLS 1.1 and 1.2. If it is essential for a server to retain support for TLS 1.0 (in addition to later versions), then TLS Fallback SCSV must be used to prevent downgrade attacks against clients that support TLS 1.1 or later. This will ensure that modern browsers will always use acceptably secure versions of TLS, while only the older clients can possibly use the weak, obsolete TLS 1.0 cipher suites.
Several other U.S. military remote access services only support the obsolete TLS 1.0 protocol, including two used by the Defense Logistics Agency. Some other military sites, including one of the Navy’s VPN services do support TLS 1.2, but with obsolete cipher suites. These particular sites all use SHA-1 signed certificates that do not expire until 2017, and so are regarded as “affirmatively insecure” by Chrome.
DoD PKI infrastructure
The Department of Defence PKI infrastructure relies on two root certificate authorities (DoD Root CA 2 and DoD Root CA 3), but these are not included in all browsers by default.
Windows and Linux users must explicitly install the DoD root certificates in order for the subscriber certificates to be validated and trusted by their browsers. But interestingly, the DoD roots are trusted on Apple platforms by default; this means that the DoD has the necessary third-party attestation for inclusion in the Apple Root Certificate Program, even though many of the subscriber certificates fail to conform to the Baseline Requirements for the issuance and management of publicly-trusted certificates.
The U.S. Government has faced numerous hurdles in being recognised as a publicly-trusted certificate authority. In 2009, the Federal Public Key Infrastructure Management Authority (US FPKI) requested for its Federal Common Policy Framework Certificate Authority (Common Policy CA) root certificate to be added to Firefox and other Mozilla products. Only subscriber certificates for .gov and .mil domains would have been trusted under this root, but the request was eventually put On Hold in May 2015. It was decided that US FPKI should be treated as a Super-CA, whose subordinate CAs must apply for inclusions themselves.
One of the arguments for accepting the US government as a publicly-trusted certificate authority was that it would avoid the need to purchase commercial certificates and thus save taxpayer dollars. One viable alternative might have been to use the free Let’s Encrypt certificate authority, which became trusted by all major browsers this week. However, the cross-signed Let’s Encrypt Authority X1 intermediate certificate uses the X509v3 Name Constraints field to explicitly disallow its use by .mil domains. No other top-level domains are precluded from using Let’s Encrypt.
Many .mil sites recommend using the InstallRoot tool to simplify the installation and management of the DoD root certificates on Windows machines. This tool also installs several intermediate certificates, which the Department of Defense uses to directly sign the subscriber certificates.
As an example, the subscriber certificate issued to cec.navfac.navy.mil was signed on 19 March 2015 by the DOD CA-27 intermediate, which is signed by the DoD Root CA 2 trusted root. This chain of trust allows the browser to verify that cec.navfac.navy.mil is a legitimate site operated by a Department of Defense agency, and that the connection is not being subjected to a man-in-the-middle attack.
These intermediate certificates are also signed with the arguably weak SHA-1 algorithm. Whilst not the most likely way in which SHA-1 will initially fail — a chosen-prefix attack such as the one used on MD5 in the Flame malware is more likely — if any of these intermediate certificates were to be targeted to find a collision, it would be possible for an attacker to generate valid subscriber certificates for any domain. This would allow the attacker to convincingly impersonate U.S. military sites and carry out man-in-the-middle attacks against browsers that trust the DoD root certificates.
Although the DoD PKI infrastructure is not trusted by all browsers, it is nonetheless surprising to see it flouting some of the well-founded rules and recommendations that apply to publicly trusted certificates as well as recommendations made by NIST. Many of these guidelines are backed by valid security concerns – in particular, using SHA-1 for signature generation is now considered ill-advised, as any well-funded attacker can plausibly compromise the affected certificates.
The risk to the Department of Defense is further heightened by enemy goverments being the most likely sources of attack. The projected cost of attacking SHA-1 is unlikely to be prohibitive, and some governments may already be in a position to find a hash collision faster than the most organised criminals.