How to avoid the next SSL vulnerability outbreak

Since the Heartbleed vulnerability was publicly disclosed in the beginning of April, IT administrators around the world have scrambled to patch web servers and to inspect and update their firewalls, mail servers, SSL VPN equipment, and just about every other device on the network that uses SSL.

There are two reasons for the rush. First, the Heartbleedbug has affected many popular websites to the tune of 17% of all SSL-enabled web servers worldwide, according to a survey from Netcraft, a UK-based internet services company. Secondly, the vulnerability is very dangerous. Today, about two-thirds of the world’s Websites useOpenSSL 1.0.1, the encryption library affected by the Heartbleed bug, putting at risk more than half a million trusted websites. The flaw allows remote attackers to view up to 64 kilobytes of memory on a vulnerable server.

As a result, the vulnerability compromises the integrity of SSL encryption. According to, the Heartbleed bug “allows anyone on the Internet to read the memory of the systems protected by the vulnerable versions of the OpenSSL software…This allows attackers to eavesdrop on communications, steal data directly from the services and users and to impersonate services and users.”

Worryingly, OpenSSL is not alone.Security gaps have been discovered in virtually every widely used SSL library. A keyword search for OpenSSL in the US National Vulnerability Database website revealed 152 Common Vulnerabilities and Exposures (CVEs). In June 2013, former US National Security Agency (NSA) officer Edward Snowden revealed the NSA had used many different ways to snoop on citizens, including decrypting encrypted communications. In fact, the Snowden leaks indicate the NSA decrypted data had been encrypted with weak or even intentionally flawed encryption algorithms, and encryption algorithms are not infallible. With risks like the Heartbleed issue and insecure Dual_EC_DRBG number generator—developed by the NSA—organizations need to carefully evaluate the SSL implementations of their servers, networking devices, and application delivery controllers (ADCs).

Shield Your Vulnerable Infrastructure

One reason IT administrators are struggling to deal with Heartbleed is that they have to assess and patch a tremendous number of applications. With many applications running on different operating systems with different SSL libraries, administrators must spend several hours testing, patching, and retesting their applications.

An easy way to safeguard vulnerable applications and avoid similar fire drills in the future is to terminate SSL traffic on ADCs. Offloading SSL traffic with ADCs not only reduces the load on application servers, but lowers the cost of managing and updating SSL libraries. Administrators do not have to manage SSL certificates on each individual server, making it possible to eliminate the burden of patching all of their individual servers in the event of an SSL vulnerability outbreak like the Heartbleed issue.

Ensure SSL Implementations Are Secure

When offloading SSL traffic with ADCs, it is important to ensure that SSL implementations are secure and they do not include vulnerable versions of OpenSSL. Leading ADC vendors are striving to deliver secure, tested, and validated SSL encryption, and apply best practices in network security in every step of product design, development, and testing, so their products will not be impacted.

Achieving security certification is a good indicator of vendors’ efforts. To demonstrate that products meet recognized benchmarks for security and functionality assurance, vendors have to submit them to standards laboratories for evaluation so that they can achieve Federal Information Processing Standard (FIPS), Common Criteria, Joint Interoperability Command (JITC) certification, or other certifications. While such certifications do not prevent products from falling victim to a zero-day SSL vulnerability, they ensure that certified products meet stringent cryptographic design and implementation requirements. This evaluation process reduces the risk that attackers will uncover vendor-specific vulnerabilities in the software and hardware.

For example, FIPS certification entails in depth testing of SSL key management, SSL roles, services and authentication, protection against attacks, and many other software and hardware requirements. In other words, achievement of such security standards assures that their products meet exacting SSL security requirements that are available.

Be Ready forPhysical Attacks

Besides cyber-attacks and software vulnerabilities, organizations must consider physical threats, such as thieves or malicious insiders that might try to physically tamper with equipment to access digital keys.

To protect their devices from physical attacks like tampering and bus probing, many ADC vendors offer hardware security modules (HSMs) on select models. They typically protect SSL private keys and provide a physical assertion on access, while some of them can also deliver performance and FIPS certification. In addition, HSMs offer the benefit of being tamper-resistant, which allows administrators to know if their network appliances have been compromised or powered on or off.

By deploying advanced ADCs which enable SSL offload and are installed with HSM cards for secure SSL key management and tamper-resistant features, IT professionals can avoid the risk of an SSL vulnerability outbreak, and be able to concentrate on their key business goals.

Hayato Koeda is Asia Pacific Japan Vice President, A10 Networks, Inc.