Forum Discussion

Andrei_Bankousk's avatar
Andrei_Bankousk
Icon for Nimbostratus rankNimbostratus
Aug 06, 2006

Using BIP/iRule as SSL accelerator for non-web application

I would like to explore the possibility of using power of iRule and SSL acceleration to secure a non-web enabled application. Currenly the application consists of a client that connects directly to a bunch of servers on various different ports. The ideal scenario would be encrypting all these connections with SSL and terminating them on BIP using 1 IP address. Client side would pass a URL or some other piece of information to select what server a particular connection needs to be forwarded to. This piece of information that is used to select a server should not be passed to the server since there are too many server-side applications to be recompiled. The problem that I am running into is if I am using something like this:

 

 

when HTTP_REQUEST {

 

if { [string toupper [HTTP::method]] eq "CONNECT" } {

 

HTTP::disable

 

select appropriate server pool below

 

}

 

}

 

 

the whole HTTP request is still being passed to the server side. So the question would be is there another way to do this or a way to remove the header.

 

 

Using CLIENT_DATA event and TCP::payload works but it is still not perfect since the information that is used to select a server needs to be passed in clear.

 

5 Replies

  • Colin_Walker_12's avatar
    Colin_Walker_12
    Historic F5 Account
    Well, you can certainly use the HTTP::header remove command to remove any header that you don't want passed along to the server.

     

     

    For that matter, you could use the HTTP::header sanitize command to build a whitelist of headers, if there are only a couple you want to allow through.

     

     

    Does that answer your question?

     

     

    Colin
  • I want the whole request not to go to the server, only what client sends next should be passed. The request is only used by BIP to select a proper pool.

     

     

    Alternatively to using http requests, if there was a way to do something similar to TCP:collect and TCP:payload but for the data that already passed through SSL portion of BIP...
  • bl0ndie_127134's avatar
    bl0ndie_127134
    Historic F5 Account
    We just added a 'discard' option to the 'HTTP::disable' rule that throws away all the request data (which I think is what you are looking for). But this will only be available on the next release which is version 9.4.

     

     

    If you have version 9.2 or newer release, you might want to play around with the stream filter. I think you might be able to create a regular expression that matches the request but has an empty replacement string. I have not tested it so I can't guarantee that it will work. Sorry!
  • unRuleY_95363's avatar
    unRuleY_95363
    Historic F5 Account
    You probably don't want to use the HTTP profile as it will not be possible to completely remove the HTTP request headers (their necessary for HTTP to operate).

     

     

    Unfortunately, that doesn't leave you with a lot of options. We've been working to solve this problem in the upcoming 9.4 release. In the meantime, here are your options:

     

     

    A) Use the STREAM profile to wildcard match and trigger the STREAM_MATCHED event. You can then use the STREAM::match and STREAM::replace commands to simulate the TCP::payload command. You could then also use the STREAM::disable command to turn off the matching once you have found what you are looking for and connected to the back-end server. Alternatively, you could use the STREAM::expression command to change the search expression to whatever defines the end of the current request, so that you can break the connection and process the next request to another server.

     

     

    B) Create a loopback vlan and a second virtual. Then decrypt on the first virtual and do the TCP payload inspection/manipulation on the second virtual.

     

     

    In 9.4 we've added a "virtual

     

    I would give option A) a try first as this should do what you need. You'll just need to be a little cunning about it. I'd love to see what you come up with...

     

  • Thanks a lot for your response. A way to look into a decrypted traffic would certainly be a very nice feature. I will give option A a try, I need to read about STREAMS a little, since I do not really know what they are.

     

     

    Will there be any performance penalty associated with option B? Will the traffic be actually sent and then subsequently received on a piece of hardware or is it just some kind of a manipulation inside BIP software.