While moves towards increased use of Hypertext Transfer Protocol Secure (HTTPS) as an Internet security measure are admirable, it begs the question of how much trust should be placed in HTTPS security? To what extent can web users rely on an HTTPS encrypted connection to secure their flow of data – and how open are these connections to manipulation by malicious attackers?
The principle purpose of HTTPS is to forge a secure channel of data transfer through an insecure network – thus affording some protection to web users even if only one stream of communication is secured. This means in theory that a person can log onto a secure web page – let’s say their online bank account, and be secure from eavesdropping and “Man-in-the-middle” attacks, even when using an anonymous network such as Tor, or an open and unsecured WiFi connection. In theory of course, such HTTPS protected websites should be impervious to attack, even if other HTTP connections across the network have experienced security breaches.
This level of security effectiveness is dependent on two main criteria: a trusted and verified server certificate, and an effective set of Cipher suites. Cipher suites are ‘message authentication code’ algorithms which allow a web connection access to an HTTPS protected site by passing through the TSL protocol layered onto the page. In other words, the cipher suites act as keys, or password combinations which allow data access between website, web server and local web browser. It follows that not all cipher suites are created equal, and some are more effective than others.
Authentication certificates are the second plank in the security provided by HTTPS connections. Certificates operate at the web browser level, whereby the browser recognizes the authority of websites that hold a certificate from a pre-specified list of providers. A number of web security companies release these certificates, including Verisign and Microsoft – and they can be purchased by individual web masters for as little as $5 to well over $1,000 per year.
An HTTPS secured website is therefore only as secure as the certificate that validates the connection. Web users should therefore only trust an HTTPS connection which fulfills the following set of criteria:
- The certificate provider is an established and reputable Internet security provider, and is recognized as such by the web browser. If the web browser does not recognize a certificate, it should prompt some serious questions by the web user as to why this is not the case – providing they have an up-to-date version of the browser installed on their computer.
- The security certificate is specific to the website in question; rather than referring to a different site which is not covered by the security guarantee.
The wild card element with HTTPS security is the classic clash of human ingenuity, naiveté and ignorance. In 2009, an experiment conducted at the Blackhat Conference illustrated how a determined Man-in-the-middle attack could outwit HTTPS security. This assault bypassed HTTPS security by changing the link to a simple “HTTP” address. This preys on the mostly correct assumption that the majority of web users know nothing, or very little about HTTPS – and often type in “HTTP” when navigating directly to a website.
More recently, a growing number of HTTPS security certificates have been found to be compromised, necessitating additional layers of computer security in order to maintain the integrity of their internet connection.
How can HTTPS security be improved?
As we have seen, HTTPS secured websites are in principle open to subversion on a number of levels. For instance, a provider of authentication certificates could choose to validate insecure websites – in which case connections that show as secure may still be open to data violations. Also, a cipher suite protecting access to a TSL may be inadequate for security needs.
Clearly, HTTPS is not an infallible system and is not invulnerable to human error or to human malice. However, the questions that remains are: To what extent are these concerns reasonably founded, and how can HTTPS security be improved?
The first conclusion is that web users should not rest on their laurels when it comes to web security, and should not immediately trust a web page simply because it boasts an “HTTPS” prefix. Especially for web-based businesses, a robust set of computer security and information sharing policies is essential to maintain data integrity online. Regular scanning of downloaded applications for viruses and malware should be a habitual practice, as should the blocking of phishing sites and regular HTTPS encryption inspection. Private users can increase their web security by avoiding the easy temptation of utilizing poorly encrypted free WiFi links, although this may be more easily said than done.
Despite the persistence of cybercrime and web-based attacks, there is still reason for optimism about the future. Governments across the world are paying increased attention to internet security concerns, with the US Congress talking about introducing legislation to force companies to take greater security measures with their users’ data. Large stakeholders in the Internet are also catching on to the problem, spearheaded by Google, who in 2011 upgraded their SSL Apis for all their HTTPS connections.
In the bid to effectively and cheaply secure internet connections for all web users, HTTPS still offers the best overall option, despite the rather haphazard way it has been thrown together, and the variables which leave it open to failure. It is still more practical than alternative forms of internet security, such as S-HTTP, which looks attractive on paper but is cumbersome to implement for most average websites. So long as standards of certificate authority can be tightened up across the board, and due attention given to maintaining the integrity of cipher suites, HTTPS still offers the best widely available means of keeping one step ahead of the hackers.
About the Author: This guest post is by David Ritchie, a freelance technical writer interested in Mac malware protection software.