In reply to Thomas’s answer:
For each site, an SSL certificate has a direct cost. We have a dev, qa, and prod environment and thus that is three certificates that are needed for each site
Hardly true. You don’t need to have every single dev and qa behind SSL with valid, current certificates. You — perhaps — want one staging site with a valid certificate. But beyond the Apache front-end, your back-end should not know that there’s SSL involved. You’re not testing anything unique or special by purchasing dev certificates.
Also, the cost is nominal. You’re spending more money on the conversation than the certificates actually cost.
For the majority of pages, the content is not secure and forcing SSL would make the page requests take longer on the server because of encrypting and decrypting
A little. Have you measured? You may find that it’s hard to measure because the variability of internet speeds trump the cost of SSL processing.
From what I understand, most browsers to do not cache pages that are SSL’ed and thus again, page requests will take longer
Again, have you measured this?
Older browsers have problems with file downloads when they are SSL’ed
Really? Which specific “older browser” are you planning to support that has this problem? If you can’t find one and are thinking that someone, somewhere might have this problem, you may be overengineering. Check your logs and see what browsers your customers actually use, and then determine if you have a problem.
I agree that “SSL everywhere” isn’t a very good approach. I think you need at least one non-SSL port-80 “welcome” page. But I’m not sure your current set of issues are solid reasons. I think you need considerably more measurements to make the case that SSL actually involves real cost or real performance hits.