Newbie Qs: Simple SSL setup 2 secure comm (& other things)?
 

Hello,

I'm looking for the least-intrusive way for a user (as in a web-browser client user) to access a "secure" server in order to fulfill these goals:

1) Establish secure communication between web server and web client (so that a 3rd party can not, among other things, steal login/password and other sensitive info provided by either the server or client).
2) Enable the server to authenticate clients via login/password and possibly via client IP num/range.
3) Enabled the server to authenticate clients by a means of a distributed "key" (possibly with something like managed SSL-client certificates).
4) Enable the client to authenticate that the server is who it claims to be (such that a "Trojan Horse" won't steal login/passwords, etc).

In the documentation I've read thus far, the SSL/Apache community seems rather fixated on #4. While I suspect this is quite important, it's *last* on my list. When trying to setup capability for #1, I am seemingly forced to deal with all the stuff associated with #4 (if I want to try and hide popup/warning msgs at my user's client browsers, anyway).

Why? Why not clearly separate the 2 mechanisms? Maybe I simply misunderstand and do not know how to do so?

I have a few more comments and questions below.

More Details
----------------

I am new to SSL and Apache web-server management, and I've been browsing various doc sources.

I want a means to securely the communication from my web servers to my clients (and vice versa) such that a 3rd party can not snoop/steal info from said communication. A popular means to do this seems to be: 1) use public/private key SSL-based encryption to provide a secure communications channel, and 2) use Apache authentication mechanisms (like htpasswd, IP num/range checks, etc).

I also want to do this in such a way that my users have the least-intrusive and "comfortable" experience possible. Read: I don't want to see the "Website Certified by an Unknown Authority" popup window (that occurs in my Firefox 1.0PR browser); I just want to connect to my server via my browser and get an instant, secure, "https:"-based communication, no fuss, no muss.

So, first big question: can I do this without having to get a formal certification from CA? CA.pl [insert CA.pl URL off of openssl.org here...because the doesn't allow me to] suggests that maybe I can. Alas, if not, I'm still wondering why the development community decided to mix up my goal #1 (above) with my goal #4. I see many server managers and client users who care a lot about #1 and very little about #4 (even though possibly they should?).

[An aside: It seems rather difficult to spoof a server. The only way I can think to do it is to put a rouge DNS server out on the net that remaps my server name(s) to an "evil", Trojan-horse-type server that will try suck down the authentication login/passwds for my legitimate server. Also, maybe one can "copy" the IP address and try to use it for their server, although this 2nd method seems less reliable and much more easily discoverable by me. Bottom line: do I legitimately need be concerned about server impersonation? Maybe I simply do not understand what's going on in this realm?]

The means to fulfill goal #2 above seems well documented, thorough, and cleanly implemented.

2nd Q: Even if I do get a CA cert and build in the appropriate keys/configuration on my server, will a client still see these "popup" windows?

I'm curious because I can see that my logins to places such as etrade.com and other things have secured, "https:", connections, but I for the life of me never remember having to "verify" Etrade's server identity via a browser popup window. Do they have some magic that I can easily use on my server(s)?

3rq Q: As for the client-authentication: It seems like SSL-client-key-certification is a good if not "best" route for this for beyond "login/passwd" or "IP-address-based" authentication; in other words an authentication mechanism that's tougher for someone to "steal". (Would any care to add comments?) The most-important part of this Q: I want to develop the "simplest" means for a user to do this (even if I have to do some significant work to set this up). I envision emailing a SSL-cert file "key" and simple browser-file-key-import instructions to each user; even better, it would be nice if I could provide a program that once executed will automatically install the client certificate on the user's computer/browser automatically so that said user can be verified on their next attempt to login to my secure server. Regardless, can anyone provide guides/pointers/recommendations/RTFM points?

That's all the questions I can think of for now. Thanks for reading thus far!

-Matt

I want a means to securely the communication (...) Read: I don't want to see the "Website Certified by an Unknown Authority" popup window (...) no fuss, no muss.
So, first big question: can I do this without having to get a formal certification from CA?
AFAIK, no. Unfortunately certs aren't expensive, you're paying exclusively for supporting market domination and all added value services you'll use zilch of...

2nd Q: Even if I do get a CA cert and build in the appropriate keys/configuration on my server, will a client still see these "popup" windows?
Only if they want to be warned about any and all CA/certificate details, which is not the default AFAIK.

3rq Q: (..) I want to develop the "simplest" means for a user to do this (even if I have to do some significant work to set this up). (..) automagically install the client certificate on the user's computer/browser
There's ways to automate this using Apache using a modified mime-type but unfortunately I can't find any URI's.
Maybe someone else can. It should be mentioned in any "good" tutorials (lots around) anyway.

Re: Newbie Qs: Simple SSL setup 2 secure comm (& other things)?
 

You don'y understand. :) You see, your point #1 relies on your #4. You can't truly have secure communications unless you can validate that the server and client are whom they claim to be. SSL/OpenSSL accomplishes this through digital certificates that have the server name permanently stamped on them. That's why your browser will also complain if the name on the certificate does not match the name of the server you are connecting to. If you can't validate that the server you are talking to really is the server you are INTENDING to talk to, you can't know that your communications link can be trusted. You want an SSL-enabled web server. Also its important to note that some of the Apache authmechs you mentioned aren't secure unless they are done over SSL.No. Like unspawn said, CAs are the biggest racket going on the internet today, but I understand why we have them. There has to be SOME foundation of trust for people to start with. If everyone could just sign their own cert, then I could set up a server claiming to be secure.etrade.com or secure.bankofamerica.com and their would be no way to tell I was lying. By having some "ultimately trusted" CAs out there, it allows people to connect to your site without having to trust some random CA.See my point above. Absolutely you need to be concerned. Its actually gotten easier over the last few years with the wonders of spyware. If a malicious user can modify your /etc/hosts file (or %SYSTEMROOT%/system32/drivers/etc/hosts on Win32), then a DNS server will never be consulted. Scenario: I setup an SSL server and maliciously call it secure.etrade.com. I then write some spyware that adds to your hosts file. I then send you an email pretending to be eTrade asking you to update your account information (I don't even have to provide a link in the email, you can use your own bookmark). When your system goes to DNS lookup secure.etrade.com, it first consults the local etc/hosts file because, like any good citizen of the net, it shouldn't send unnecesarry packets. It finds that secure.etrade.com points to 1.2.3.4, and your system then initializes an SSL connection to the server that I setup on 1.2.3.4. I created a fake certificate and set the server name to secure.etrade.com. Your browser then complains because, even though the certificate is still valid (e.g. date is good) and the server names match (as far as your system knows), the certificate isn't signed by a trusted CA. :)No. As unspawn said, unless they have gone in a set their browser security settings to the highest settings (which 98% of the world doesn't), they won't see that message. Yes, their SSL certificates are issued by a trusted CA, e.g. Verisign. Your computer comes setup to trust certain CAs. Companies who are willing to pay for a certificate from one of these CAs won't have (most) browsers complain when connectin to their servers.

What YOU can do is have your users install the certificate on their system. This is an option in the popup that your web browser complains about. Once the certificate is installed on the user's computer, it won't complain when teh connect the next time.The simplest solution is to pay for a certificate from a CA. Or as I mentioned earlier, you could simply email the user instructions on how to install the self-signed certificate on their system. However, my experience is that the end user won't do it at all. ;)

If the group of your clients is limited and you have personal contact with them (and their PCs), you can install the server's certificate to their browsers. This way you can achieve #1 and #4 without buying a certificate from a real CA.