Re: [load balancing] Offloading SSL termination and rewriting HTTP toHTTPS with Apache

From: Tal Klein <Tal.Klein [izzat] citrix.com>
Date: Wed Jan 23 2008 - 15:08:43 EST

Hi Clarke,

Is the SSL stuff built into your pages or something? I ask because if
you're letting the LB do the SSL termination, apache should expect to
receive everything through HTTP/port 80 but it sounds like the problem
is that the page it's hitting is either looking for a cert or apache is
configured only to listen for that site on port 443. The initial
scenario isn't a function of apache because all it is doing is sending
requests back to a port on an IP, so if there's any SSL or cert-handling
stuff that happens inside of your site beyond the standard SSL handshake
that's probably what's not working. Otherwise, you may want to ensure
that apache is listening on the right port for the right IP/URL.

-Tal

---
Tal M. Klein
Technical Marketing & Strategy
Delivery Systems Division
Citrix Systems, Inc.
-----Original Message-----
From: lb-l-bounces@vegan.net [mailto:lb-l-bounces@vegan.net] On Behalf
Of Clarke Morledge
Sent: Wednesday, January 23, 2008 11:50 AM
To: lb-l@vegan.net
Subject: [load balancing] Offloading SSL termination and rewriting HTTP
toHTTPS with Apache
Hi, everyone.
When you offload SSL termination functionality to an external load 
balancer (whether it be a Cisco CSS, Foundry Server Iron, etc.), it
should 
ideally save you in resources on your Apache real servers.
However, if you were normally doing a mix of clear text and SSL on the 
Apache system prior to offloading the SSL, retaining the appropriate 
session context becomes a problem.  You must somehow train Apache to 
distinguish between regular clear text sessions and other clear text 
sessions that have been SSL terminated on the external load balancer (or
SSL accelerator).
Unfortunately, with Apache 2.2.6, I have had no such luck getting this
to 
work correctly.  I have tried sending the formerly SSL terminated
sessions 
to a different port; i.e. something other than tcp/80, and then somehow 
forcing Apache to rewrite URLs with "http" in them to be "https" for all
sessions coming into that non-standard port.  (When I mean "I", I mean
my 
system admin folks -- I am personally more of a network guy).
This not working consistently, so I am wondering if someone has a recipe
on how to do this with Apache.   I can manage to get some of the URLs 
rewritten from "http" to "https", such as URLs that are in the HTTP 
headers.  But URLs embedded in the web pages mostly get overlooked.
I have tried to get the external load balancer / SSL acceleration to
help 
out, but so far with Cisco and Foundry I have not  managed to  find the 
appropriate solution.  Rewriting URLs in HTTP headers are one thing.
But 
trying to rewrite URLs embedded in the TCP stream isn't really possible 
since it would be such a computationally expensive process.
The workaround I have is to continue with the SSL termination on the
load 
balancer and settle for a lower grade, 40-bit SSL encryption on the 
backend connection to the real servers.  This is slightly better than 
having the real server doing all of the SSL directly with the client,
but 
it sort of defeats the whole purpose of what I was trying to do in the 
first place --- getting rid of SSL computations completely on the real 
server.
Does anyone have any solutions/recipes?
Thanks.
Clarke Morledge
College of William and Mary
Information Technology - Network Engineering
Jones Hall (Room 18)
Williamsburg VA 23187
_______________________________________________
lb-l mailing list
lb-l@vegan.net
http://vegan.net/mailman/listinfo/lb-l
Searchable Archive: http://vegan.net/lb/archive
http://lbdigest.com Load Balancing Digest
_______________________________________________
lb-l mailing list
lb-l@vegan.net
http://vegan.net/mailman/listinfo/lb-l
Searchable Archive: http://vegan.net/lb/archive
http://lbdigest.com Load Balancing Digest
Received on Wed Jan 23 15:13:32 2008

This archive was generated by hypermail 2.1.8 : Wed Jan 23 2008 - 15:13:32 EST