Why You Need HTTPS for Your Website, Today
Think you don’t need HTTPS for your website? Well, you do. Even if your site does not sell products via e-commerce, web security risks exist for plain HTTP connections. And search engines are starting to lower non-HTTPS sites in search ranking. Even the U.S. government is moving all their sites from HTTP to HTTPS. Here’s why you should, too.
Without HTTPS, a user’s connection to your site can easily be monitored or modified. Non-HTTPS connections could even allow your site to be impersonated by a hacker.
According to CIO.gov, a properly-configured HTTPS connection guarantees three things:
Over HTTPS, a visitor’s connection is encrypted. This obscures their stored cookies and other sensitive user data.
HTTPS ensures a visitor is talking to your “real” website, not to an impersonator or a “man-in-the-middle” who stepped in.
HTTPS connections mean data sent between a visitor and your website has not been tampered with.
A plain HTTP connection can be easily monitored, modified, and impersonated. Think about users at Starbucks or on a hotel’s public Wi-Fi. Their browsing location makes them a prime target for being monitored. And if they are connecting to your site without HTTPS, they are open to session hijacking via cookie stealing. HTTPS on its own can’t protect these users 100%, but combined with other site architecture techniques you can get very close.
In addition, there are some newer incentives emerging that make moving your site from HTTP to HTTPS even more important.
One of the biggest reasons besides security to move to HTTPS is that Google may soon start penalizing non-HTTPS sites in search results. This means you may start ranking lower for keywords if your site is not served over an HTTPS connection.
Comparisons of search engine ranking results before and after changing a site from HTTP to HTTPS show that HTTPS can positively affect your SEO. Some sources say that Google has been using HTTPS as a ranking signal since as early as 2014. And more recent investigations show the positive weighting for HTTPS in search engine results will only increase.
In addition, referrer information is not passed from HTTPS websites to HTTP websites. This means migrating to HTTPS can improve analytics about web traffic referred from HTTPS websites.
To avoid taking a SEO hit, be sure to use 301 redirects to redirect users from HTTP to HTTPS. Moving to HTTPS is a permanent situation. Therefore, 302 redirects are improper. 302’s may even negatively impact your rankings.
In addition, browsers are starting to design more noticeable security icons for the address bar. These icons notify users when they are browsing over a non-HTTPS site. They are displayed whether or not the site is collecting personal data.
Users are going to get accustomed to an icon that indicates HTTPS. They may come to suspect your site if it doesn’t have it. Plus, proposed changes to these icons are in the works. Motherboard reports that Google’s Chrome browser may now explicitly call out websites without HTTPS as unsafe.
Will these icons cause users to turn away from sites without HTTPS? The advantages of HTTPS make the potential loss of traffic seem like a pointless compromise. Providing a secure connection is good customer service.
When you consider all these factors in total, the verdict is clear. You will have to move to HTTPS some time soon. Having a conversation with your IT team about this is important. So I’m going to answer some questions for you in advance. To help understand the answers, here are some other web security terms you might find helpful.
SSL — secure socket layer or transport layer security. Common protocols for SSL include:
- SSL 2.0
- SSL 3.0
- TLS 1.0
- TLS 1.1
- TLS 1.2
Note: SSL 2.0 and 3.0 are actually deprecated. Using these layers leave you open to huge vulnerabilities. Web developers should use TLS for security. However, we still use the term SSL as an umbrella to cover TLS, since it is widely understood.
HTTPS — secure hypertext transport protocol. You can use a number of different secure protocols and have an HTTPS site.
HTTP/2 — Different than HTTPS, HTTP/2 is a new version of HTTP that is designed to deliver sites more quickly and efficiently. HTTP/2 uses multiplexing and binary protocols. However, this requires the use of SSL to work.
No, not really. Traditionally, any site with a login should serve content over HTTPS. But after recent data breaches, the industry standard is moving every website toward forcing HTTPS.
These days, the only case to be made for non-HTTPS sites would be for something with super high traffic, and where low latency is key. Of course, it couldn’t be a site that stores or asks for personally identifying information.
There are several reasons why adding HTTPS is a good idea, even if you don’t sell items on your website.
Serving your site over a secure connection also ensures that hackers can’t sneak in and spoof your site while users are browsing. And some organizations report non-HTTPS sites are more likely to be monitored by government agencies. Regular HTTP traffic is open to full packet inspections, so source, destination, request header, and content are open to inspection. Some site visitors may prefer that privacy.
Don’t forget the other three other reasons I’ve mentioned to move to HTTPS (besides security):
- Potential SEO benefits
- User experience
- Customer service
The process is usually not very complicated. There are two basic steps to getting HTTPS.
- Buying the proper SSL certificate for your organization’s needs and your site’s requirements. For domain.com, you would get a cert for domain.com. If you have multiple subdomains, you would either need a cert for each, or obtain something called a wildcard cert. This would cover everything at *.domain.com. This means the certificate would be applicable for any and all subdomains, like mail.domain.com or clients.domain.com. Note: wildcards are more expensive.
- Installing the certificate. The web browser will request SSL and then handshake with the server. If that completes successfully, you’ll be using SSL/TLS. You can force HTTPS/SSL by having your webserver redirect all requests to an SSL-enabled port. For example:
That way, people can type in www.yourwebsitedomain.com and reach the site. No need to alert your customers your URL will include HTTPS or to append :443 to the end of the URL.
Yes. If your industry has to comply with security requirements for HIPAA or PCI-DSS, you will need to ensure at least TLS 1.1 SSL on your site (at the time of writing). Organizations that must comply with financial reporting or communication requirements for The Sarbanes-Oxley Act (SOX) or The Gramm-Leach-Bliley Act (GLBA) are also subject to some additional security requirements. These mostly apply to storing data and sending emails.
For both PCI-DSS and HIPAA/HITECH, data transmission security is just one aspect of a much longer list of compliance requirements. Your information security policies as a whole have to be in compliance in every aspect. If one aspect does not comply, you’re subject to penalties, especially if a breach occurs.
Compliance with these standards almost always requires use of the latest version of TLS. In fact, even having your Web servers configured to allow browsers to connect using earlier versions of SSL/TLS can put you in violation. Services such as www.ssllabs.com can help you test your compliance and identify where your vulnerabilities exist.
Updating your connection HTTP to HTTPS is an important part of web security, but it is just part of the picture. Secure data transmission by itself will not prevent your site, application, or database from being exploited or even taken over. That is why best practice lists such as the OWASP Top Ten exist.
There are many vulnerabilities that don’t depend on an attacker “seeing” confidential data in flight, especially if a site has form fields that allow anonymous users to submit arbitrary data. Malicious users could use these forms to perform SQL injections and more. The solutions include user input validation and not trusting any user input to be safe. Without fortified entry points, encryption can’t help you.
In principle, all form submissions should use SSL/TLS by default, even if there is no explicit compliance requirement.
Those requirements are based on universally acknowledged best information security practices. If the data your site is handling is confidential in any sense, you should be using these same practices. This is especially relevant when credentials or other personal information are being passed over HTTP.
While you’re in the security mindset, you may want to work with your team to look at:
- Making sure all updates and patches are installed
- Reviewing password security
- Performing a security audit
Adding SSL can get expensive. Costs depend on:
- The number of sites and subdomains you need to cover
- Who the issuing authority is (more reputable vendors charge more money)
Options run from about $50 per year to upwards of $1500 depending on the wildcards and type of encryption offered. If you do e-commerce, you need to make sure your encryption meets the requirements for PCI-DSS compliance. Some of the lower-priced options may not work for this requirement, or in other edge cases. Others may not meet browser requirements and raise their alert flags, causing fear in some users. Self-signed certs may do this.
However, organizations like Let’s Encrypt are disrupting SSL providers by offering security certificates for free.
Let’s Encrypt is a nonprofit organization trying to make the web more cooperative. According to their website, their mission is “much like the underlying Internet protocols themselves, Let’s Encrypt is a joint effort to benefit the community, beyond the control of any one organization.”
We haven’t seen much UX commentary on how users react to these new security flags in the browser. Anecdotally, they are somewhat noticeable, as they are consistent with icons some users are accustomed to looking for in the URL bar.
Below are examples for you to see how different browsers treat an HTTPS site versus a non-HTTPS site.
How users view these icons or other warnings should definitely be part of the larger security/digital literacy dialogue, though. Calling attention to a site’s security (or lack thereof) is a step in the right direction.
But beyond that, we should be finding ways to make that awareness more meaningful. For example, how can we get users to care, or to actually change their actions/behaviors at key points of interaction (e.g., entering personal information)? We also need to consider alarm fatigue.
What will browser makers design for sites that are not HTTPS in the future? The current standard display for sites that try to deliver data normally subject to privacy requirements over a non-HTTPS connection is unavoidable:
How will that change?
Hopefully this post has made the advantages of HTTPS clear. Ready to take advantage of what this technology has to offer? Your next step is to contact your IT department or a trusted web support entity.
Originally published at medium.com on April 27, 2016.