Using Single Apache SSL/Non-SSL in Production? 37
tck1000 asks: "I currently maintain some legacy webservers, running Apache 1.3.x on Linux, on x86 hardware. Two separate daemons are used. One to serve SSL vhosts, and one to server non-SSL vhosts. Each of these servers also is compiled with PHP, mod_perl, and JServe, and also works with a Tomcat servlet engines. In the process of planning an upgrade path, I've thought about using a single daemon to serve both the SSL and Non-SSL vhosts. Is this a good idea?"
"These webservers serve about 4 million hits a day across all the vhosts. I'm worried about memory usage if every httpd process has to load mod_ssl, as well as everything else they load.
I've been searching for comparisons between running 2 daemons (and the associated effort in maintaining/upgrading/patching), vs. running a single daemon (with any added overhead it entails).
I've found a lot of examples of how to do it, but not much on the why's.
Comments, Opinions, Ideas, Links?"
Slashdot/Sourceforge/etc... (Score:5, Informative)
Good luck!
A very simple question with a complex answer? (Score:2)
Re:A very simple question with a complex answer? (Score:2)
Re:Slashdot/Sourceforge/etc... (Score:3, Interesting)
1) Memory leaks - in our environment pound leaked memory like a siv. I had a cron job that restarted it daily it was so bad. In Pound's defense, this may have been a leak in the openssl libs.
2) Compatibility - Older versions of pound had very serious problems with some browsers. We had many clients that should not access the secure website. You had to upgrade to the pound-current tarball to fix it, which probably introduced the memory leak mentio
No, it doesn't (Score:3, Insightful)
someone _does_ use two different servers for
http and https.
If you really want to increase security, use the
new chroot facilities.
Re:No, it doesn't (Score:3, Insightful)
I don't understand what you are saying here. People use https to prevent others from sniffing their traffic, e.g. for credit card numbers or other data that should be kept secret, like passwords. Chroot environments are used for a completely different purpose: To keep the impact on your whole system as little as possible when (not if!) a security flaw in the daemon is discovered and thus an attacker can execute arbitrary code on your m
Re:No, it doesn't (Score:2)
the content exchanged.
Another one: use propolice (the stack protector)
if you can.
http://www.research.ibm.com/trl/projects/security
Re:No, it doesn't (Score:1)
SSP is good, but not commonly available in distributions.
I've made packages for Debian stable/unstable which are available from my security pages [debian.org].
More feedback is always appreciated - as it stands I use them, but I've no idea about others!
Re:No, it doesn't (Score:2)
because of which some programmes (mozilla, wineX)
still are compiled with -fno-stack-protector.
In OpenBSD since release 3.3, propolice is enabled,
as in MirBSD (http://mirbsd.de/). The latest MirBSD
development snapshot, available in 1-2 days under
https://mirbsd.bsdadvocacy.org:8890/curren t
(while writing this, I'm building it), has gcc 3
with propolice, W^X (ie, memory pages are either
writable or executable), NXSTACK and NXHEAP
protection mechanisms, and the defau
The Concern is... (Score:1)
If your SSL machine is the same as your www host, then if the www host (a more likely target for random attacks) is compromised, the SSL is worthless, since they can replace your cert, access protected data etc, under the same permissions of the www daemon.
SO, if your SSL daemon is handling data that sensibly should not be on the most obvious target for first attack, then no, its not a good idea.
If on the ot
At this point... (Score:1)
SSL itself isn't secure enough for me -- I have to trust VeriSign. So there are better ways of storing really sensitive information.
At this point, we are mainly
Re:At this point... (Score:2)
This is wrong on two levels:
Re:At this point... (Score:1)
As for setting up my own CA, there's the problem of people having to trust me initially. I actually prefer that to verisign (it's free), but there could be a better solution in general -- like an encrypted network filesystem.
#2: You're right, of course -- my bad, it is transit. And that is what this person was suggesting: "SSL is used to secur
Re:At this point... (Score:2)
This is only a trust issue for SSL clients, not for an ssl server.
at what point do you draw the line between 'ssl' and 'not ssl'?
SSL is a specific protocol, not a library. It has been standardized by the IETF in RFC 2246 [ietf.org]. If the protocol described in that document is implemented, it may properly be described as SSL or TLS. SSH, of course, doe
Re:At this point... (Score:1)
1.) I put critical documents on an SSL site.
2.) VeriSign swaps out my private key for their own.
3.) User requests secure page from my site, giving username and password.
4.) VeriSign intercepts the request, proxies it to my server (a man-in-the-middle attack), and keeps a copy of the file downloaded.
5.) VeriSign now has a full copy of whatever file the user was downloading.
So if I care at all about the clients, or if I am in f
Re:The Concern is... (Score:2)
Replacing the certificate? Wouldn't just about every browser throw a fit at that? The SSL isn't being used to protect any kind of persistent data on the filesystem.
Link (Score:5, Informative)
Comments, Opinions, Ideas, Links?
Recipe 7.4: Serving a Portion of Your Site via SSL [onlamp.com] from O'Reilly's Apache Cookbook ?
JP
Might consider more than that... (Score:2, Interesting)
Basically I've always found that people get into trouble when they run webservers with excessive complexity. On a modern webserver, serving just about anything, the actual performance of the webserver software doesn't mean much, all the time is taken with DB interaction and custom code (cgi, jsp, etc..). I would therefore suggest t
Re:Might consider more than that... (Score:4, Informative)
Re:Might consider more than that... (Score:2)
At the same time, how many images does an average page of yours use? How many stylesheets? How many external JavaScript files? Your code may only be running on 5% of the requests to your server.
Static content simply needs to be blasted out to the user as quickly as possible. There's not much sense in using a 12MB Apache process loaded down with mod_perl, PHP, and god
Re:Might consider more than that... (Score:1)
I was, however, under the impression that the vast majority of the cost of a website is paying for bandwidth, so it doesn't make a whole lot of difference (cost wise) if the webserver runs half as fast. In fact, if you can save a $80,000/year admin by consolidating all your servers into ten identical boxes each serving everything, then perhaps it's cost effective, even if you have to pony up a
Re:Might consider more than that... (Score:2)
Half the servers run one httpd.conf, half the servers run another. Or half the servers run Apache, half the servers run your favorite app server. J2EE servers are enough of a pain in the ass to deal with that I'd rather get rid of half of them for simple Apache/thttpd/publicfile/mathopd/etc static content servers anyway, even if it is another piece of
Re:Might consider more than that... (Score:2)
YMMV, but we've found exactly the opposite. We've had 3 separate security problems through using tomcat, two of which caused "session leakage", i.e., displaying one customer's session information to another. As a finacial services site, we just can't afford that sort of exposure. Yes, it only shows up under high load, but the 4 million or so hits a day that we get is enough t
Re:Might consider more than that... (Score:1)
Re:Might consider more than that... (Score:1)
Yes. Two had already been fixed by others (one was in a newer release, one wasn't but had a separate patch available). The third we fixed ourselves.
You're Doing Fine (Score:1)
Some advice... (Score:2)
Have you considered an SSL
Re:Some advice... (Score:3, Interesting)
Re:Some advice... (Score:2)
wow (Score:3, Interesting)
My conclusion:
Moving to one process to serve all requests, SSL and non-SSL, is more of a hassal than it's worth.
SSL and Non-SSL on one process requires IP-based vhosting. If you're using vhosts you probably don't have multiple IPs per server. Thus you must use name-based vhosts, and SSL gets confused.
I gave up and installed two processes and am very happy with that solution.
Apache+OpenSSL 2.0.48/Win32 on Windows Server 2003.
Re:wow (Score:1)
Re:wow (Score:1)
Yes, it is possible. Yes, I highly recommend it.
Relevant parts:
### Section 2: 'Main' server configuration
Port 80
## SSL Support
<IfDefine SSL>
Listen 80
Listen 443
</IfDefine>
### Section 3: Virtual Hosts
NameVirtualHost 192.168
Actually it's less overhead... (Score:2)
The only really ugly case is trying to do named virtual host SSL; which would work fine if you could get the browsers to agree on how they verify certificates:
But if y
Not an Apache specific answer... (Score:2)
Another consideration is whether Apache limits your use of a cert:key pair to each instance. We have always used (Netscape Enterprise|iPlanet Enterprise|Sun ONE). Earlier versions would limit you to 1 instance per port listened OR 1 instance per SSL cert. Eventually, we had up to 30 instances of the httpd running becau