I am installing an SSL accelerator module to work with the CSM. I have come up with different ways for the server to determine if a request requiring encryption actually passed through the ssl module, but would like to know the best practice or most common way of setting this up.
If header insertion is the most common, what is recommended to insert into the header, and how would the server be instructed to accept or deny the request depending on the header information on a page per page basis. The web site is using IIS.
I have also considered changing the name of all pages requiring encryption to something that could be matched with wildcards in a url map and use in L7 policies directing those pages to 443.
Any thoughts would be appreciated.
what's the goal of your request? Do you need this to make sure that every redirect request is still a https request issued by the client or what is the prupose of your request?
If this is the case you can use normal ssl-module tools and do normal url rewriting so that a http redirecet stating, please move to http://www.foo.com/newpath/newpage.html will look like please go to https://www.foo.com/newpath/newpage.html.
(see http://www.cisco.com/en/US/partner/products/hw/modules/ps2706/products_data_sheet09186a00800c4fe9.html#wp1002173 table 1 the row with URL Rewrite). If I'm correctly informed this rewrting feature was introduced in Software version 2.1.
Thanks for your reply.
I am using the url rewrite feature and it does work well.
My question put another way:
when a server is receiving port 80 traffic from both users directly and the SSL module after unencryting SSL traffic, what is the best way to set up the SSL module and server so the server can determine if the request to a page requiring SSL encryption passed through the SSL module and did not come directly from the user in clear text across the internet?
The server would have pages not requiring encryption across the internet listening on port 80, as well as, pages requiring encryption across the internet also listening on port 80(because SSL is offloaded).
I have come up with a few ways to do it, but wanted to know if there was a 'best practice' for this setup.
I can think of two ways:
First do a certain SRC-nat for traffic that comes from the SSL-Module by using a different Vserver on the CSM for traffic headding towards the servers coming from the SSL-Module than the vserver which is used for traffic to the server which are accessed directly from the Internet. This enables you that you know that this was a request decrypted by the module or a direct access.
Second address a different serverport which offers the same content as port 80 (i.e. 81) so you know that traffic comming from SSL_Module hits 81 and every other traffic hits 80.
Both possibilities are having some boundary limitations but I think that they are quite straight forward and easy to maintain.
Thanks for your reponse.
Those were two of the ways that I had thought of as well. Neither one was acceptable by the web admin though.
Here are two other ways I had considered to do this for anyone watching this post for information:
1. http header insertion
2. rename all pages requiring encryption such as /_webpage.html. Then I could policy switch on the CSM using wildcard url maps.
To SSL module
Directly to server
Is anything needed at all ?
For L3 and L4 rules, the 2 flows are setup upon receiving the SYN.
So the response from the server will simply be forwarded where it came from - client or ssl.
If using L5 rules, the CSM will respond to the SYN using its routing table. So I'm not sure how the CSM will know client x.x.x.x is the client or the SSL module.
I think you should test your solution before implementing. Or did you try it yet ?
I also do not understand what is the concern of using a different port on the CSM to make the distinction between client and ssl traffic ?
This would not require any changes on the server.
There was a question in all of this. I was looking to find out the 'best practice' / most commonly implemented way of doing this.
Yes, I have tested the solution and it does work. It's a L7 policy.
I don't want to take up any more of your time. I do appreciate your replies.