httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier>
Subject Re: [users@httpd] Using SetEnvIf on response headers
Date Thu, 09 Jul 2009 08:16:06 GMT
Ray Van Dolson wrote:
> On Wed, Jul 08, 2009 at 03:35:58PM -0700, André Warnier wrote:
>> Ray Van Dolson wrote:
>>> Hi all;
>>> I'm trying to strip out NTLM as an authentication option from response
>>> packets (my Apache is acting as a reverse proxy).
>> By curiosity, what does this achieve ?
>> If the origin server requires NTLM authentication for a resource, it is 
>> unlikely to be happy with a Basic authentication coming back from the 
>> browser.
> The server allows both NTLM and Basic (multiple WWW-Authenticate
> headers are transmitted).  The client insists on using NTLM if it's
> available which doesn't work properly in a reverse proxy setup (at
> least as far as I understand it).
> If I remove the NTLM header, the client falls back to Basic and all
> works correctly.
> The client is BIS (Blackberry) so unfortunately I can't change its
> behavior. :)
Allright, that makes sense, and does not sound like you are trying to
pull off a "man-in-the-middle" attack.
(And incidentally, you're right also, it is not really possible to do
NTLM auth through a proxy, for multiple reasons).

But first, maybe you should re-think about the whole scheme.
If the server sends back a 401 + WWW-Authenticate, it means that the
requested resource is marked as protected.
You will not really be bypassing this protection, but...
The NTLM scheme is (half-intentionally) limited in scope to a local
Windows Domain.
Basic authentication is not, and by allowing it, you will be in fact
allowing these clients to send user-id and password, almost in clear,
over any untrusted connection, from anywhere.  If these user-id and
password are the same as the internal Windows Domain login of these same
users, then I am quite sure someone is going to /strongly/ object.

Thus if the Blackberry supports this, I would at least strongly
recommend that you use HTTPS between the client and the proxy (even if
the proxy then forwards to the server in vanilla HTTP).

Even in that cases, though, you would have to take care of these pesky
response WWW-authenticate NTLM headers from the server.

The second line of thought would thus be to investigate if, at the level
of the content server, it would not be possible to arrange that the
Blacberry-accessible content, would be defined so as /not/ to require
authentication.  If so, problem solved.

If not however, then you still have to take care of the back-end 
response's WWW-authenticate NTLM headers.

I had a quick browse through the standard Apache modules, and it seems
that there is nothing that allows to test a /response/ header, and then
do something about the response headers in general.
If I was faced with the same issue, I would immediately think of doing
this via a mod_perl output filter.  That is because I have mod_perl
configured on all my servers, and because I like perl and mod_perl, and
because it is the ideal Swiss Army knife for this kind of situation.

But then, do you really need to do something ?

Say you always delete the WWW-authenticate: NTLM header, (and maybe 
always add a WWW-Authenticate: Basic header, although it seems that this 
is not necessary, since the server already sends one).
These headers should only be taken into account by the "browser", when 
coming in a 401 response, and be ignored when coming in 200 OK 
responses.  So what is the problem ?

The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:> for more info.
To unsubscribe, e-mail:
   "   from the digest:
For additional commands, e-mail:

View raw message