Installing ModSSL Question

2002-06-04 Thread Don



Hi,

I'm new to this so please bare with me. I am 
running RedHat Linux 6.2 with Apache 1.3.22 and OpenSSL 0.9.6d. I wish to 
install ModSSL so that I can secure my web site.

I have downloaded the mod_ssl-2.8.5-1.3.22 tarball 
from the web site. Upon reading the documentation, I find that I need to 
recompile apache with additional configuration options in order to install 
ModSSL.

Here is my dilemma. I never compiled Apache 
from source but rather installed from rpm packages. Therefore, there 
doesn't seem to be any way I can install ModSSL. I've looked at the FAQ 
but can see no hints on installing ModSSL once Apache is installed. 
Neither have I found and ModSSL rpm package.

I DON'T want to download the Apache tarball and 
compile/install if I can help it because RedHat is a bit screwy as it uses it's 
own directories. Installing Apache from the tarball will undoubtedly mess 
up my system as it will install in other directories and confuse the hell out of 
me.

Do I have other options?

Thanks,
Don


Re: Installing ModSSL Question

2002-06-04 Thread Nalin Dahyabhai

On Tue, Jun 04, 2002 at 10:41:06AM -0400, Don wrote:
 I have downloaded the mod_ssl-2.8.5-1.3.22 tarball from the web site.  Upon reading 
the documentation, I find that I need to recompile apache with additional 
configuration options in order to install ModSSL.
 
 Here is my dilemma.  I never compiled Apache from source but rather installed from 
rpm packages.  Therefore, there doesn't seem to be any way I can install ModSSL.  
I've looked at the FAQ but can see no hints on installing ModSSL once Apache is 
installed.  Neither have I found and ModSSL rpm package.

The packaged version for Red Hat Linux already has the necessary EAPI
patch applied.  You should be able to either compile mod_ssl using apxs
(which is included in the apache-devel package) or rebuild a mod_ssl RPM
package from a later release using 'rpm --rebuild' (though I haven't done
that lately, YMMV).

HTH,

Nalin
__
Apache Interface to OpenSSL (mod_ssl)   www.modssl.org
User Support Mailing List  [EMAIL PROTECTED]
Automated List Manager[EMAIL PROTECTED]



SSLRequireSSL Circumvention

2002-06-04 Thread phil


I seem to have accidentally circumvented the SSLRequireSSL directive. 
Here's what my .htaccess file looks like: 

SSLRequireSSL
DirectoryIndex index.wp2
AddHandler cgi-script .cgi
Options +ExecCGI
deny from all
AuthType Basic
AuthUserFile /yadda/yadda/path/to/site/root/admin/.htpasswd
AuthName Administrative Pages
require valid-user
satisfy any

(I obscured the AuthUserFile path here.)

My .htaccess file is being parsed and used.  And if I try to fetch a
page in the admin area, I get this logged:

[Tue Jun  4 15:46:03 2002] [error] access to 
/yadda/yadda/path/to/site/root/admin/index.wp2 
failed for 206.228.191.21, reason: SSL connection required

BUT, I still get the page in the browser!  Weird.  I can reload it,
punch in the URL for a new page (which isn't cached), etc.  I tried
this on a couple different client computers to be sure.

Now, I can get the expected result if I comment out the 'deny from
all' and 'satisfy any' lines.  So, I'm OK now.  Logs look right, and
the browser is refused on port 80 for the admin area, as expected.

I thought it was odd, though, that it simply isn't enought to use the
SSLRequireSSL line for working logging and authentication.  There
seems to be some interaction happening between SSLRequireSSL and the
auth configs.

The doc says this on SSLRequireSSL:

SSLRequireSSL -

This directive forbids access unless HTTP over SSL (i.e. HTTPS) is
enabled for the current connection. This is very handy inside the
SSL-enabled virtual host or directories for defending against
configuration errors that expose stuff that should be protected. When
this directive is present all requests are denied which are not using
SSL.

But, of course, this is not true under some configuration conditions. 
Still the documentation mentioned that this is particularly helpful
for 'defending against configuration errors'.

BTW- I originally put in the 'deny from all' and 'satisfy any' lines
because I had another line 'allow from .my-domain.com' inbetween them 
at one point.  Which makes me wonder, what would I do if I wanted to
put it back in?

Anyways, I thought I would mention it because I didn't see anything
else on this inconsistency in the mail list or anywhere else for that
matter.

I'm using Apache-1.3.24 with mod_ssl-2.8.8.


Phil

-- 
Philip Edelbrock -- IS Manager -- Edge Design, Corvallis, OR
   [EMAIL PROTECTED] -- http://www.netroedge.com/~phil
 PGP F16: 01 D2 FD 01 B5 46 F4 F0  3A 8B 9D 7E 14 7F FB 7A
__
Apache Interface to OpenSSL (mod_ssl)   www.modssl.org
User Support Mailing List  [EMAIL PROTECTED]
Automated List Manager[EMAIL PROTECTED]



Re: SSLRequireSSL Circumvention

2002-06-04 Thread Cliff Woolley

On Tue, 4 Jun 2002 [EMAIL PROTECTED] wrote:

 SSLRequireSSL
 DirectoryIndex index.wp2
 AddHandler cgi-script .cgi
 Options +ExecCGI
 deny from all
 AuthType Basic
 AuthUserFile /yadda/yadda/path/to/site/root/admin/.htpasswd
 AuthName Administrative Pages
 require valid-user
 satisfy any

 BUT, I still get the page in the browser!  Weird.  I can reload it,
 punch in the URL for a new page (which isn't cached), etc.  I tried
 this on a couple different client computers to be sure.
 Now, I can get the expected result if I comment out the 'deny from
 all' and 'satisfy any' lines.  So, I'm OK now.  Logs look right, and
 the browser is refused on port 80 for the admin area, as expected.

That's not a bug, it's a feature.  mod_ssl acts as an access checker for
SSLRequireSSL just like both mod_access and mod_auth.  satisfy any means
that if any of the access checkers is satisfied, then access is allowed.
Presumably your browser either has the password for mod_auth cached or
you've typed it in again.  In that case, mod_auth's require valid-user
condition is satisfied, so access is granted.  If mod_auth's requirement
failed, access would still be granted as long as the connection was SSL.
The deny from all is useless here since it can never be satisfied.

Bottom line: I don't think you should be using satisfy any given the
configuration above.

--Cliff

__
Apache Interface to OpenSSL (mod_ssl)   www.modssl.org
User Support Mailing List  [EMAIL PROTECTED]
Automated List Manager[EMAIL PROTECTED]



Re: SSLRequireSSL Circumvention

2002-06-04 Thread Cliff Woolley

On Tue, 4 Jun 2002 [EMAIL PROTECTED] wrote:

 BTW- I originally put in the 'deny from all' and 'satisfy any' lines
 because I had another line 'allow from .my-domain.com' inbetween them
 at one point.  Which makes me wonder, what would I do if I wanted to
 put it back in?

Ah, forgot to respond to this part.  If you want that, then you would
obviously have to use 'satisfy any'.  And in that case, you can't use
SSLRequireSSL.  You can use a RewriteRule to get the same effect.

It probably wouldn't hurt to have this mentioned in the docs, I agree.

--Cliff

__
Apache Interface to OpenSSL (mod_ssl)   www.modssl.org
User Support Mailing List  [EMAIL PROTECTED]
Automated List Manager[EMAIL PROTECTED]



Re: SSLRequireSSL Circumvention

2002-06-04 Thread phil


Yeah, I zapped the 'satisfy any' and 'deny from all' which made the
server act as expected.  I think your explaination of the behavior is
correct. 

I'm still not understanding how this action is understandable from the
documentation for SSLRequireSSL, nor the fact that the logs are saying
'access failed' when clearly it hasn't?  The documentation and the
logging seems to state a strict enforcement, although it seems to not
be under some conditions.

Nor, out of curiousity, how I might configure it if I wanted some
logic like this:  SSL connection AND (password auth OR domain match) 

Thanks for the reply and explaination, btw!


Phil

On Tue, Jun 04, 2002 at 08:32:52PM -0400, Cliff Woolley wrote:
 On Tue, 4 Jun 2002 [EMAIL PROTECTED] wrote:
 
  SSLRequireSSL
  DirectoryIndex index.wp2
  AddHandler cgi-script .cgi
  Options +ExecCGI
  deny from all
  AuthType Basic
  AuthUserFile /yadda/yadda/path/to/site/root/admin/.htpasswd
  AuthName Administrative Pages
  require valid-user
  satisfy any
 
  BUT, I still get the page in the browser!  Weird.  I can reload it,
  punch in the URL for a new page (which isn't cached), etc.  I tried
  this on a couple different client computers to be sure.
  Now, I can get the expected result if I comment out the 'deny from
  all' and 'satisfy any' lines.  So, I'm OK now.  Logs look right, and
  the browser is refused on port 80 for the admin area, as expected.
 
 That's not a bug, it's a feature.  mod_ssl acts as an access checker for
 SSLRequireSSL just like both mod_access and mod_auth.  satisfy any means
 that if any of the access checkers is satisfied, then access is allowed.
 Presumably your browser either has the password for mod_auth cached or
 you've typed it in again.  In that case, mod_auth's require valid-user
 condition is satisfied, so access is granted.  If mod_auth's requirement
 failed, access would still be granted as long as the connection was SSL.
 The deny from all is useless here since it can never be satisfied.
 
 Bottom line: I don't think you should be using satisfy any given the
 configuration above.
 
 --Cliff

-- 
Philip Edelbrock -- IS Manager -- Edge Design, Corvallis, OR
   [EMAIL PROTECTED] -- http://www.netroedge.com/~phil
 PGP F16: 01 D2 FD 01 B5 46 F4 F0  3A 8B 9D 7E 14 7F FB 7A
__
Apache Interface to OpenSSL (mod_ssl)   www.modssl.org
User Support Mailing List  [EMAIL PROTECTED]
Automated List Manager[EMAIL PROTECTED]



Details on how to run a CRL?

2002-06-04 Thread Jason Haar

We are looking at using Client Certs via an internal CA as a cheap way of
strong authentication (SecurID costs are killing us!)

Obviously we'll have to introduce processes by which leaving staff have
their certs revoked, and have quick turnaround on revoking certs when a user
reports them lost (yeah, right... :-/)

Anyway, I can't think of a way of getting the server to check revocations
other than uploading the crl.pem hourly/daily from the CA to each SSL
server. This is possible, but I wondered if there is a better way of doing
it, or is that how this is meant to be done? I mean, that doesn't look like
it'd scale very well...

If that is true, can I imply from this that revocation checks basically
aren't done on the Internet today? 


-- 
Cheers

Jason Haar

Information Security Manager
Trimble Navigation Ltd.
Phone: +64 3 9635 377 Fax: +64 3 9635 417
__
Apache Interface to OpenSSL (mod_ssl)   www.modssl.org
User Support Mailing List  [EMAIL PROTECTED]
Automated List Manager[EMAIL PROTECTED]



RE: SSLRequireSSL Circumvention

2002-06-04 Thread Han,Donghoon

Just remove the 'satisfy any' line and try it again.
This worked on my server.


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On Behalf Of [EMAIL PROTECTED]
Sent: Wednesday, June 05, 2002 9:52 AM
To: Cliff Woolley
Cc: [EMAIL PROTECTED]
Subject: Re: SSLRequireSSL Circumvention


Yeah, I zapped the 'satisfy any' and 'deny from all' which made the
server act as expected.  I think your explaination of the behavior is
correct. 

I'm still not understanding how this action is understandable from the
documentation for SSLRequireSSL, nor the fact that the logs are saying
'access failed' when clearly it hasn't?  The documentation and the
logging seems to state a strict enforcement, although it seems to not
be under some conditions.

Nor, out of curiousity, how I might configure it if I wanted some
logic like this:  SSL connection AND (password auth OR domain match) 

Thanks for the reply and explaination, btw!


Phil

On Tue, Jun 04, 2002 at 08:32:52PM -0400, Cliff Woolley wrote:
 On Tue, 4 Jun 2002 [EMAIL PROTECTED] wrote:
 
  SSLRequireSSL
  DirectoryIndex index.wp2
  AddHandler cgi-script .cgi
  Options +ExecCGI
  deny from all
  AuthType Basic
  AuthUserFile /yadda/yadda/path/to/site/root/admin/.htpasswd
  AuthName Administrative Pages
  require valid-user
  satisfy any
 
  BUT, I still get the page in the browser!  Weird.  I can reload it,
  punch in the URL for a new page (which isn't cached), etc.  I tried
  this on a couple different client computers to be sure.
  Now, I can get the expected result if I comment out the 'deny from
  all' and 'satisfy any' lines.  So, I'm OK now.  Logs look right, and
  the browser is refused on port 80 for the admin area, as expected.
 
 That's not a bug, it's a feature.  mod_ssl acts as an access checker
for
 SSLRequireSSL just like both mod_access and mod_auth.  satisfy any
means
 that if any of the access checkers is satisfied, then access is
allowed.
 Presumably your browser either has the password for mod_auth cached or
 you've typed it in again.  In that case, mod_auth's require
valid-user
 condition is satisfied, so access is granted.  If mod_auth's
requirement
 failed, access would still be granted as long as the connection was
SSL.
 The deny from all is useless here since it can never be satisfied.
 
 Bottom line: I don't think you should be using satisfy any given the
 configuration above.
 
 --Cliff

-- 
Philip Edelbrock -- IS Manager -- Edge Design, Corvallis, OR
   [EMAIL PROTECTED] -- http://www.netroedge.com/~phil
 PGP F16: 01 D2 FD 01 B5 46 F4 F0  3A 8B 9D 7E 14 7F FB 7A
__
Apache Interface to OpenSSL (mod_ssl)   www.modssl.org
User Support Mailing List  [EMAIL PROTECTED]
Automated List Manager[EMAIL PROTECTED]

__
Apache Interface to OpenSSL (mod_ssl)   www.modssl.org
User Support Mailing List  [EMAIL PROTECTED]
Automated List Manager[EMAIL PROTECTED]