The Healthcare.gov website has been plagued with bugs and other problems since the October 1 launch. As web programmers often do, the designers of the federal government's flagship healthcare website have a test version of the site, test.healthcare.gov, to help work out the kinks before implementation on the public site. Attempts to access this site are met with "Access Denied. You don't have permission to access 'http://test.healthcare.gov/' on this server." However, another test version of the site, possibly set up in October after the launch, is readily accessible to the public: spa.healthcare.gov.
When a user first attempts to access the "spa" site, a warning from the user's browser may be encountered. For example, the following warning appears to Chrome users:
The "security certificate" for the site is registered to Akamai Technologies, which bills itself as the "leading cloud platform for helping enterprises provide secure, high-performing user experiences on any device, anywhere." Akamai does not list Healthcare.gov or the Department of Health and Human Services (HHS) as a client, though Akamai has been identified as handling server and web traffic duties for the site.
Some pages on the site simply mirror the main www.healthcare.gov site, such as the home page. However, some pages on the main site (https://www.healthcare.gov/find-premium-estimates/) are met with a "Sorry, we can't find that page" message on the "spa" site (https://spa.healthcare.gov/find-premium-estimates/). The login page on the "spa" site does not even open, but rather returns "An error occurred while processing your request" message.
It is unclear why this "spa" site would be publicly accessible. A web designer, who requested not to be named, asked about security concerns of the "spa" site wrote:
Well it does have the https (ssl) option, however the certificate that is installed is for the wrong domain so you will get a warning/have to accept etc. Certificate details below. It is common practive to create a "duplicate" site for testing and development. I do it all the time, however, common practice is to restrict access to the development/testing site. I always password protect etc the [non-production] site. To me it just seems like more sloppy work.Congressional testimony given on November 19 by internet security firm TrustedSec mentioned a security concern with the "spa" site:
NOTE: A version of this article (before the update) first appeared at The Weekly Standard.
No comments:
Post a Comment