Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 10 Oct 2001 23:41:17 -0700
From:      Ulf Zimmermann <ulf@Alameda.net>
To:        Alex Newman <dolemite@wulimasters.net>
Cc:        freebsd-hackers@freebsd.org
Subject:   Re: NATD+SSL
Message-ID:  <20011010234117.J518@seven.alameda.net>
In-Reply-To: <20011010200007.94855.qmail@host4.rpi.wulimasters.net>; from dolemite@wulimasters.net on Wed, Oct 10, 2001 at 08:00:07PM %2B0000
References:  <20011010200007.94855.qmail@host4.rpi.wulimasters.net>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Oct 10, 2001 at 08:00:07PM +0000, Alex Newman wrote:
> Ok I know this sounds wacky, but I will try justify why i think it is 
> usefull. If someone can think of a better way to achieve goals 1-3 or if 
> they are silly goals please tell me. How easy would it be to implement ssl 
> in the redirection part of natd. Some reasons why this is better than 
> sslwrap/stunnel/sslproxy: 
> 
> 1) say you had a packet coming in on port 443 ->application->80->thttpd  
> thttpd would see everything coming from localhost 
> 
> 2) It would allow you to more efficently have ssl proxy boxes infront of an 
> array of webservers. This is useful if you had for instance a hardware 
> crypto card in the ssl proxy. Currently the only decent way I know to do 
> this today is with linux+stunnel since it has transparent proxy support. 
> 
> 3) Since these programs always are doing a redirect anyways it seems silly 
> not to use natd for the redirction part of the process. 
> 
> Alex Newman
> www.wulimasters.net

Alteon has a solution for this like this:

Client.443 -> Loadbalancer -> SSL offloader (call iSD) -> Loadbalancer ->
Real Server.

the Loadbalancer has its usual config of a virtual server for that port
443 and then filters which redirect the SSL traffic to the offloader.
The offloader has the SSL certificates loaded and has some SSL hardware.
It then decrypts the request, sends it back to the loadbalancer on a
pretermined port (81 in their examples). The continuing of the filters
then forwards these port 81 packets to a real server based on persistent
connections/cookies or based on its normal load balancing.

The SSL offerloader has 2 modes, transparent or proxy. In proxy mode,
the real server sees the request as coming from the SSL offloader
and in transparant mode as coming from the real client.

Now the SSL offloader is basicly a Linux box. They lately removed
most of the clues to show that is is a Linux box, but I have seen
them.

I have been thinking trying to put something simular for FreeBSD
together (with or without hardware crypto card for SSL). It would be
mostly a proof of concept for me.

-- 
Regards, Ulf.

---------------------------------------------------------------------
Ulf Zimmermann, 1525 Pacific Ave., Alameda, CA-94501, #: 510-865-0204

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20011010234117.J518>