|
Home > Archive > WebSphere Edge Server > January 2004 > SSL Affinity without CBR
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
SSL Affinity without CBR
|
|
| albertpz@telelin.es 2004-01-19, 3:02 pm |
| I'm planning to set sesion affinity over 2 SSL backend servers, since
they are Aplication Server where session affinity is mandatory.
My question is :
Is the ND server able to maintain affinity over SSL comunications? i
don't want to use CBR.
Is this possible? if not can the ND manage the SSL certification like a
Web Server do?
Oscar Alvarez - Barclays
| |
|
| Oscar,
In Dispatcher with SSL, you can use the client IP based affinity because
the IP is not encrypted (obviously). However, you cannot use the cookie
based affinities without the Caching Proxy/CBR. The only other option
is the kernel content based routing method which allows you do to SSL ID
based affinity. It's a very simple CBR setup in the kernel and does not
involve the Caching Proxy. It (kernel CBR) cannot decrypt the SSL
traffic though...so the affinity can only be based on the SSL ID field.
Jeff
| |
|
| > In Dispatcher with SSL, you can use the client IP based affinity becausequote:
> the IP is not encrypted (obviously).
Is it still the "real" client address if the user comes through a reverse
proxy ? With HTTP, the server sees the proxy address and not the client
address.
Ben.
"JLee" <leeja@NOSPAMus.ibm.com> wrote in message
news:3E52A1B2.1090301@NOSPAMus.ibm.com...quote:
> Oscar,
>
> In Dispatcher with SSL, you can use the client IP based affinity because
> the IP is not encrypted (obviously). However, you cannot use the cookie
> based affinities without the Caching Proxy/CBR. The only other option
> is the kernel content based routing method which allows you do to SSL ID
> based affinity. It's a very simple CBR setup in the kernel and does not
> involve the Caching Proxy. It (kernel CBR) cannot decrypt the SSL
> traffic though...so the affinity can only be based on the SSL ID field.
>
> Jeff
>
| |
|
| We see whatever IP comes in -- so if the client goes through a proxy
then that proxy IP is what we see. That's the reason the other
affinities have been added over time, to give you options in that scenario.
Jeff
| |
| Oscar Alvarez 2004-01-19, 3:02 pm |
| Then. that IP affinity is not the best option for a large production
environment.
what about the SSL session ID affinity that Kernel CBR provides?
I hear that Internet Explorer 5 and greater, force renegotiation of SSL Id's
every 2 minutes. (i read this but i never checked)
if this is true we have still the same problem.
right?
Oscar
----- Original Message -----
From: JLee <leeja@NOSPAMus.ibm.com>
Newsgroups: ibm.software.websphere.edge-server
Sent: Wednesday, February 19, 2003 6:52 PM
Subject: Re: SSL Affinity without CBR
quote:
> We see whatever IP comes in -- so if the client goes through a proxy
> then that proxy IP is what we see. That's the reason the other
> affinities have been added over time, to give you options in that
scenario.quote:
>
> Jeff
>
JLee <leeja@NOSPAMus.ibm.com> escribió en el mensaje de noticias
3E53C44E.50304@NOSPAMus.ibm.com...quote:
> We see whatever IP comes in -- so if the client goes through a proxy
> then that proxy IP is what we see. That's the reason the other
> affinities have been added over time, to give you options in that
scenario.quote:
>
> Jeff
>
| |
|
| Oscar,
Actually, kernel CBR will watch for SSL ID negotiation (from either
direction) and update the affinity record with the new ID. Every effort
to keep things correct is attempted; however, the one case we can't
handle is when the browser does not send the SSL ID. Not much we can do
in that case.
Jeff
| |
| Oscar Alvarez 2004-01-19, 3:02 pm |
| Hi Jeff.
We did lot of tests with this matter.
We can't use Kernel CBR with Internet Explorer 5.0 or greater, we
allways lost the affinity every 2 minutes. It' seems that Network Dispatcher
is unable to detect the new SSL ID after the renegotiation.
We can set the negotiation time at the Windows Registry using the
ClientCacheTime value. but this is not a solution for our customers. We are
using ND 4.0.2
Btw. netscape 4.0 works ok! (no new SSL negotiation or perhaps ND can
intercept the SSL id negotiation)
Do you know a solution for this?
thanks in advance.
Oscar Alvarez
JLee <leeja@NOSPAMus.ibm.com> escribió en el mensaje de noticias
3E54CB40.7040109@NOSPAMus.ibm.com...quote:
> Oscar,
>
> Actually, kernel CBR will watch for SSL ID negotiation (from either
> direction) and update the affinity record with the new ID. Every effort
> to keep things correct is attempted; however, the one case we can't
> handle is when the browser does not send the SSL ID. Not much we can do
> in that case.
>
> Jeff
>
| |
|
| Oscar,
You might want to do some traces to see what the IE browsers is sending
but if at that 2 minute mark, if it sends the old SSL ID and a
renegotation request, then KCBR will update it's records. If the IE
browser decides to renegotiate by simply not providing the SSL ID (thus
triggering the new session setup), then KCBR has no way catching that
and updating it's records appropriately. If you see the SSL ID provided
by IE the entire time, then I would suggest going through IBM Support to
have it analyzed as to why the affinity failed.
By the way, if you're hesitant about using CBR because of Edge Server V1
(3.0, 3.6) code then you might want to give V2 a try. It's much
improved over the previous C/Java mix in V1.
Also, we have PTF2 for Edge Server V2 out and available. You can
download the ND build from the link below.
http://www.ibm.com/software/webserv.../lbsupport.html
Click on "All supported downloads" and then click on the "Load Balancer
version 4.0.3.0" link.
Jeff
|
|
|
|
|