Encrypted malware vs. F5's full proxy architecture

Everyone knows that malware is a huge problem, and several recent studies (including one by our very own F5 Labs research center) have shown that nearly half of all malware is now encrypted.   So, if all this malware is encrypted, then how do you go about finding it and stopping it if you can't even read it?  This problem is critical to the security of web applications today and will be even more critical in the future as encrypted Internet traffic becomes more pervasive.  

There are two basic scenarios in which to categorize this situation:  1) inbound encrypted malware, and 2) outbound encrypted malware.  What I'm calling "inbound" encrypted malware is when an attacker sends malicious traffic to your webserver in order to infect the server and/or a user accessing that server.  The "outbound" encrypted malware is when a user in your organization visits an infected website and ultimately infects his/her computer with the malware from that infected site.  Admittedly, the "outbound" encrypted malware situation is a huge problem and needs to be addressed, but for the purposes of this article, we will look at the "inbound" malware problem.  

When you configure a secure webserver (one that uses encryption), you have to generate and store the keys that are used for encryption.  Those keys can be stored on the webserver itself, or they can be stored on a separate proxy device.  Many organizations choose to use a proxy device because it is typically custom-built to handle cryptography operations much faster than standard webservers.  This "handing off" of the crypto keys is called SSL offload.  F5's BIG-IP is the best in the business at this.  I won't go into all the marketing chatter about it, but suffice it to say, the BIG-IP is really, really good and fast at this.  The SSL offload not only provides a faster encryption experience, but it also allows for a strategic point of control over your web traffic.  

The F5 BIG-IP also employs a full proxy architecture that allows full visibility of every single request to your web applications.  When a user sends an HTTP request to your web application, the BIG-IP accepts that request on behalf of your webserver (in fact, the end user thinks he is talking directly to the webserver but he's really talking to the BIG-IP) and then tears down the request from layer 7 all the way down to layer 1 and then rebuilds the connection from layer 1 all the way back up to layer 7 before sending it on to the backend webserver.  This is called a "full proxy" architecture because it establishes two completely independent connections...one with the client and one with the backend server.  The reason this is important is that it allows the BIG-IP to inspect every single part of that request at every single layer to make sure it is legitimate traffic.  If it's malware, the BIG-IP can reject it before it ever gets to the webserver.  Check out the following diagram that shows the flow of the full proxy architecture:

 

 

The full proxy allows for many other cool things as well (like using iRules to modify traffic in realtime at wire speed), but for the purposes of this discussion, it allows for the complete inspection of your traffic to ensure malware never reaches your webservers.  By offloading SSL/TLS encryption onto the BIG-IP, you move the encryption point away from your webservers and onto the BIG-IP.  From a BIG-IP configuration standpoint, you do this via the SSL profile where you actually load the encryption keys, certificates, etc.  You can actually have one unique profile for the client-side connection and another, separate one for the server-side connection.  This is cool as well because you can use two totally different encryption strengths, keys, etc for each side of the connection.  Because the BIG-IP holds the encryption keys, it will decrypt all the web traffic and then have the ability to inspect the clear text traffic.  Prior to decryption, there would be no way to feasibly inspect the traffic.

When you offload all your SSL/TLS traffic onto the BIG-IP and let it inspect each request at every layer, you can free up your webservers to do what they do best...serve up those amazing web applications that we all love!  Also, when an attacker sends encrypted malware to your webservers, the BIG-IP will decrypt it and stop it before it ever reaches your servers.

 

Related Resources:

• SSL Ciphers Supported on BIG-IP
• SSL Profiles on BIG-IP (10-part article series)