httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matthew England <mengl...@mengland.net>
Subject [users@httpd] Newbie Qs: Simple SSL setup 2 secure comm (& other things)?
Date Sun, 07 Nov 2004 19:42:41 GMT
<html>
<body>
Hello,<br><br>
I'm looking for the least-intrusive for a user (as in a web-browser
client user) to access a &quot;secure&quot; server in order to fulfill
these goals:<br><br>
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).<br>
2) Enable the server to authenticate clients via login/password and
possibly via client IP num/range.<br>
3) Enabled the server to authenticate clients by a means of a distributed
&quot;key&quot; (possibly with something like managed SSL-client
certificates).<br>
4) Enable the client to authenticate that the server is who it claims to
be (such that a &quot;Trojan Horse&quot; won't steal login/passwords,
etc).<br><br>
In the documentation I've read thus far, the SSL/Apache community seems
rather fixated on #4.&nbsp; While I suspect this is quite important, it's
*last* on my list.&nbsp; 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).<br><br>
Why?&nbsp; Why not clearly separate the 2 mechanisms?&nbsp; Maybe I
simply misunderstand and do not know how to do so?<br><br>
I have a few more comments and questions below?<br><br>
More Details<br>
----------------<br><br>
I am new to SSL and Apache web-server management, and I've been browsing
various doc sources.<br><br>
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.&nbsp; 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).<br><br>
I also want to do this in such a way that my users have the
least-intrusive and &quot;comfortable&quot; experience possible.&nbsp;
Read: I don't want to see the &quot;Website Certified by an Unknown
Authority&quot; 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, &quot;https:&quot;-based communication, no fuss, no muss.<br>
&nbsp;<br>
So, first big question:&nbsp; can I do this without having to get a
formal certification from CA?&nbsp;
<a href="http://www.openssl.org/docs/apps/CA.pl.html">http://www.openssl.org/docs/apps/CA.pl.html</a>
suggests that maybe I can.&nbsp; Alas, if not, I'm still wondering why the development
community decided to mix up my goal #1 (above) with my goal #4.&nbsp; I see many server
managers and client users who care a lot about #1 and very little about #4 (even though possibly
they should?).<br>
&nbsp;<br>
[An aside:&nbsp; It seems rather difficult to spoof a server.&nbsp; 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 &quot;evil&quot;, Trojan-horse-type server that will try suck down the authentication
login/passwds for my legitimate server.&nbsp; Also, maybe one can &quot;copy&quot;
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.&nbsp; Bottom line:&nbsp; do I legitimately
need be concerned about server impersonation?&nbsp; Maybe I simply do not understand what's
going on in this realm?]<br>
&nbsp;<br>
The means to fulfill goal #2 above seems well documented, thorough, and cleanly implemented.&nbsp;
<br>
&nbsp;<br>
2nd Q:&nbsp; Even if I do get a CA cert and build in the appropriate keys/configuration
on my server, will a client still see these &quot;popup&quot; windows?&nbsp; <br>
&nbsp;<br>
I'm curious because I can see that my logins to places such as etrade.com and other things
have secured, &quot;https:&quot;, connections, but I for the life of me never remember
having to &quot;verify&quot; Etrade's server identity via a browser popup window.&nbsp;
Do they have some magic that I can easily use on my server(s)?<br>
&nbsp;<br>
3rq Q:&nbsp; As for the client-authentication:&nbsp; It seems like SSL-client-key-certification
is a good if not &quot;best&quot; route for this for beyond &quot;login/passwd&quot;
or &quot;IP-address-based&quot; authentication; in other words an authentication mechanism
that's tougher for someone to &quot;steal&quot;.&nbsp; (Would any care to add
comments?)&nbsp; The most-important part of this Q: I want to develop the &quot;simplest&quot;
means for a user to do this (even if I have to do some significant work to set this up).&nbsp;
I envision emailing a SSL-cert file &quot;key&quot; 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.&nbsp; Regardless, can anyone provide guides/pointers/recommendations/RTFM points?<
br>
&nbsp;<br>
That's all the questions I can think of for now.&nbsp; Thanks for reading thus far!<br>
&nbsp;<br>
-Matt<br>
</body>
</html>


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


Mime
View raw message