Visibility and control over SSL traffic in an era of HTTP/2.0
F5 “SSL Everywhere” architecture is centered on the custom-written SSL/TLS stack that is part of every F5 BIG-IP deployment. This enables F5 to have the visibility and control over SSL/TLS traffic in the era of HTTP/2.0.
Why is the visibility and control of SSL/TLS traffic so important? Only a decade ago, SSL was reserved for financial institutions and some specific organizations like public sector agencies for the log-in pages of security-conscious web sites and services. Today this has been expanded to most web-based services, and is quickly becoming the de-facto protocol for communications. Based on industry research from Gartner, more than 50 percent of the world’s Internet traffic will be encrypted by the end of 2015.
TLS today offers a paradigm shift in which companies approach IT networks, as it offers communications security over a network server. The connection between client and server is private because symmetric cryptography is used to encrypt the data transmitted.
Visibility and control over SSL/TLS traffic in HTTP/2.0
With the growing use of encrypted traffic, the traditional approach of depending on firewalls, intrusion protection systems and intrusion detection systems has become obsolete, as these devices will be blindsided without knowing the data stream that is passing through it.
The solution to this problem is to have the initial SSL decryption take place at the security perimeter. However, most solutions available within the industry working at the security perimeter are not been designed or developed for the specific purpose of “SSL decryption”. While some might have the capability to decrypt, they are not able to do so adequately. Many enterprises are also experiencing significant performance drop when they enable SSL decryption. This started a quest to explore “how” they should design their perimeter incorporating optimized handling of SSL traffic. Obviously, to maximize the efficacy of layer 7 security devices, the SSL decryption has to be executed near the security perimeter. Once the inbound SSL has been decrypted, the resulting requests can be analyzed, modified, and steered.
SSL cipher
Cybercriminals often attack by using SSL to bypass security devices, knowing those devices are security loopholes. Malware hidden within SSL traffic could also easily bypass security platforms. Gartner also estimates that by 2017, over 50 percent of attacks on the network of enterprises will use SSL to bypass security.
With the discovery of more vulnerable cipher suites that produces attacks like Heartbleed, BEAST, POODLE, and more, security administrators have a short time window to fix vulnerabilities. Having to manage hundreds or thousands of SSL fronting servers would take weeks to fix while they remain susceptible to attack from malicious sources.
It becomes a question of knowing what traffic to decrypt. If a business is serving content to users externally, it needs to use a device to offload SSL traffic from the server and then insert protection into the traffic flow. This will break the SSL, but in an intelligent way - you do not want to decrypt a banking session but you do for a Facebook session. Security needs to have the intelligence to understand where the traffic is going and then make a decision on whether it should be decrypted or left as it is.
While SSL technically supports users to achieve security from point to point, it does not necessarily secure the entire traffic. SSL could be intercepted by hiding malware in the encrypted traffic without faking an SSL certificate. Therefore the major focus for IT is to inspect the scams in real time and mitigate them immediately.
F5’s full proxy architecture enables conversion and decryption seamlessly, while implementing separated connections for both internal and external communications. The ability to terminate SSL sessions also make it easier for IT to use encryption for traffic in the outside and utilize the old HTTP if they need to. All connections will be possible and IT will not have to break and replace the whole web application infrastructure to enjoy the benefits of HTTP/2.0.
Keep the performance while managing TLS configuration
With the adoption of stronger key lengths, from 1024 bits to 2048 bits, computational requirements have increased exponentially from four to eight times that of the previous. This decreases performance on the existing infrastructure that has to handle a similar traffic size. Having specialized hardware together with a hardware accelerator will alleviate the need to upgrade CPU resources across the entire server farm.
With PCI DSS 3.1 mandating companies to stop using SSL and TLS 1.0 by 30 June 2016 in favour of more recent TLS implementations, companies will need to comply with all devices having a centralized SSL management point that will allow issues to be rectified within minutes across the entire environment.
Document references: