Subject: SSLRequireSSL Circumvention

From: [email-masked]
Date: Tue, 4 Jun 2002 16:59:22 -0700

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-masked] -- 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-masked]
Automated List Manager                            [email-masked]

---

From: Cliff Woolley <[email-masked]>
Date: Tue, 4 Jun 2002 20:32:52 -0400 (EDT)

> 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

---

From: Cliff Woolley <[email-masked]>
Date: Tue, 4 Jun 2002 20:39:12 -0400 (EDT)

> at one point.  Which makes me wonder, what would I do if I wanted to

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

---

From: [email-masked]
Date: Tue, 4 Jun 2002 17:51:40 -0700

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

---

From: "Han,Donghoon" <[email-masked]>
Date: Wed, 5 Jun 2002 12:19:45 +0900

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

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

Phil

---

From: Cliff Woolley <[email-masked]>
Date: Thu, 13 Jun 2002 23:02:33 -0400 (EDT)

> SSLRequireSSL.  You can use a RewriteRule to get the same effect.

I just discovered a config option of which I was previously unaware that
would help here.  From the SSLOptions directive:

#   o StrictRequire:
#     This denies access when "SSLRequireSSL" or "SSLRequire" applied even
#     under a "Satisfy any" situation, i.e. when it applies access is denied
#     and no other module can change it.

So add:

 SSLOptions +StrictRequire

and then your scenario will work.  Sorry for misleading you earlier!

--Cliff