You also may have a hard link in your code pointing directly to an http link. In other words, your site partially bypass your ssl module. Maybe you can highlight it by creating new services and content rule where you will redirect your decrypted flows. I mean for example :

content WebSphere-test

advanced-balance sticky-srcip

vip address 10.241.100.1

add service newserv1

add service newserv2

protocol tcp

port 50000

sticky-inact-timeout 180

active

ssl-server 10 cipher rsa-with-3des-ede-cbc-sha 10.241.100.1 50000 weight 5

ssl-server 10 cipher rsa-with-rc4-128-md5 10.241.100.1 50000 weight 3

ssl-server 10 cipher rsa-with-rc4-128-sha 10.241.100.1 50000 weight 4

When connecting through SSL, you should not see "normal" services counters increase.

That's just an idea...

David

Hello

Thank you both for your advice.

I tried both approaches but I had no luck. First I wrote a few rules to rewrite whatever redirect there could have been but no one was detected.

After a while, by chance I ended up getting a message stating too many sessions were open and that was a redirect which I was able to keep inside the tunnel following Gilles' instructions.

I kept trying to find a redirect but I couldn't so David's idea was next.

According to what I could see from a capture, I wrote a few content rules and redirect services on an attempt to match any of the URLs that were there but again very little changed.

I keep seeing a "secure and no secure content" message instants after the second window opens up. Could then the redirect be inside the flash code? Is there anything that can be done to overcome it?

In general terms can Flash be load-balanced?

If you have a moment to go over the capture, I'd be very grateful.

Remember this is a one-armed scenario so the site is accessible either through the CSS or directly to the server. Both direct HTTP (port 9081) and CSS-based SSL traces are attached.

Thanks a lot

Guido

Guido,

the object that appears in cleartext is

"/bantotal/servlet/com.dlya.bantotal.afrgetusrmnucode "

And we can see a referer that is :

Referer: http://10.239.101.111:9081/bantotal/servlet/realIndex.html

This object was also requested by the client but it received a 304 not modified from the server.

So we do not see the content of the object.

I would suggest to clear the cache of your browser, and then re-do the same test.

SSL and cleartext capture.

Try to capture front-end and backend at the same time.

Since this is one-armed it should be easy.

It will allow us to see the response from the server in clear, before it gets encrypted.

Gilles.

Gilles

Thanks for your support.

I see. I missed the redirect but... I keep thinking that the rules I wrote should have recognized the string and taken action upon it.

Anyhow I was able to list every object that gives form to the site and made a list out of them. Is it right to assume that a few rules that match a string, common to each object, would solve this? For instance “ssl-server 10 urlrewrite 1 */bantotal/*” and to be on the safe side “ssl-server 10 urlrewrite 2 */bantotal/* sslport port 443 clearport 9081”.

On the other hand I'm going to do what you suggested though I'm not sure what you meant with "front-end and backend at the same time". Did you think 2 PCs one to sniff while requesting HTTPS and the second one sniffing the back-end side of the conversation?

Thanks a lot and please stay tuned :)

Guido

Guido,

your problem is the client browser reporting that you are changing to a non-secure page.

There are only 2 possible reasons for that.

1 - the server sent a redirect to a cleartext page

2 - the content of a page has a hard coded link pointing to a cleartext page.

The first problem can be solved with a url-rewrite.

The 2nd problem can only be solved by fixing the server.

So, to identify which problem we are facing, we need to see at the same time the traffic between client and loadbalancer and the traffic between loadbalancer and server.

Since you are in one-armed mode, all traffic goes in and out a single interface.

So, you can span/monitor that interface using a 2nd pc, while the first pc is the client browsing the site.

In the trace, we should see the HTTPS traffic from the client and the HTTP traffic from the server.

Hoep this makes sense like this.

Gilles.

Gilles

Thanks. It made sense.

I made a capture the way you said. No filters to be sure nothing was left out so a display filter may be required.

So far the only 302 redirect I found was on packet 845.

Would you look at it?

Client: 10.1.1.140

VIP: 10.241.100.4

Server: 10.239.101.112

Thanks a lot.

Guido