LVS
lvs-users
Google
 
Web LinuxVirtualServer.org

Re: LVS and Apache-SSL

To: Lars Marowsky-Bree <lmb@xxxxxxxxx>
Subject: Re: LVS and Apache-SSL
Cc: Joseph Mack <mack@xxxxxxxxxxx>, linux-virtualserver@xxxxxxxxxxxx, psysadmin <psysadmin@xxxxxxxxxxx>
From: Wensong Zhang <wensong@xxxxxxxxxxxx>
Date: Fri, 25 Jun 1999 23:09:37 +0800

Lars Marowsky-Bree wrote:

> On 1999-06-24T15:48:02,
>    Wensong Zhang <wensong@xxxxxxxxxxxx> said:
>
> > I tested LVS with servers running Apache-SSL.
> > LVS uses the VS patch for kernel 2.2.9, and uses
> > the PCC scheduling. It worked without any problem.
>
> However, this was not the point why SSL needs special support.
>
> Obviously, anything which is based on a TCP connection from the client to the
> server will most likely work very well.
>

SSL is a little bit different.

In use, the client will send a connection request to the server. The
server will return a signed digital certificate. The client then
authenticates the certificate using the digital signature and the
public key of the CA.

If the certificate is not authentic the connection is dropped. If it is
authentic then the client sends a session key (such as a) and encrypts
the data using the servers public key. This ensures only the server can
read it since decrypting requires knowing the server private key.
The server sends its session key (such as b) and encrypts with its
private key, the client decrypt it with server's public key and get b.

Since both the client and the server get a and b, they can generate
the same session key based on a and b. Once they have the session key,
they can use this to encrypt and decrypt data in communication. Since the
data sent between the client and server is encrypted, it can't be read by
anyone else.

Since the key exchange and generating is very time-consuming, for
performance reasons, once the SSL session key is exchanged and
generated in a TCP connection, other TCP connections can also
use this session key between the client and the server in the life-span
of the key.

So, we have make the connections from the same client is sent to
the same server in the life-span of the key. That's why the PCC
scheduling is used here.

Have I made it clear?

Wensong


>
> It is just that we can use the SSL session ID to do better than that and
> separate the requests all comeing in from the same proxy into multiple
> sessions and schedule them to different machines, so not all of aol.com hits
> a single https server.
>
> Mind you I have no idea how to implement this, since this would require the
> load balancer to do scheduling based on in-band data, which we currently don't
> do at all, do we?
>
> Sincerely,
>     Lars Marowsky-Brée
>
> --
> Lars Marowsky-Brée
> Network Management
>
> teuto.net Netzdienste GmbH - DPN Verbund-Partner




<Prev in Thread] Current Thread [Next in Thread>