Slashdot Mirror
Using Single Apache SSL/Non-SSL in Production?
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?"
This is what Slashdot does (and sourceforge too for that matter), they use one Apache host to serve content and use pound to do the SSL.
Good luck!
You can't grep a dead tree.
Honestly, this is the first time I've heard that
someone _does_ use two different servers for
http and https.
If you really want to increase security, use the
new chroot facilities.
My Karma isn't excellent, damn it! (And
Heres the bottom line. SSL is used to secure things that you dont want people to see, CC#'s, etc.
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 other hand, your ssl daemon is simply mirroring the plaintext in an SSL form, then for all intents and purposes, it doesn't matter
-- (appended to the end of comments you post, 120 chars)
Comments, Opinions, Ideas, Links?
Recipe 7.4: Serving a Portion of Your Site via SSL from O'Reilly's Apache Cookbook ?
JP
First of all, I am a bit of a web admin. I write software all day, run my own website on my machine, and many of my past jobs were writing asp (shudder) and cgi of various sorts.
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 that you try to simplify a bit.
I've tried jboss and tomcat and don't have any complaints. They work very well, and (at least from what I've heard) are very secure. No buffer overflows to be found, for obvious reasons. In addition, the portabiliity is nice.
Because of this you might consider trying to run tomcat without apache. The SSL in tomcat works fine, and it's easy enough to set it up so that it will serve both secure and non secure pages. This simplifies everything by placing the entire webserver (except for the cgi) in a single process. I've never really tried the cgi through tomcat, but I'm told it works so you might want to try it at some point. Not sure about PHP, and of course do a lot of testing and investigation before rolling this out into production (as if that even needed to be said).
If this works for you, you've eliminated all the OS/architecturre dependencies at once. In addition it'll help by cutting out one piece of software (apache), and might help security.
Why?
He who laughs last is stuck in a time dilation bubble.
You have to do quite a bit to isolate them. You must at least prevent against simple local-user DOS like a forkbomb (remember that it is a C one-liner), and you must isolate the apache users. If you access any of the same content via SSL as you do with straigh HTTP, you have to put them in the same group, and be very paranoid about other things.
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 guarding against local attacks. If the software does that for me in an unobtrusive way (dropping permissions, chroot, etc.), then that's ok. But I can't be bothered to patch my kernel and such against every possible scenario, and no one should -- you find the sweet spot between security and convenience.
And it's damn inconvenient to have to buy more memory because you _might_ have your HTTP apache server hacked before your SSL one is.
Don't thank God, thank a doctor!
If you don't gain any additional benefit from using two apache instances, and you have a hang on the configuration, then what you currently have is just perfect. The difference is not significant on a server with lots of memory (512mb+) as is typically used in web hosting. As usual, more specific information about your servers would have been helpful!
First, the biggest problem with having so many virtual hosts is the file handle utilization. This is mostly caused by having seperate logs for each host (a custom access log and an error log.) After 300 hosts you'll start adding ulimit lines to your apache startup scripts. And that's ugly. You can prevent this one by defining no log entries on your vhost configs and using a global config. Write a script to parse out the logs for each domain at the end of the day or whatever.
/home/users/example.com/www.example.com/html (or whatever you're using.)
Have you considered an SSL accelerator? They really do work. All HTTPS requests are handled on that box making the requests themselves normal HTTP on your webserver. No need for SSL support on your web server AT ALL. I cannot tell you how handy these things are. I'm sure you can find one that can fill your needs. Ours has handled 500 concurrent connections before.
Another thing you might consider, although I'm not sure how it would work in your situation, do not define any VirtualHost entries at all. A global mod_perl URL translator handler could do all of that work for you.
Let's say, for example, that you host www.example.com. Your URI Translator will look at the requested domain name and set the requested filename to
If that works for you, you'll never have to restart apache again. Instead, just adding users to the directory structure will make the websites available.
You sir, are in the exact same situation I was in just two days ago.
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.
I sent a dollar to that address and it came back undeliverable. Jerk.
One reason to keep these running separately is that it becomes easier to dedicate hardware specifically to the SSL portions of your hosting infrastructure, should you choose to go that route.
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 because there were 30 different SSL certs.
Good luck.
(There should be an 'Ask Slashdot: Revisited' where people follow-up on any suggestions received from 'Ask Slashdot'.)
sarchasm: The gulf between the author of sarcastic wit and the person who doesn't get it.
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 you're already running the SSL servers under apache, you just move those vhosts into your other configuration and just run one server. You may have to specify the SSL options in each <VirtualHost> section, rather than configuration -wide though. You just have fewer total httpd's running, and that will be less overhead.
- "History shows again and again how nature points out the folly of men" -- Blue Oyster Cult, 'Godzilla'
SSL takes up, on average, about 80% of the CPU on systems that process SSL themselves. This means your CPU is spending more time on encryption than actual requests.
Just go buy some SSL hardware. You can get SSL network cards fairly cheap, or you can spring for the external equipment. These free up the CPU so they can do actual work.
$.02