Subscribe Now

* You will receive the latest news and updates on the Canadian IT marketplace.

Trending News

Blog Post

Security issues in HTTPS

Security issues in HTTPS 

HTTPS provides strong protection against passive data interception. Cryptographic mechanisms like Perfect Forward Secrecy (PFS) make it difficult to decrypt data if certificates and their corresponding keys are compromised in the future. A variety of strong cryptographic algorithms make head-on cryptanalysis prohibitively expensive. As a result, adversaries can no longer simply sniff network traffic; they are forced to adopt more complex and expensive active attack methods, and apply them more selectively.

HTTPS relies on TLS and, to a lesser extent, legacy SSL protocols. Implementation errors and protocol defects have been found in the past, and more will be found in the future. While they can result in security breaches, the overall trend is improvement.

From a risk management perspective, HTTPS provides one layer of security. Protecting sensitive information requires additional layers such as VPN and end-to-end content encryption. Issues in the HTTPS trust model and server implementations must be addressed.

Server impersonation is a significant issue. An adversary with privileged network access can redirect users to a look-alike web site. Selected components of web applications, such as javascript, can be targeted by selectively redirecting requests. These approaches require the adversary to obtain a certificate that matches the hostname of the impersonated server and is accepted by the victim’s PC.

Current web browsers recognize certificates issued by hundreds of Certification Authorities. A sophisticated adversary only needs to compromise one Certification Authority or, in the case of government agencies, obtain cooperation through court orders or other means.

On some operating systems it is possible for malware to install a Certification Authority certificate. For example, the SuperFish VirtualDiscovery adware that Lenovo shipped on some PCs installs a trusted root certificate. The SuperFish root certificate was used to enable a transparent HTTPS proxy on the local PC. The same approach could be used to install a certificate to facilitate server impersonation. In the future, more malware writers will likely seek to install their own root certificate on compromised PCs and a market for rogue certificates may evolve.

A more selective attack is to compromise the legitimate web site and steal the private key associated with the certificate. A dirty little secret of HTTPS servers is that private keys are almost always stored in plain text on the local file system. In most environments, web servers need to start automatically. While they key could be encrypted, the web server would still need to store the encryption key somewhere.

Some organizations offload SSL/TLS to a hardened appliance, but the vast majority do not. Some HTTPS servers access keys and execute web applications in the same security context, making it possible to target private key by compromising the web application. Adversaries may also target system administrators with malware to obtain server access credentials.

The cost of obtaining of certificates presents a barrier to widespread HTTPS adoption. A basic certificate for a single web site costs between $50 and $100 per year. By comparison, a domain registration costs about $20 per year and web hosting for small sites is available as low as $5 per month. It is unreasonable to expect a small site owner to spend more for a certificate than domain registration and hosting combined.

Extended Validation certificates are considerably more expensive, ranging as high as $1000 per year. Certification Authorities also charge significantly more for wildcard certificates, even though they follow the same verification and issuance procedure as certificates for a single server name. There is no reason that a certificate for * should cost more than a certificate for

One potential solution is to dispense with the existing certification authority model altogether and allow domain owners to publish certificate validation information using a mechanism such as DNSSEC. In some respects the existing certificate model evolved because of DNS security issues. Fixing DNS might be a better solution.

On the browser end of the connection, stronger controls are required on mixed content. Browsers generally warn users of mixed HTTP and HTTPS traffic, but they silently allow parts of the page to be retrieved from servers in different domains. Historically this made sense; a web page could incorporate images or other content from a variety of sources. That makes it easy to embed content such as videos and advertisements. The same mechanism can also be used to include mobile code and other active elements. While this may be acceptable for blogs and media sharing sites, it is not acceptable for sites dealing with personal information. A new high-security HTTPS mode is required in which the browser only communicates with a single server or domain.

Upgrading to HTTPS prevents passive data interception and denies criminals, service providers, governments, and other snoops the ability to hoover up data en mass. It is an important and valuable first step, but security issues in HTTPS must be addressed.

Have a security question you’d like answered in a future column? Email

Related posts