Re: [users@httpd] Newbie Qs: Simple SSL setup 2 secure comm (& other things)?

[Ralf Glauberman <rg...@michaeli-gymnasium.de>]

plain txt please, no html!

hi,
as you seem to be really new to ssl, i explain it in detail:
ssl is a protocol which implements client/server autentication and a 
public/private key encryption, not only for http. you might have seen ssh, 
smtps, pop3s, ... as well. when opening an https connection, the server 
autenticates to the client and vise versa, then the actual http-data is 
transfered over ssl, meaning it is all encrypted. for ssl, the server must 
and the client may use certificates. you can create(sign) new certificates 
with your existant certificate, meaning you say "i guarantee that you can 
trust this one". you can also sign a certificate for yourself, but the 
client has to decide if he wants to trust you. browsers do have a buildin 
list of certificates of the cas, if they open an https connection and get a 
server-certificate which is signed by a ca, they see, "someone whom i trust 
(the ca) has guaranteed that i can trust this certificate". so, but your 
certificate is not signed by a ca, but by yourself. as the browser doesn't 
recognise you, it asks the user wheter he trusts you. the only way to get 
arround this is to get signed by a ca (expensive) or to import your own 
certificate into the users browser.
ok, this handles point 1, 3 and 4 on your list and 2 can be done using basic 
authentication.
hope it gets clearer now.
ralf

----- Original Message ----- 
From: Matthew England
To: openssl-users@openssl.org ; users@httpd.apache.org
Sent: Sunday, November 07, 2004 8:42 PM
Subject: [users@httpd] Newbie Qs: Simple SSL setup 2 secure comm (& other 
things)?


Hello,

I'm looking for the least-intrusive 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?  http://www.openssl.org/docs/apps/CA.pl.html 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 poi nts?< br>
That's all the questions I can think of for now.  Thanks for reading thus 
far!

-Matt
--------------------------------------------------------------------- The 
official User-To-User support forum of the Apache HTTP Server Project. See 
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 


---------------------------------------------------------------------
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