Re: HTTP to HTTPS redirects strange issue!!

sgonsalv · ‎07-02-2006

Hi Giles,

Have noticed a strange problem with HTTP to HTTPS redirects that i've setup for a customer.

BACKGROUND

- CSM is configured in routed mode

- The backend server is WebCT Vista, hosted on Bea Weblogic 8.1 and is written in J2EE so it's all beans.

- Both the HTTP and HTTPS paths individually work fine, without an issue. That is you can login, click on links and have the information you've requested displayed.

ISSUE

The strange issue i've noticed is that when i have the HTTP to HTTPS redirection in place, the following happens:

- point my browser to http://130.194.11.122

- the CSM replies back with a HTTP redirect (302), specifying that the new location is https://130.194.11.122

- The browser refetches the page by browsing to https://130.194.11.122

- I login fine

- I can click on some of the links without a problem (been told that they are relative links)

- However, with the other links on the page, after clicking on them, i get thrown back to the homepage again! Been told that these are absolute links.

TESTS

- i've setup my own servers and have not had a problem with the redirection setup, as all works as expected.

QUESTIONS/THOUGHTS

(I've attached a copy of the config that i've got in place for the WebCT test environment)

- Just wondering if you've come across a similar problem before?

- Does the config need to be altered at all?

To my mind the "refetch" performed by the browser should be treated the same as pointing my browser "directly" to https://130.194.11.122 - correct me if i'm wrong!

Considering this, you wonder why the server would treat a connection coming in after a redirect different to a direct connection?! Would this have anything to do with absolute and relative links?

Any insights would be most useful.

thanks

Sheldon

---------------------

serverfarm VISTESTSSLFARM

nat server

no nat client

predictor leastconns

real 172.16.11.11

inservice

real 172.16.11.12

inservice

serverfarm REDIR-FARM

nat server

no nat client

redirect-vserver REDVS1

webhost relocation 130.194.11.122%p

ssl 443

inservice

serverfarm FARM-VISTATEST

nat server

no nat client

predictor leastconns

failaction purge

real 130.194.13.244

inservice

real 130.194.13.245

inservice

real 130.194.13.247

inservice

probe VISTA-TCP-80

sticky 225 cookie JSESSIONID timeout 60

vserver VISTEST-SSLVIP

virtual 130.194.11.122 tcp https

serverfarm VISTESTSSLFARM

ssl-sticky offset 20 length 6

sticky 30 group 101

replicate csrp sticky

persistent rebalance

inservice

vserver VISTEST-DECVIP

virtual 172.16.11.101 tcp www

serverfarm FARM-VISTATEST

sticky 60 group 226

persistent rebalance

inservice

vserver VVISTA-TEST-80

virtual 130.194.11.122 tcp www

serverfarm REDIR-FARM

sticky 60 group 225

replicate csrp sticky

persistent rebalance

inservice

!

carenas123 · ‎07-07-2006

Check fixing arrowpoint-cookies

Gilles Dufour · ‎07-16-2006

there is no arrowpoint-cookie with the CSM, moreover this is SSL, so no cookies unless you have an SSL module to decrypt the traffic.

What happens is that the absolute path forces the browser to open a new HTTP connection which is redirected to HTTPS. Since this is a new connection, you need some form of stickyness to make sure the connection is sent back to the same server.

I see you have the ssl-sticky offset command but I think you still need to configure an ssl sticky group for this function to work.

Try also sticky based on source ip if adding the ssl sticky group does not solve the problem.

Gilles.

PS: sorry for delay - was on a GREAT vacation. :-)

sgonsalv · ‎07-17-2006

Hi Gilles,

(Yup! Holidays are great for recharing the batteries!)

You mention configuring an ssl-sticky group. Not sure if you missed it in the config, but I actually have this configured on the SSL VIP as below:

sticky 101 ssl timeout 30

vserver VISTEST-SSLVIP

virtual 130.194.11.122 tcp https

serverfarm VISTESTSSLFARM

ssl-sticky offset 20 length 6

sticky 30 group 101 <---- here

replicate csrp sticky

From my understanding this is required if there is more than one SSL module (which we have), and therefore ensures that the CSM always forwards

traffic from a particular client to the same SSL Services Module.

You may have noticed on the vserver VISTEST-DECVIP that i have cookie based stickyness configured:

sticky 226 cookie JSESSIONID timeout 60

vserver VISTEST-DECVIP

virtual 172.16.11.101 tcp www

serverfarm FARM-VISTATEST

sticky 60 group 226

persistent rebalance

inservice

To my mind, this should be sufficient to ensure that all connections are "stuck" to one real server for the duration of the session. Based on the TCP connections on the CSM i can verify that all connections are being stuck to one real server.

Are you suggesting that i should look at having source IP based stickyness applied to VISTEST-DECVIP, as a better way of making sure that the connections are stuck?

After doing some testing, when connecting directly to https://130.194.11.122, (not via a redirect), one of the things i noticed was that while the page itself is encrypted, and kept within the HTTPS domain, the links themselves are not secure (i.e they are http://...). Now, if all links are "relative" then this should not be a problem, because by default, all such links are encrypted by the SSL protocol. At the moment the users are kept within the secure domain by a URL rewrite performed on the SSL module.

Thoughts:

-------------

From what i can see, i've got stickyness in place, while I can try changing "Cookie based" stickyness to "source IP based" to see if that changes results as mentioned above. However, having noticed the links on the page themselves, i tend to think that the issue here is with the links themsleves, which should be:

- either all relative, or

- if they are absolute, the domain specified should be "https"

Do you agree - what are your impressions?

thanks,

Sheldon

Gilles Dufour · ‎07-17-2006

sorry - didn't see the sticky 101 line.

Could you verify the decrypted traffic [capture a sniffer trace] and verify if the cookies are there.

If you can't find anything wrong in the trace, could you send it to me.

Thanks,

Gilles.

sgonsalv · ‎07-18-2006

Hi Gilles,

I've attached a copy of an ethereal trace from my machine (client). This is a trace of me (192.168.0.2) connecting to http://muso-staging.monash.edu.au (130.194.11.122).

From looking at the traffic for all the HTTP transactions, i can see the cookie in the header, although it looks like the real servers are also adding their own cookie: JESSION_ALTERNATE. To me the traffic appears to be normal. Further as evidenced by the CSM TCP logs (attached), i noticed that i was stuck to 1 of the 3 real servers (130.194.13.245). In case you are wondering, my IP in the CSM logs is my real world IP (144.132.44.114), since these are tests from home/boardband.

As far as a trace of the "decrypted" traffic per se, that is, traffic to and from the backend server itself, i'll get the server Admin to get me a copy of this.

Just as an aside, the Application vendor mentioned that ideally session persistance should be setup using the "Offset/length sticky" function, where this feature adds enhanced support for Java 2 Platform, Enterprise Edition (J2EE) based applications such as BEA WebLogic. At the moment the cookie that is set is done by using the "cookie insert" function, since the CSM code we are running is 3.1(4).

(We will be looking to upgrade to a safe harbor code 4.2 later this year)

thanks,

Sheldon

Gilles Dufour · ‎07-18-2006

Sheldon,

the trace you provided is when doing HTTP - not https.

If I understand correctly, it works find with HTTP.

The problem is only with HTTPS - correct ?

Gilles.

sgonsalv · ‎07-18-2006

Hi Gilles,

Correct, the problem only appears when connecting to HTTPS:// via a redirect from the CSM. I'll grab these traces, i.e. the traffic to and from the real server (decrypted) from the Application admin.

I attached the previous traces just to show how the HTTP path operates...although it isn't entirely relevant here.

Sheldon

sgonsalv · ‎07-18-2006

Just had a couple of things to add to my previous reply:

1. Looking at vserver VVISTA-TEST-80 i've noticed that i have a sticky group in place (cookie: JSESSIONID). Not sure if this would make a difference, but i think this isn't really required, and probably just complicates things?

vserver VVISTA-TEST-80

virtual 130.194.11.122 tcp www

serverfarm REDIR-FARM

sticky 60 group 225

replicate csrp sticky

persistent rebalance

inservice

2. WRT to links that "throw you back" to the login page, here is some info on what happens in the backend:

- when a client clicks on these link, based on their username specific information for this student is gotton from another server (not part of the serverfarm)

- this info is brought back to the real server dealing with the client request

- the info is imbedded / formed into a page that makes it look like the information is local to the server

- this is sent back to the client

Sheldon

steve-hong · ‎01-16-2007

what does the "sticky 225 cookie JSESSIONID timeout 60 " do? Does it look into the http header for the JSessionID string and use that parameter for sticky?

thanks,

Steve

sgonsalv · ‎01-16-2007

The statement "sticky 225 cookie JSESSIONID timeout 60" applies or inserts the cookie JSESSIONID on behalf of the server, so that cookie stickiness can be performed.

Cheers Sheldon

sgonsalv · ‎01-16-2007

I should add that this issue i initially posted was solved by simply changing the relocation string from 130.194.11.122 to the actual hostname of the service instead, i.e. muso-staging.monash.edu.au (in this case)

For some reason the redirection didn't work well when using the IP address.

Sheldon