Whether it’s an Internet data center hosting web applications serving up millions of pages per day or a corporate data center hosting hundreds, if not thousands, of internal applications, nothing is more vital than the network connecting the users to those applications. We often take the network of routers, switches, and other technologies so for granted that we refer to it as the “dumb plumbing.” The notion of the network as plumbing is a testament to the reliability and performance we’ve come to expect from this part of the infrastructure. In general, the network “just works,” freeing us to focus on the upper layers of the stack which are often more complex and difficult to standardize.
With estimates of the growth of SSL up as much as 48% year over year, the traffic on that reliable network is increasingly encrypted. The growth of SSL encryption can be attributed to many drivers but most notably to privacy concerns arising from the revelations that the NSA and other government agencies are able to listen in on the majority of Internet traffic. Google, Microsoft, and others are using their weight to push for all Internet traffic to be encrypted. With SPDY and HTTP/2.0 encrypting web application traffic by default, it’s not unreasonable to expect that the vast majority of Internet traffic will be encrypted before the end of the decade.
Not only do we have explosive growth in encryption of Internet traffic, but IT organizations are also faced with the task of securing internal communications against eavesdropping. Zero trust model security is similarly being catalyzed subsequent to the Snowden revelations, which is affecting how we transmit data even on these closed networks. SSL or TLS encryption for intranet applications is already fairly commonplace but will grow even more rapidly than Internet encryption due to ready availability of self-signed certificates with little or no cost associated.
If most traffic on the Internet and organization intranets will be encrypted by 2020, then encryption must be as rock-solid and reliable as the routing and switching infrastructures that support our network plumbing today. However, at present, that is far from the case. Too often, we see Internet properties with poor SSL implementations that support weak forms of cryptography. The efforts of the Netcraft and SSL Labs have helped immensely in raising awareness around this issue. Even fundamental issues of certificate management and secure key storage have proven to be big challenges, with compromises attributed to private key leakage or outages due to certificate expiration still occurring.
Encrypted private network traffic is perhaps more daunting, since self-signed, untrusted certificates are so easily created and deployed. One of the more damaging effects of these untrusted certificates is users becoming accustomed to adding security exceptions to access sites signed with untrusted certificates. With intranet applications often outnumbering Internet-facing applications by a ratio of 10:1 or more, the problem of key and certificate management can be significant.
Establishing processes and systems for the effective management and secure storage of keys and certificates is a vital first step to implementing effective encryption of both public and private network traffic and introducing reliability to transport encryption. Solutions from vendors such as Symantec and Venafi exist for the management of certificates and keys at large scales, enabling proactive awareness of configuration errors, certificate expirations, and other key issues. These or other solutions will facilitate the creation of an internal Root Certificate Authority for the standard signing of any certificates for intranet traffic. Of course, establishing a policy and enforcing the process for certificate signing requests (CSR’s) is more important than what technology you choose. However, the benefit of more trustworthy encryption for your internal and external users is difficult to measure.
The next component of many key and certificate management strategies is secure key storage. Protecting the private keys is essential to preserving the integrity of encrypted communications, and many solutions exist to improve the security of how the private keys are stored. Thales and SafeNet are two leading vendors in the network-based Hardware Security Module (HSM) appliances. At one time relevant only in high-security or FIPS-compliant environments, heightened awareness of secure key storage due to vulnerabilities such as Heartbleed has many IT organizations considering the adoption of HSM solutions.
The last piece of the solution for establishing reliable encryption across your organization will be identifying your SSL termination points. This process is facilitated greatly by effective key and certificate management as outlined above. Ensuring that these endpoints support protocols such as PKCS#11 and Key Management Interface Protocol (KMIP) is important, as these standard APIs are vital to integrating your termination points with both Key/Certificate Management solutions as well as HSMs. More importantly, it is at the termination endpoint where the SSL/TLS vulnerabilities such as Heartbleed, BEAST, or others may be exposed and exploited. Routine maintenance of these encryption endpoints should include a review of ciphers and protocols supported to ensure minimum vulnerability exposure.
Tools such as SSL Labs’ Pulse can simplify the task of evaluating Internet-facing implementations and identify weak spots as best practices evolve. In order to meet best practice standards, encryption endpoints must possess both high performance as well as diverse cipher support. Performance prevents encryption from becoming a bottleneck or potential DoS-attack surface. Cipher diversity enables the selective disabling of weak ciphers such as RC4 and preferring new standards such as Diffie-Hellman Ephemeral (DHE) to support Perfect Forward Secrecy (PFS). As the ultimate and most visible enforcement point of encryption policy, the encryption endpoint should be easily configurable to ensure that the SSL handshake is as secure as possible.
In conclusion, SSL encryption must be as reliable as the networks it depends on. When SSL is implemented poorly, we expose our data and users to unnecessary risk, and our application resources to possible compromise or outage. In the all-encrypted future, centralized management of certificates and keys, secure key storage, and robust endpoint termination are the three pillars of ensuring transport encryption with the reliability and trustworthiness we must demand. However, we must integrate across these pillars, establishing a Public Key Infrastructure (PKI) for both internal and external resources.
[su_box title=”About Brian A. McHenry” style=”noise” box_color=”#0e0d0d”]
As a Security Solutions Architect at F5 Networks, Brian McHenry focuses on web application and network security. McHenry acts as a liaison between customers, the F5 sales team, and the F5 product teams, providing a hands-on, real-world perspective. Prior to joining F5 in 2008, McHenry, a self-described “IT generalist”, held leadership positions within a variety of technology organizations, ranging from startups to major financial services firms.
Twitter: @bamchenry[/su_box]
As a Senior Security Solutions Architect at F5 Networks, Brian McHenry focuses on web application and network security. McHenry acts as a liaison between customers and F5 product teams, providing a hands-on, real-world perspective. He is a regular contributor on InformationSecurityBuzz.com, a co-founder of BSidesNYC, and a speaker at AppSecUSA, BC Aware Day, GoSec Montreal, and the Central Ohio Infosec Summit, among others. Prior to joining F5 in 2008, McHenry, a self-described IT generalist, held leadership positions within a variety of technology organizations, ranging from startups to major financial services firms.
The opinions expressed in this post belong to the individual contributors and do not necessarily reflect the views of Information Security Buzz.