Okay. You're going to end up getting yourself into something related to
hot water when you do something like this. I'm assuming that you actually
have a clue about what you're doing, so I'm going to skip the "this is why
the handshake was designed the way it was" speech.
The entire point of the handshake is to have a set of keys for the
connection, as well as the state that's necessary to manage the keys in
the connection. There is no protocol-level IP-redirect-with-same-state
function, so you're going to have to have some machine in the middle act
as a stateful intelligent router/headermunger based on some condition...
either seeing both the change-cipher messages, or (more likely) seeing a
notice from the accellerated system about what system to redirect the
stream to, on what port. (Essentially, starting a Network Address
Translation process -after- the connection is already established.)
You're also going to have to munge the information in the keystructure
itself, so that SSL itself doesn't complain that the IP or port that it's
communicating with has changed.
Also, you're going to have to do some kind of kernel patching on the
actual content servers to be able to force a connection into an OPEN state
without having to go through the TCP handshake, since most UNIXes follow
the standards and send an RST to a non-SYN packet to a port that is
listening.
Bottom line: I'd suggest that you get accellerator cards for all your
content servers. It's MUCH less headache, and it will be faster (as well
as more effective, and time-efficient, and energy-efficient) in the long
run than the kind of hack you're suggesting.
---
Mat Butler, Winged Wolf <[EMAIL PROTECTED]>
SPASTIC Web Engineer SPASTIC Server Administrator
----Begin FurryCode v1.3----
FCWw5amrsw A- C+ D H+++ M+++++[servercoder] P+ R++ T+++ W Z++ Sm++
RLCT/M*/LW* a cl/u/v++++>+++++ !d e- f>++++ h++ iwf+++ j p->+ sm++
----End FurryCode v1.3----
On Thu, 1 Jun 2000, Jacob Cohen wrote:
> I'm trying to get SSL handshaking to work on a remote, accelerated machine
> to take some load off of the web servers when they have a lot of incoming
> connections.
> Since the accelerator card in the remote machine supports OpenSSL, I figured
> I would use the OpenSSL routines on that machine to do the handshaking.
> However, in order to do the handshake, the SSL structure has a pointer to a
> handshake function, and several pointers to other data and structures..
> passing these pointers to the remote machine is pretty useless, and short of
> doing a deep copy of the entire structure (it's pretty deeply nested) I
> don't really see any way around it.
>
> As far as I can tell, the best point to have OpenSSL on the web server send
> data to the remote server is in the SSL_accept() function. Instead of doing
> the handshaking locally, it will do it remotely.
>
> Is there a better way to do this? Should I just place the remote call within
> the handshake function itself, so I don't have to pass the entire SSL
> structure over to the remote server?
>
> Thanks.
> J.
> ________________________________________________________________________
> Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com
>
> ______________________________________________________________________
> Apache Interface to OpenSSL (mod_ssl) www.modssl.org
> User Support Mailing List [EMAIL PROTECTED]
> Automated List Manager [EMAIL PROTECTED]
>
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
