What does Google’s “HTTPS Everywhere” mean for Web Application Security

Druckfreundlich, PDF & E-Mail

This post was submitted by Product Manager Neeraj Khandelwal and is also published on our corporate blog here.

Google's recent announcement of boosting search rankings of HTTPS sites is welcome news from boosting the general security of the Internet. For example, it will force popular sites away from transporting passwords in plaintext. Undoubtedly, HTTPS is great to combat Man-in-the-Middle (MITM) attacks.

To cite an analogy, HTTPS is like an armored delivery vehicle going from point A to point B that secures it's passengers while in transit. It also ensures that the passengers are delivered to the right destination. However, just like the armored vehicle, it does not provide any guarantee for what you load into or take out from the vehicle. It could well be a live bomb, or your enemy itself in disguise…

Adversaries can use this to their advantage.

HTTPS can blindside traditional perimeter security

Brad Pitt and his team pose as Germans to get past heavily guarded German bases in The Inglorious Bastards.
If your adversary can’t recognize you for what you are, then their security is useless. HTTPS brings up a similar conundrum for perimeter security. Since the data is completely encrypted, traditional perimeter security solutions like firewalls, IDS/IPS, etc. have no way to tell if it is malicious. For your adversaries (attackers), it becomes easier to hide their attacks within HTTPS and target  your servers or applications.

This also works both ways: responses originating from the servers in the data centers can contain data leaks as well as malicious exploits targeting the users and perimeter security will fail to notice them. The HTTPS padlock in the browser's location bar only confirms the identity of the server, but will not prevent you from a watering hole attack.

This can often induce a false sense of security at the endpoints, the web server and the site visitors. As a webmaster, if you are transitioning from HTTP to HTTPS and you rely on non-proxy security solutions, you may in fact be inadvertently relaxing your security posture in the process.

Application Proxies can help Secure and Scale HTTPS 

In the checkpoint security example above, the checkpoint security needs to be equipped with a block list (these guys are definitely not allowed in) or better, with an allow list (a list of their own personnel with photos, etc.).

This is similar to what an application proxy like the Barracuda Web Application Firewall does. If you care about web application security, what you really need is an application proxy-based solution that can look inside HTTPS and keep out malicious data. This is done via SSL offloading – where the proxy decrypts and inspects the HTTPS traffic and communicates using HTTP with the protected servers (with an option to re-encrypt the data stream to them, if needed).

This ensures that all the encrypted traffic is thoroughly examined for malicious attacks or data leaks.

There are many other instances where a SSL offloading through an application proxy like the Barracuda Web application Firewall provides a lot of value:

  • Content Rewriting: Modern application security often required rewriting of legacy web applications on-the-fly, such as injecting response headers for HTTP Strict Transport Policy (HSTS) and click jacking prevention, injecting randomized tokens for CSRF prevention, cookie encryption, etc.
  • Securing weak SSL stacks: Old web servers often do not support the latest enhancements to SSL. An outdated SSL stack could have tons of vulnerabilities. Upgrading SSL on multi-vendor servers could be time-consuming, opening up threat windows. See more here.
  • Speeding up Application Delivery: Apart from security, other application delivery features also benefit from an application proxy that can offload SSL. For example, content caching and compression require the proxy to look inside HTTPS before it can cache or compress the content.
  • Reducing Load on protected Servers: HTTPS does require increased processing power, especially with 2048 bit keys. Older servers with weak hardware that were doing just fine with HTTP could struggle to keep up with the demands imposed by HTTPS. SSL Offloading to an application proxy offloads all the compute capacity challenges on to the proxy itself.
  • Making your HTTPS Future Proof: Without PFS (Perfect Forward Secrecy) ciphers, your HTTPS traffic captured today, could be decrypted in the future with powerful hardware of stolen keys. PFS prevents this, however, using PFS means that sniffer device based security like IPDS or span port based application proxies are useless since they can’t decrypt PFS communication.

Remember, if your servers were to suffer a breach, it would not matter if you are using HTTPS or not. The plunge in rankings (and the caution “this site serves malware”) in search rankings could be devastating to your business.

Nach oben scrollen