This article covers the technical details, with examples, of why you might be failing the HTTP Still Available check.
The HTTP Still Available check is used to measure whether a server is allowing users to connect to it via HTTP rather than HTTPS. Connecting to a website via HTTPS is more secure as it involves an SSL/TLS-based connection, which in turn provides the following security benefits:
-
Ensures the information being sent to and from the server is encrypted, rather than being sent in plaintext.
-
Ensures that the server you are connecting to has proven they are who they say they are.
You will be failing this check for a domain if your web server serves up a webpage when you access the domain over its HTTP port.
But I have my HTTP port redirecting to HTTPS...
Perfect, this is good practice. Many web browsers will try the HTTP version of a website first before trying the HTTPS version. If you have a proper redirect response on your HTTP port then you will pass this check. You should combine this with proper HSTS settings to ensure browsers always attempt an HTTPS-based connection from the beginning.
But my server returns a "403 - Forbidden", "404 - Not Found" or "503 - Service Unavailable", etc, response. It's not accessible, right?
From a "connection and transmission of data" point of view, your server is still accessible over HTTP. As an example, a user might attempt to visit your website and embed their username and password in the URL parameters or the request headers as part of the request. The server may respond with a 403 - Forbidden response, but the user's credentials have already been sent in plaintext across the internet. This makes for an easy MITM attack vector.
As above, the best practice here is the employ both a redirect to HTTPS and configure your HSTS settings to ensure all connections to your server and made over a secure connection in the first place.
See also: