Manufacturing.gov and White House security suffer under U.S. shutdown

Dozens more U.S. government websites have become inaccessible since last week, when Netcraft highlighted the impact of security certificates expiring during the federal shutdown.

As of today, more than 130 TLS certificates used by U.S. government websites have expired without being renewed. Some of these sites are now completely inaccessible in modern browsers due to their strict transport security policies.

The latest sites to be affected include some particularly prominent examples.

manufacturing-snippet

Take https://manufacturing.gov, for instance. While Trump is keen to highlight the performance of U.S. manufacturing during his administration, the shutdown has meant that nobody was available to renew the site's TLS certificate when it expired on 14 January 2019. Consequently, https://manufacturing.gov is dead in the water, along with https://manufacturingusa.com which shares the same certificate.

manufacturing

Furthermore, as https://manufacturing.gov appears in Chromium's HSTS preload list, visitors are unable to bypass the browser's security warnings, rendering the site unreachable.

manufacturing.gov appears in Chromium's HSTS preload list, which ensures that the website's strict transport policy will always be enforced, even when a browser has never visited the site before.

manufacturing.gov appears in Chromium's HSTS preload list, which ensures that the website's strict transport policy will always be enforced, even when a browser has never visited the site before. www.manufacturing.gov uses a different certificate, which is currently valid.

A White House subdomain at https://pages.mail.whitehouse.gov has also become unreachable. The certificate used by this site expired on 15 January 2019 and has not been renewed. This site is also covered by an effective preloaded HSTS policy.

White House security warnings in Mozilla Firefox.

White House security warnings in Mozilla Firefox.

Other notable websites to have been affected by expired certificates over the past five days include two FAA (Federal Aviation Authority) websites, a National Archives customer portal, the FFIEC (Federal Financial Institutions Examination Council) Anti-Money Laundering Infobase, several Department of Agriculture sites, and several governmental remote access services.

When the federal government restarts, the White House will need to renew its certificate for pages.mail.whitehouse.gov. The list price for a replacement DigiCert organisation validated certificate — similar to the expired one — could be up to $399 per year, or about 70 Big Macs.

.gov security falters during U.S. shutdown

Dozens of U.S. government websites have been rendered either insecure or inaccessible during the ongoing U.S. federal shutdown. These sites include sensitive government payment portals and remote access services, affecting the likes of NASA, the U.S. Department of Justice, and the Court of Appeals.

The DigiCert certificate used by this U.S. Court of Appeals website expired on 5 January 2019 and has not yet been renewed. The site provides links to a document filing system and PACER (Public Access to Court Electronic Records).

The DigiCert certificate used by this U.S. Court of Appeals website expired on 5 January 2019 and has not yet been renewed. The site provides links to a document filing system and PACER (Public Access to Court Electronic Records).

With around 400,000 federal employees currently furloughed, more than 80 TLS certificates used by .gov websites have so far expired without being renewed. To compound the situation, some of these abandoned websites can no longer be accessed due to strict security measures that were implemented long before the shutdown started.

One such example is https://ows2.usdoj.gov, a U.S. Department of Justice website which uses a certificate that expired in the week leading up the shutdown. The certificate has been signed by a trusted certificate authority, GoDaddy, but it has not been renewed since it expired on 17 December 2018.

All U.S. Department of Justice subdomains are covered by an HSTS policy. Combined with an expired TLS certificate, this currently makes it difficult for regular users to ignore the warnings and use the website.

All U.S. Department of Justice subdomains are covered by an HSTS policy. Combined with an expired TLS certificate, this currently makes it difficult for regular users to ignore the warnings and use the website.

In a twist of fate, the usdoj.gov domain — and all of its subdomains — are included in Chromium's HSTS preload list. This is a prudent security measure which forces modern browsers to only use secure, encrypted protocols when accessing the U.S. DoJ websites; however, it will also prevent users from visiting the HTTPS sites when an expired certificate is encountered. In these cases, modern browsers like Google Chrome and Mozilla Firefox deliberately hide the advanced option that would let the user bypass the warning and continue through to the site.

While this behaviour is bound to frustrate some users, in this case, security is arguably better than usability when you can't have both. If users were to ignore such warnings, they would be vulnerable to the type of man-in-the-middle attacks that TLS certificates were intended to combat.

However, only a few of the affected .gov sites implement correctly-functioning HSTS policies. Just a handful of the sites appear in the HSTS preload list, and only a small proportion of the rest attempt to set a policy via the Strict-Transport-Security HTTP header – but the latter policies will not be obeyed when they are served alongside an expired certificate, and so will only be effective if the user has already visited the sites before.

Consequently, most of the affected sites will display an interstitial security warning that the user will be able to bypass. This introduces some realistic security concerns, as task-oriented users are more likely to ignore these security warnings, and will therefore render themselves vulnerable to man-in-the-middle attacks.

For example, https://rockettest.nasa.gov/ is not included in the HSTS preload list, and its certificate expired on 5 January 2019. This causes browsers to display an interstitial security warning that users can ignore.

This NASA website is still using an expired certificate, but the domain does not appear on the HSTS preload list.  Users can therefore ignore the browser's warnings and proceed to the site.

This NASA website is still using an expired certificate, but the domain does not appear on the HSTS preload list. Users can therefore ignore the browser's warnings and proceed to the site.

The following example clearly demonstrates the potential dangers of ignoring browser security warnings. The certificate used by this Berkeley Lab .gov website at https://d2l.lbl.gov expired on 8 January 2019 (although Berkeley Lab was not affected by the shutdown) and has not yet been replaced. As there is no effective HSTS policy, users can ignore the browser's warnings and proceed to the login form.

Encouraging users to ignore browser warnings could make them more susceptible to man-in-the-middle attacks.

Encouraging users to ignore browser warnings could make them more susceptible to man-in-the-middle attacks. In this example, clicking next to the browser's address bar will explicitly advise the user not to enter any sensitive information, such as passwords – but anyone who really needs to use the site may foolishly end up doing so anyway.

With Donald Trump seemingly unwilling to compromise on his demands for a wall along the border with Mexico, and Democrats refusing to approve a budget containing $5.7bn for the wall, the hundreds of thousands of unpaid federal employees might not be the only ones hurting. As more and more certificates used by government websites inevitably expire over the following days, weeks — or maybe even months — there could be some realistic opportunities to undermine the security of all U.S. citizens.

Most Reliable Hosting Company Sites in December 2018

Rank Performance Graph OS Outage
hh:mm:ss
Failed
Req%
DNS Connect First
byte
Total
1 EveryCity SmartOS 0:00:00 0.000 0.230 0.070 0.338 0.338
2 Bigstep Linux 0:00:00 0.000 0.233 0.071 0.146 0.146
3 Webair Linux 0:00:00 0.000 0.335 0.080 0.161 0.161
4 Hyve Managed Hosting Linux 0:00:00 0.000 0.170 0.081 0.162 0.162
5 CWCS Linux 0:00:00 0.000 0.293 0.083 0.160 0.160
6 Rackspace Linux 0:00:00 0.004 0.663 0.006 0.015 0.015
7 New York Internet (NYI) FreeBSD 0:00:00 0.004 0.540 0.063 0.125 0.125
8 www.dinahosting.com Linux 0:00:00 0.004 0.280 0.089 0.178 0.178
9 krystal.co.uk Linux 0:00:00 0.004 0.241 0.100 0.198 0.198
10 GoDaddy.com Inc Linux 0:00:00 0.008 0.433 0.007 0.021 0.022

See full table

EveryCity had the most reliable hosting company site in December 2018, with no failed requests and an average connection time of 70ms. EveryCity appeared eight times in the top 10 in 2018, and has maintained 99.9994% uptime over the last four years. The hosting company offers cloud hosting solutions and managed third-party services, with its primary data centre located in the heart of the City of London.

Four other hosting company sites also successfully responded to all of Netcraft's requests, and were ranked by their average connection times. In second place, Bigstep had an average connection time just a millisecond slower than EveryCity. Bigstep has maintained 99.97% uptime over the past five years. Webair, Hyve and CWCS complete the top five, with average connection times of 80ms, 81ms and 83ms.

Linux was the most popular operating system in December 2018, used by eight of the top 10 most reliable hosting company sites. SmartOS is used by EveryCity, which had the most reliable hosting company site. SmartOS is an open-source community fork of OpenSolaris designed specifically for cloud computing. FreeBSD also appears in the top 10 for December.

Netcraft measures and makes available the response times of around twenty leading hosting providers' sites. The performance measurements are made at fifteen minute intervals from separate points around the internet, and averages are calculated over the immediately preceding 24 hour period.

From a customer's point of view, the percentage of failed requests is more pertinent than outages on hosting companies' own sites, as this gives a pointer to reliability of routing, and this is why we choose to rank our table by fewest failed requests, rather than shortest periods of outage. In the event the number of failed requests are equal then sites are ranked by average connection times.

Information on the measurement process and current measurements is available.