For over twenty years it’s been possible to protect interaction with websites using encryption. The majority services we interact with daily such as online banking, major online retailers and social media giants such as Facebook, Google, Twitter etc use this technology by default. Website developers and infrastructure engineers have long known the value of web site encryption, but the message had not been given significance to the public.

Now Google, and other browser vendors, are taking steps to explicitly inform users sites are not secure. Organisations need to respond to this challenge by ensuring that their websites are appropriately protected.

HTTP

Hypertext Transfer Protocol, the mechanism that is used to send content to and from web sites.

HTTPS

HTTP extended with TLS to encrypt communication between browsers and web sites.

SSL

Secure Sockets Layer, deprecated technology to implement website encryption.

TLS

Transport Layer Security, replacement for SSL. Confusingly, some use SSL to mean both TLS and SSL.

Certificate

During a browser connection to a website it offers a certificate that guarantees the website is authentic. The data associated with a certificate is used as the basis for TLS encryption.

What are encrypted websites?

There are two ways to give access to a website. HTTP – where data is sent unencrypted between the browser and the web site, and HTTPS – where that data is encrypted using TLS.

With unencrypted HTTP sites, anyone can see the interaction “in transit” between the browser and the web server. For example, if you log in to a site anyone on the same network can, in principle, view your password with simple tools. Likewise, an ISP or other entity could intercept and record everything you do.

With encrypted HTTPS, this interception is far costlier and time consuming, the mathematics behind HTTPS ensures that while it is very “cheap” for browsers and web servers to secure the network traffic sent to and from a site, it requires a practically unreasonable investment in time, money, expertise and equipment to break this encryption.

An additional advantage of HTTPS encrypted sites is a guarantee (using a certificate) that you are looking at the real site, and not a copy designed to collect your data, such as passwords for online banking.

Why aren’t all websites encrypted?

Historically there was a non-trivial investment required to enable HTTPS on a site – in terms of cost, expertise and computing power.

Today HTTPS can be obtained at a very low cost (sometimes for free), tools and automation simplify deployment, and as computing power increases, it’s estimated that the overhead of HTTPS accounts for less than 1% of processing power for a typical website.

In short, unless you have overriding reasons to do so, your website traffic should be protected with HTTPS, and insecure HTTP should not be used.

What is Google doing and why?

Google is leading the way on encouraging adoption of HTTPS:Google is leading the way on encouraging adoption of HTTPS:

• In successive releases, they have slowly changed the behaviour of the Chrome browser to display an explicit warning when people browse to a HTTP website.
• Prioritising results for secure sites in search results.

In the October 2017 release of Chrome, non-HTTPS pages where a user can enter data will be very clearly marked as not secure:

Google has stated that in future its plans to show the ‘not secure’ message for all websites that are HTTP and not HTTPS, even if data isn’t being entered:

Websites that use HTTPS will continue to be marked as secure.

Even if a site uses HTTPS it doesn’t mean it is fully secure. Ensuring that your site is HTTPS-only is an essential step in making your site secure, but that’s only part of the security picture. Your application may still have insecure behaviours that can afford leaking of user credentials and data, and other attacks. Reviewing the list at https://www.owasp.org/index.php/Top_10_2013 is a good starting point.

What you need to do?

You need a plan to ensure that HTTPS is the only way to access your site(s). However, before we take the plunge, we must be aware that:

• All non-sensitive pages should be automatically redirected to the HTTPS site. This ensures that results from Search engines (such as Google) and entries in user bookmarks and history continue to work.
• Some level of testing is required, not only to ensure the website works, but to ensure that some sensitive functions such as login pages, can’t be accessed indirectly via HTTP. Note that significant rework of a site for HTTPS is a potential indicator of poor software architecture or quality of implementation.
• You may need to inform your users of the change as they may need to change their bookmarks.
• Certificates associated with HTTPS are designed to expire, typically after a year or two, and if they are not renewed, you will be in the potentially embarrassing situation of a site being marked “not secure” due to the expiry. Therefore, ownership of certificate renewal must be clearly defined.
• Web services and APIs require different considerations, for security reasons we should generally avoid redirection of HTTP to HTTPS for APIs, so the migration requires careful planning and clear communication to API consumers.
• Ensure that other detailed technical concerns are considered, e.g. ensuring that your user session cookies are set to “secure”, the use of HSTS and that the site security configuration follows industry guidelines e.g. https://wiki.mozilla.org/Security/Server_Side_TLS.

Managing the migration on modern Cloud infrastructure

All modern cloud platforms offer tools and services to simplify HTTPS configuration. For example, both Google Cloud and AWS have low, or zero, cost “certificate” services and load-balancing infrastructure that essentially abstracts configuration away from your site.

Managing the migration of legacy websites

In older/more traditional architectures, you may need more careful planning and testing around configuration of applications, web servers and other infrastructure. In principle this is straightforward, but in practice an experienced infrastructure architect may be required to ensure HTTPS is implemented correctly and securely. Tools such as https://letsencrypt.org/ help, but are not a substitute for planning, testing and understanding.

Lessons for leaders

• All new sites must be HTTPS-only
• All existing sites should be reviewed
• Making a site HTTPS-only isn’t a silver bullet for security – your application could still have insecure behaviours
• If a site is migrated we must take care that testing is done, including checking that existing links still work
• Web services/APIs migration requires careful planning and communication
• Modern cloud infrastructure makes migration easier
• Legacy sites require more detailed and skilled work

How Arrk can help

Google is taking steps to notify users when they access insecure HTTP websites using the Chrome browser, we need to respond to this challenge by ensuring that our sites are encrypted using HTTPS.

Arrk has a wide range of skills in bespoke software development, infrastructure and application security, cloud management, testing services, HTTPS migration strategies and low-level HTTPS build and configuration, to offer these related services:

• HTTPS Migration
• Cloud management
• Infrastructure optimisation
• Full-Stack Security Review
• TechmArrk™ Software Architecture Review
• Software Testing
• API Design
• Architecture modernisation