Forum Discussion

Kanghis_23583's avatar
Kanghis_23583
Icon for Nimbostratus rankNimbostratus
Feb 10, 2009

http to https redirect

This is a fairly common task: a shopping cart application requires us to secure the transaction. Without the big-ip in place, the flow redirects any request to http:/this.domain.com/this/directory to https://this.domain.com/this/directory.

I'm a complete neophyte when it comes to writing irules but have spent sevearl hours looking at examples and related threads. This much I know so far:

I've set up two Virtual Servers with the same IP; VS1 monitoring 80 contains the irule below which should redirect any requests for this.domain.com/this/directory to the VS2 monitoring 443.

My ssl rewrite is fairly straight forward:

when HTTP_REQUEST {      if { [HTTP::uri] equals "/this/directory/"} {         HTTP::redirect "https://this.domain.com/this/directory/"    }  }

VS2 (https://this.domain.com) is monitoring 443, has a client_ssl attached and is mapped to a pool with a single node also monitoring 443. On the backend webserver (apache) we have two virtual hosts; one node member is listening to port 80 and is mapped to pool1:80 and the other node is monitoring 443 and is mapped to pool2:443.

I am obviously doing something wrong because the url being returned is http://this.domain.com/this/direcotry/* and not https://this.domain.com/this/directory/*, page error notwithstanding.

Any help would be appreciated.
  • James_Quinby_46's avatar
    James_Quinby_46
    Historic F5 Account
    dmkang -

    I used the iRule Redirector Generator to create the following HTTP->HTTPS redirector:

     
     when HTTP_REQUEST { 
       HTTP::redirect https://[getfield [HTTP::host] ":" 1][HTTP::uri] 
     } 
     

    The generator can be downloaded from here:

    http://devcentral.f5.com/Default.aspx?tabid=169

    ...and is very useful for creating simple redirects, especially for new-ish users.

  • Here is a very generic approach, ripped right from the ask.f5.com solutions (SOL3847 to be exact). This one redirects all traffic to its https counterpart:

      
     rule redirect_rule {  
     when HTTP_REQUEST {  
     HTTP::redirect https://[HTTP::host][HTTP::uri]  
     }  
     }  
     

    The only difference here is that you want to do some basic URI switching (also note that you can accomplish a similar thing with an HTTP class profile, so you may want to check that option out as well).

    I think you may be looking for "contains" instead of "equals"; at the bottom of your post you indicate a "*", which tells me there's more stuff following '/this/directory/', which may not match exactly. I don't have a lab box handy but this should get you close:

      
     when HTTP_REQUEST {  
     if { [HTTP::uri] contains "/this/directory/" } {  
     HTTP::redirect https://[HTTP::host][HTTP::uri]  
     }  
     }  
     

    I hope this helps,

    -Matt
  • Thanks for you input. I should have added some additional information about the trigger that launches the https://credit_card_athorization_page.

    I'm passing query parameters when VS1 is redirected to VS2. I looked at the irule documentation and it appears that I should be using HTTP::query although there [getfield [HTTP::uri] ? 2] is the preferred method for retrieving the string following the "?"

    Having read that I modified the rule to look like:

    when HTTP_REQUEST {  
     log local0. "redirecting to https" 
     if { [HTTP::uri] contains "/this/directory/"} 
      {  HTTP::redirect https://"this.domain/"[getfield [HTTP::uri] ? 2]} 
     } 

    I'm not even sure this is correct but I'm still unable to generate a different behavior.

  • I may be missing something, but I believe that HTTP::uri will work for you: it represents everything after the hostname. From the docs, for this request:

      
     http://www.example.com:8080/main/index.jsp?user=test&login=check 
     

    HTTP::uri should return:

     
     /main/index.jsp?user=test&login=check 
     

    ...Note that you're snagging everything, including the bits after the "?". Check out the wiki and the examples here: http://devcentral.f5.com/wiki/default.aspx/iRules/HTTP__uri.html

    I believe that the stanza:

    HTTP::redirect https://[HTTP::host][HTTP::uri]

    Should work for you, or get you darn close.

    -Matt
  • Posted By dmkang on 02/10/2009 2:19 PM

    {  HTTP::redirect https://"this.domain/"[getfield [HTTP::uri] ? 2]}   
     } 

    If you're trying to protect the page submission (which is implied by mentioning the form parameters) then you're wasting your time here.

    By the time this connection hits your Big/IP the user has already submitted the form via (insecure) HTTP. All you're doing is saying 'oh, you should have submitted that form via (secure) HTTPS, so try again'.

    From the user's security standpoint they're already blown.

    You really need to catch the page before the form is submitted and make sure that the form is submitted securely in the first place (potentially by having the write rewrite the leading page to make sure the form action points to the secure URL.
  • The paramters being passed in the URI do not need to be encrypted for this exercise. At the moment, all I'm trying to encrypt is Credit Card informaiton. The paramters beign passed are used to identify the user. When the user clicks on the trigger button, a javascript call opens a window (window.open (http://mydomain.com/this/directory/page.asp?parameterid1+parameterid2) with the uri information passing the parameters as http://

     

     

    The LTM should offload the SSL and rewrite the page using the irule below and the resulting page should be encrypted for submission.

     

    when HTTP_REQUEST {

     

    if { [HTTP::uri] contains "/this/directory/"}

     

    { HTTP::redirect https://[HTTP::host][HTTP::uri]}

     

    }

     

     

    Unfortunately, the window insists on using http: so the irule is definitely not working. What other ways could I troubleshoot this. Everyone's help is appreciated but I could be doing more to help out my developers.

     

     

    Thanks again!