[users@httpd] Re: converting to SSL

[Hugh Williams <hu...@soco.agilent.com>]

Boyle Owen wrote:
> > -----Original Message-----
> > From: Hugh Williams [mailto:hughw@soco.agilent.com]
> > 
> > Hi;
> > 
> > I have an existing Apache 1.3.33 installation.  I need to 
> > introduce SSL
> > capability to the server, and so have installed 2.0.54 with mod_ssl on
> > the same system.  After much tinkering with SSL configuration 
> > (I think I
> > understand it much better now!), I have both servers up and running.
> > 
> > My question:  Assuming careful comaptibility checks on the httpd.conf
> > files, are there any reasons (security, operational, whatever) that I
> > cannot or should not point the cgi-bin/htdocs/images aliases 
> > at the same
> > location and let users access the content either way?  I am 
> > maintaining
> > separate logfile locations; I presume that as long as I have 
> > the server
> > instances running as the same User/Group that there won't be 
> > permission
> > issues with any files created via CGI.  I would expect to start
> > redirecting various portions of the content via Redirect or 
> > mod_rewrite
> > in the 1.3.33 instance until everything is using SSL.
> 
> As far as apache is concerned, the SSL site is just another VH that
> happens to work on port 443 instead of 80.  So having the same content
> as the port 80 VH is no problem.

To be clear:  I am running the port 80 instance from Apache 1.3.33 and
the secure 443 traffic from Apache 2.0.54, so they are not virtual hosts
under the same executable.  In fact, the Apache 2 has its own IP address
that the Apache 1 server doesn't even acknowledge.

> I'm a little puzzled as to why you might want to do this...  To be
> clear:  SSL encrypts the pipe betwee the client and the server - it
> doesn't make the server more or less secure.  Its usual application is
> to protect confidential information while it is in transit over the
> public internet.  For example, when a client uploads the contents of a
> form submission or when the server delivers personal information to the
> client.  There's not much point SSLising a public website...

I run this on our intranet; our (potentially overly paranoid) security
department has (strongly) recommended (via an audit report even!)  that
any and all transmission of passwords of any kind be encrypted, thus I
need to have at least some portions of my web server using SSL (and I
have lots of content/script owners whose applications are unfamiliar to
me, so it's hard to know exactly which pieces to repoint).

I combined this with my desire to convert to Apache 2.x, so set up an
independent Apache 2 instance rather than turning SSL on in the 1.3.x
instance.

My customers (and manager) don't like downtime or having to change all
their bookmarks and links (awww...), so my long-term goal is to make
everything SSL, and eventually knife-edge swap the existing and new host
names so everyone 'transparently' starts using SSL - the old server
would redirect all requests to the https equivalent.  This is laziness
on my part and assumes that the hardware can handle the increased load
without performance degradation (or at least not so much that customers
start to complain anyway).

I am sure that there are better ways to accomplish all this, but this is
what I came up with for now.  I have not done any serious advertising of
the SSL server yet, so I may decide to try something different.

Thanks for any input,

hugh

-- 
 Hugh Williams                  "There are two things to aim for in life;
 hugh_williams@agilent.com       first, to get what you want; and after that,
 Agilent Technologies            to enjoy it.  Only the wisest of mankind
 Santa Rosa 2US-C                achieve the second."
 707.577.4941                         - Logan Pearsall Smith, 1931

---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
   "   from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org