SSL And Beyond, Part 3: Securing the Future

In our previous installment, we considered how the various kinds of SSL certificate are deemed compatible with a range of web browsers, applications, and operating environments.

To conclude this series, we’ll look at how SSL and TLS may be deployed in the future, and the spread of SSL/TLS-based encryption into the mainstream.

Why Should SSL Matter to Me?

These days, everyone with an internet connection transmits sensitive information of one kind or another. With personal data, credit card details and the like moving through unsecured channels, it’s no longer just big corporations and governments that have to worry about some or all of that information being intercepted by unscrupulous third parties.

Information is most vulnerable when it’s moving between systems, and the encryption offered by SSL (Secure Sockets Layer) and its successor TLS (Transport Layer Security) is currently the best defense for that data while it’s in transit.

The Scope of The Threat

The allegations raised by the whistleblower Edward Snowden in 2013 ­– that government intelligence agencies across the globe were and are gathering reams of sensitive data from the phone and email communications of rival agencies, corporate bodies, and citizens alike – brought the security problem to light.

Ciphertext or encrypted data from emails and digital communications was included in the haul of intercepted information, along with the metadata from mobile phone calls. Though it would be tough to crack the encryption used in these messages now, an organization with time on its hands may gain hold of the keys needed to decrypt it in the months or years to come.

But there’s more to it than that. Cybercriminals continue to target individuals and organizations using a variety of techniques:

  • False links, spam emails and phishing attempts are used to lure people to fake websites that are deliberately designed to look like the real sites that people normally visit.

  • So-called “man-in-the-middle attacks” occur when information moving between clients and web servers is intercepted and used to steal login details and user accounts.

  • Domains can be “spoofed” or tampered with, allowing cybercriminals to monitor exchanges and send emails to targeted users.

  • Using various ruses (email attachments, booby-trapped links, etc.), malware can be installed on a targeted system, unwittingly turning it into a bot, which may be used in the activities of criminal networks.

For an organization, the damage from falling victim to these attacks may extend to a loss in consumer confidence and an erosion of trust in the validity of their website.

The Zero Trust Model (ZTM)

ZTM is a network security strategy first proposed by analyst John Kindervag of Forrester Research. As its name suggests, the Zero Trust Model presumes that each element of a network distrusts every other element. All data passing between devices is assumed to have slipped through whatever security nets are in place.

So at each stage, it’s imperative that data which is being transmitted should be secured as it’s in transit. Which means SSL or TLS comes into play.

In the ZTM, a so-called “network segmentation gateway” regulates device availability and security over a web of high-speed links giving access to various zones of the network. Each device must gain insights into packet data, and have access to application layers. This data must first be decrypted, and then encrypted again, once the device has done its job. This re-encryption of SSL data is gaining popularity in wider circles.

Certified Truths

SSL and its visible signs are indicators of trust to the user community.

The HTTP Secure (HTTPS) protocol merges the standard HTTP with Secure Sockets Layer, and presents in the address bar of a user’s browser. Behind the scenes, the “https” prefix results from a website having been authenticated on presentation of a valid SSL certificate. Moreover, communications between its server and a client’s machine are being securely encrypted.

A green coloring on the first part of an address bar denotes the use of an Extended Validation (or EV) SSL certificate, by the web server. This indicates that the site owner has gone the extra mile to ensure confidence by submitting their organization to more intensive vetting and validation procedures. These guidelines have been laid down by the CA/B Forum.

An EV-certified site will also display more information about the business verified to use that web address, and the Certification Authority (CA) which issued the certificate.

Watching the Watchmen

CAs aren’t perfect, and may need help to maintain a strong measure of SSL security. The Open Web Application Security Project (OWASP) publishes a best practices guide, for SSL operations. Among their recommendations are diligent hardware monitoring and network security measures, methods of authenticating the ownership of domains, ensuring regular independent audits, and the use of hardware-based systems for signing SSL certificates cryptographically.

For system administrators, the SSL Labs project provides tools for testing and evaluating the security of websites and their associated servers. Part of their focus is on making sure ciphertext remains unreadable long into the future, and best practices for protecting and storing encryption keys.

The Future Perfect

Perfect Forward Secrecy (PFS) is a passive surveillance feature recently added to SSL that puts an extra layer of security on the exchange of messages when a client and server try to establish their encryption key protocol. PFS can be activated by a cryptographic cipher contained within the SSL termination device. Once set, it becomes very difficult for a hacker to gain access to the key needed to decrypt any previous communications.

Some Government Backing

In March 2015, the Obama administration announced a proposal for SSL to become standard practice for federal websites. “The HTTPS-Only Standard” initiative was issued by the CIO Council (a think tank composed of the CIOs of various federal institutions), and will (if it becomes law) “require the use of HTTPS on all publicly accessible Federal websites and web services”.

HTTPS Everywhere? Not yet…

In 2010, the Tor Project and the Electronic Frontier Foundation produced a browser plugin dubbed “HTTPS Everywhere”, initially a Firefox extension. Once installed, the utility would automatically select the encrypted (“https”) version of any website you visited if one was available. This meant secure browsing with reduced hassle.

Sadly, the major manufacturers have yet to include this behavior as standard in their browsers.

HSM: Guarding Against Heartbleed

In 2014, a serious error in the “heartbeat” code of the popular OpenSSL software library was uncovered. Dubbed “Heartbleed”, it had the potential to quietly feed the contents of a device’s memory to a malicious user. At the time of its discovery, Heartbleed had been in place for over two years – enough time for private encryption keys and administrator login details to have been siphoned off much of the web.

From then until now, SSL users who employ FIPS 140-2 Hardware Security Modules (HSMs) were safe. An HSM is built around a cryptographic core and an encryption key store, as a separate hardware and software layer of added security. Keys are confined to the store (not transferred into memory on a network host), and are not vulnerable to Heartbleed leaks.

Though they can be expensive, HSMs are now being used as centralized key stores, making encryption services available across an organization’s internal network. Network-attached HSMs (netHSMs) are active in remote data centers and private clouds, allowing decryption services to be ported across the global reach of an enterprise.

Public netHSM (a.k.a. CloudHSM) devices are increasingly being deployed on public clouds, often in conjunction with Application Delivery Controllers, to filter encryption requests between them.

‘Freak’ Shows…

Hot on the heels of the Heartbleed, Shellshock and Poodle scares, many organizations invested heavily in the Linux Foundation, whose OpenSSL provides a variant on the original SSL technology. The “Freak” bug, which later came to light, threw even this alternative into doubt. But it’s not as bad as all that.

Freak affects Apple’s Safari browser on the iPhone, iPad, desktop Macintosh, and on the internal browser supplied with Android systems. Firefox, Internet Explorer and Google Chrome are unaffected however. As so many users have more than one browser installed, the actual risk of their data being intercepted in transit is low. Existing SSL certificates will not have been compromised and remain valid.

The Freak incident demonstrates the importance of having alternatives, and can teach us other lessons as well.

The bug derives from the U.S. government’s long-standing policy of imposing restrictions on the export of strong encryption technology. When SSL emerged in the 1990s, it was limited by law to an encryption key length of 512 bits. Freak allows some browsers and web servers to downgrade their encryption strength until a client can make a connection.

The problem is exacerbated by web server configurations, which allow the use of so-called export grade (i.e. lower strength) encryption ciphers. These often tend to be called into action by older machines running legacy versions of browsers. As we move into the future, the trend should be towards increasing levels of encryption strength – and making encryption facilities more widely available.

Consider the Cloud

An organization using the cloud for data and application storage needs to ensure the safety of its data in transit. Credit card details, health records, and sensitive personal information require protection if they’re to be moved off site. SSL/TLS encryption and validation can address some of these concerns, but there are issues specific to cloud service provision that have to be considered.

Service level agreements (SLAs) need to specify that the cloud provider should use SSL encryption – preferably strong 128-bit or higher. There are also requirements for regulatory compliance, especially where secure e-commerce transactions are concerned.

SSL certificates may need to cover multiple domains under a single IP address, and allow for frequent updates, as cloud applications evolve and storage needs change. Cloud service providers must also be affiliated with trusted Certification Authorities, which will not issue certificates to servers in prohibited countries or store data in web servers located in those areas.

The “Let’s Encrypt” Initiative

This is an online resource, a free, open, and automated Certification Authority, backed by the Internet Security Research Group (ISRG), a public benefit corporation based in California. The “Let’s Encrypt” Initiative was launched by the Electronic Frontier Foundation, a non-profit organization and digital rights advocacy.

Purchasing a strong and legitimate SSL certificate may be beyond the means of individuals and small businesses. Setting one up can prove just as daunting. Even IT professionals in large firms can expect to spend at least an hour referring back to Google and all the sources necessary for certificate validation. Then there’s certificate maintenance and renewal.

“Let’s Encrypt” installs as a small utility in your web server. Its back end contains a full Certification Authority. The procedure for generating and installing an SSL certificate takes about twenty seconds or less. And the utility renews and manages certificates automatically.

The initiative is due to launch in “mid-2015” (that’s any time from now), and already has strong backing from a consortium that includes Cisco and Mozilla.

ACME (Automated Certificate Management Environment): No Joke

Though it sounds like something from a Road Runner cartoon, the Automated Certificate Management Environment (ACME) is an integral part of and partner to the “Let’s Encrypt” initiative. It’s a protocol dedicated to setting up an HTTPS server and acquiring a 99+% browser-compatible SSL certificate without human intervention. ACME achieves this by establishing a certificate management agent on your web server.

On the server, your Let’s Encrypt-compatible (ACME) management agent first proves to the Certification Authority that your server actually controls a legitimate domain. A set of challenges are issued from the CA to verify this. Once validated, the agent can request new SSL certificates and renew them and revoke them as required.

The push from “Let’s Encrypt” and ACME is towards simplicity. If obtaining certificates for SSL encryption is made less complex then more people will be inclined to do it.

Impetus From Google

In August 2014, Google announced a change in its criteria for search rankings. Sites with valid SSL certification and HTTPS will now be placed higher on their lists.

The policy will be phased in gradually. At present, less than 5% of websites have achieved the HTTPS status needed to be bumped up the charts. But Google seems to be indicating that its filtering process will increase in strength and scope as time goes on.

SSL Everywhere?

That’s the plan. And if the “Let’s Encrypt” Initiative rolls out fully this year, we may see it start coming together.