One of the common findings security assessment services encounter when they evaluate the Internet presence of an organization are sites where login credentials travel over the Internet unencrypted.
So: HTTP not HTTPS.
You’ve all seen the “not secure” warnings:
The intent of the browser’s warning is to make the user aware that there is a risk of credential loss with this “http-only” unencrypted login.
The solution is HTTPS of course, but that requires that a “certificate” be created, signed by some “certificate authority” (CA), and that the certificate be installed on the website.
If the user connects via HTTPS ( not HTTP ) the browser and the server negotiate an encrypted communication channel based on the SSL/TLS protocol and all is well…. almost.
The traffic will be encrypted, but if the particular CA that created the website’s certificate is not itself known to the browser (and those trusts are either built-in or added by an IT department) the user may see something like the following:
The browser will give the user the option to trust the certificate and proceed – but this is universally regarded as a bad practice as it makes the end user more inclined to disregard all such security warnings and thus be more susceptible to phishing attacks that intentionally direct them to sites that are not what they claim to be.
The usual solution is to purchase certificates from a known and accepted CA (e.g. DigiCert, Comodo, GoDaddy, Entrust, etc.).
The CA’s that issue these certificates will perform some checks to ensure the requester is legitimate and that the domain is in fact actually controlled by the requester. The extent to which identity is verified and the breadth of coverage largely determines the cost – which can be anywhere from tens to thousands of dollars. SSLShopper provides some examples.
Users who browse to such sites will see the coveted “green lock” indicating an encrypted HTTPS connection to a validated website:
The problem is the cost and administrative delay associated with purchasing certificates from accepted CA’s, keeping track of those certificates, and ensuring they are renewed when they expire.
As a result some sites either dispense with HTTPS altogether or rely on “self-signed” certificates with the attendant risk.
This is where “Let’s Encrypt” comes in.
“Let’s Encrypt” is an effort lead by some of the major players in the industry to lower (read: eliminate) the cost of legitimate HTTPS communications and move the Internet as much as possible to HTTPS (and other SSL/TLS encrypted traffic) as the norm.
The service is entirely free and the administrative costs are minimal. Open-source software (Certbot) exists to automate installation and maintenance.
Quoting from the Certbot site:
“Certbot is an easy-to-use automatic client that fetches and deploys SSL/TLS certificates for your webserver. Certbot was developed by EFF and others as a client for Let’s Encrypt … Certbot will also work with any other CAs that support the ACME protocol.…
Certbot is part of EFF’s larger effort to encrypt the entire Internet. Websites need to use HTTPS to secure the web. Along with HTTPS Everywhere, Certbot aims to build a network that is more structurally private, safe, and protected against censorship”
The software allows “Let’s Encrypt” – acting as a CA – to dynamically validate that the requester has control of the domain associated with the website and issue the appropriate cert. The certificates are good for 90 days – but the entire process of revalidation can be easily automated.
The upshot is that all the barriers that have prevented universal adoption of HTTPS have largely been removed. The CA’s economic model is changing and some have left the business entirely.
Do you still have HTTP-only sites and are they a chronic finding in your security assessments?
Has cost and administrative overhead been a reason for that?
Take a look at “Let’s Encrypt” now!
One caveat:
Just because a site has a legitimate certificate and is using HTTPS does NOT mean it is necessarily safe, You may find your users are under the impression that is the case. As always, user education is a required part of your security program.
See:
HTTPS:
- https://en.wikipedia.org/wiki/HTTPS
- https://en.wikipedia.org/wiki/Public_key_certificate
- https://www.quora.com/What-is-certificate-authority-What-are-some-examples-of-them
- https://www.sslshopper.com/ – SSL costs
“Let’s Encrypt”:
- https://letsencrypt.org/
- https://chooseprivacyweek.org/resources/https-lets-encrypt/
- https://www.eff.org/encrypt-the-web
User Education: