Access to login:password containing URLs using Apache 1.2 as proxy.

Access to login:password containing URLs using Apache 1.2 as proxy.

Post by Rais Dmitr » Fri, 13 Feb 1998 04:00:00



Does anybody knows if it's possible to configure the Apache server
(version 1.2 or, maybe 1.3) as proxy server, so that the proxy server will
serve requests for documents requiring user authentication (something like

).

With the template configuration file (after adding proxy module) the
server responds that this is "Bad Request", when is used as proxy server
and login:password containing URL is requested.

If somebody knows some solution, or knows that there is no solution and
the server just doesn't processes such requests, answer me please.

An answer by E-mail is really appreciated.

================================================================
Dmitri Rais           Ben Gurion University of the Negev, Israel
                      BGU-CS Lab. Staff.
----------------------------------------------------------------

 
 
 

Access to login:password containing URLs using Apache 1.2 as proxy.

Post by Marc Slemk » Sat, 14 Feb 1998 04:00:00



>Does anybody knows if it's possible to configure the Apache server
>(version 1.2 or, maybe 1.3) as proxy server, so that the proxy server will
>serve requests for documents requiring user authentication (something like

>).

Documents requiring authentication are not accessed in the form
you specify.  It is _NOT_ a standard form, and is not a good idea for
numerous reasons.  The proper way is for a client to send the
appropriate Authorization: header.  Most clients require that a
user enter it in a dialog box, but some clients do accept it in
the form you cite, however they _must_ convert it into a proper
request before sending it otherwise they are sending an invalid
request.

 
 
 

Access to login:password containing URLs using Apache 1.2 as proxy.

Post by Michael Salm » Tue, 03 Mar 1998 04:00:00



|>
|> >Does anybody knows if it's possible to configure the Apache server
|> >(version 1.2 or, maybe 1.3) as proxy server, so that the proxy server will
|> >serve requests for documents requiring user authentication (something like

|> >).
|>
|> Documents requiring authentication are not accessed in the form
|> you specify.  It is _NOT_ a standard form, and is not a good idea for
|> numerous reasons.  The proper way is for a client to send the
|> appropriate Authorization: header.  Most clients require that a
|> user enter it in a dialog box, but some clients do accept it in
|> the form you cite, however they _must_ convert it into a proper
|> request before sending it otherwise they are sending an invalid
|> request.

I agree that this form should not be sent to a server but it should be
acceptable to any browser as it conforms to RFC1738.

/Michael
--
This space intentionally left non-blank.

 
 
 

Access to login:password containing URLs using Apache 1.2 as proxy.

Post by Marc Slemk » Tue, 03 Mar 1998 04:00:00





>|>
>|> >Does anybody knows if it's possible to configure the Apache server
>|> >(version 1.2 or, maybe 1.3) as proxy server, so that the proxy server will
>|> >serve requests for documents requiring user authentication (something like

>|> >).
>|>
>|> Documents requiring authentication are not accessed in the form
>|> you specify.  It is _NOT_ a standard form, and is not a good idea for
>|> numerous reasons.  The proper way is for a client to send the
>|> appropriate Authorization: header.  Most clients require that a
>|> user enter it in a dialog box, but some clients do accept it in
>|> the form you cite, however they _must_ convert it into a proper
>|> request before sending it otherwise they are sending an invalid
>|> request.
>I agree that this form should not be sent to a server but it should be
>acceptable to any browser as it conforms to RFC1738.

Erm... no it doesn't.  RFC-1738 says:

   An HTTP URL takes the form:

      http://<host>:<port>/<path>?<searchpart>

   where <host> and <port> are as described in Section 3.1. If :<port>
   is omitted, the port defaults to 80.  No user name or password is
   allowed.  <path> is an HTTP selector, and <searchpart> is a query
   string. The <path> is optional, as is the <searchpart> and its
   preceding "?". If neither <path> nor <searchpart> is present, the "/"
   may also be omitted.

The general form of a URL includes somewhere for a password, however
it is expressly not permitted in a HTTP URL because it makes little
sense.

Not that RFC-1738 is right about a lot of things, and it should not be
used as a canonical reference.  Unfortunately, better onces can be
difficult to find (and aren't standard) although they do exist.

 
 
 

Access to login:password containing URLs using Apache 1.2 as proxy.

Post by Chris Gr » Tue, 03 Mar 1998 04:00:00



 writes:



> >|>
> >|> >Does anybody knows if it's possible to configure the Apache server
> >|> >(version 1.2 or, maybe 1.3) as proxy server, so that the proxy server will
> >|> >serve requests for documents requiring user authentication (something like

> >|> >).
> >|>
> >|> Documents requiring authentication are not accessed in the form
> >|> you specify.  It is _NOT_ a standard form, and is not a good idea for
> >|> numerous reasons.  The proper way is for a client to send the
> >|> appropriate Authorization: header.  Most clients require that a
> >|> user enter it in a dialog box, but some clients do accept it in
> >|> the form you cite, however they _must_ convert it into a proper
> >|> request before sending it otherwise they are sending an invalid
> >|> request.

> >I agree that this form should not be sent to a server but it should be
> >acceptable to any browser as it conforms to RFC1738.

> Erm... no it doesn't.  RFC-1738 says:

>    An HTTP URL takes the form:

>       http://<host>:<port>/<path>?<searchpart>

>    where <host> and <port> are as described in Section 3.1. If :<port>
>    is omitted, the port defaults to 80.  No user name or password is
>    allowed.  <path> is an HTTP selector, and <searchpart> is a query
>    string. The <path> is optional, as is the <searchpart> and its
>    preceding "?". If neither <path> nor <searchpart> is present, the "/"
>    may also be omitted.

> The general form of a URL includes somewhere for a password, however
> it is expressly not permitted in a HTTP URL because it makes little
> sense.

> Not that RFC-1738 is right about a lot of things, and it should not be
> used as a canonical reference.  Unfortunately, better onces can be
> difficult to find (and aren't standard) although they do exist.

The IETF draft URI syntax (*), to which of course, it would be inappropriate
to refer other than as a work-in-progress, replaces user:password by
"userinfo", and deliberately avoids any suggestion that it include cleartext
passwords:

   URL schemes that involve the direct use of an IP-based protocol to a
   specified server on the Internet use a common syntax for the <site>
   component of the URI's scheme-specific data:


   where <userinfo> may consist of a user name and, optionally,
   scheme-specific information about how to gain authorization to access


   The user information, if present, is followed by a commercial

      userinfo      = *( unreserved | escaped |
                         ";" | ":" | "&" | "=" | "+" )

   Some URL schemes use the format "user:password" in the <userinfo>
   field. This practice is NOT RECOMMENDED, because the passing of
   authentication information in clear text (such as URIs) has proven to
   be a security risk in almost every case where it has been used.

(*) <URL: ftp://ftp.ietf.org/internet-drafts/draft-fielding-uri-syntax-01.txt>

Of course there is little difference between passing a cleartext password
from client to server as the URI of an HTTP request, and passing it from
server to client in the body of a response.  But come to that the way it
is passed when using Basic Authentication is little better. :[

What do we want? MD5 Digests!  When do we want it? Now!

--

  Chris Gray

 
 
 

Access to login:password containing URLs using Apache 1.2 as proxy.

Post by Marc Slemk » Tue, 03 Mar 1998 04:00:00



>The IETF draft URI syntax (*), to which of course, it would be inappropriate
>to refer other than as a work-in-progress, replaces user:password by
>"userinfo", and deliberately avoids any suggestion that it include cleartext
>passwords:
>   URL schemes that involve the direct use of an IP-based protocol to a
>   specified server on the Internet use a common syntax for the <site>
>   component of the URI's scheme-specific data:


[...]

Note that this document strictly defines the format of URLs; it is left
to the definition of the specific scheme as to what they implement.
"http" has no concept of including authentication information
in the URI.  Some clients do it, but... that is their problem.

Quote:>   Some URL schemes use the format "user:password" in the <userinfo>
>   field. This practice is NOT RECOMMENDED, because the passing of
>   authentication information in clear text (such as URIs) has proven to
>   be a security risk in almost every case where it has been used.
>(*) <URL: ftp://ftp.ietf.org/internet-drafts/draft-fielding-uri-syntax-01.txt>
>Of course there is little difference between passing a cleartext password
>from client to server as the URI of an HTTP request, and passing it from
>server to client in the body of a response.  But come to that the way it
>is passed when using Basic Authentication is little better. :[

There is a very big difference between the two.  URIs are generally
not treated as private information.  They can be stored in logfiles.
They can be kept in client caches and history lists.  They can be
included in referer headers.  They can be cached by proxys.  Some
of these can be avoided in some cases if each bit of software
involved takes special steps to mangle the URI, but it is foolish
to think that every bit of software will do that, especially because
it really shouldn't.
 
 
 

Access to login:password containing URLs using Apache 1.2 as proxy.

Post by Liam Qui » Tue, 03 Mar 1998 04:00:00






>|>
>|> >Does anybody knows if it's possible to configure the Apache server
>|> >(version 1.2 or, maybe 1.3) as proxy server, so that the proxy server will
>|> >serve requests for documents requiring user authentication (something like

>|> >).
>|>
>|> Documents requiring authentication are not accessed in the form
>|> you specify.  It is _NOT_ a standard form, and is not a good idea for
>|> numerous reasons.  The proper way is for a client to send the
>|> appropriate Authorization: header.  Most clients require that a
>|> user enter it in a dialog box, but some clients do accept it in
>|> the form you cite, however they _must_ convert it into a proper
>|> request before sending it otherwise they are sending an invalid
>|> request.

>I agree that this form should not be sent to a server but it should be
>acceptable to any browser as it conforms to RFC1738.

Then I wonder why RFC 1738 [1] says this:

<<
An HTTP URL takes the form:
     http://<host>:<port>/<path>?<searchpart>
where <host> and <port> are as described in Section 3.1. If :<port>
is omitted, the port defaults to 80.  No user name or password is
allowed.

[1] http://www.w3.org/Addressing/rfc1738.txt

--
Liam Quinn
Web Design Group            Enhanced Designs, Web Site Development
http://www.htmlhelp.com/    http://enhanced-designs.com/

 
 
 

Access to login:password containing URLs using Apache 1.2 as proxy.

Post by Chris Gr » Wed, 04 Mar 1998 04:00:00



Quote: writes:
> >Of course there is little difference between passing a cleartext password
> >from client to server as the URI of an HTTP request, and passing it from
> >server to client in the body of a response.  But come to that the way it
> >is passed when using Basic Authentication is little better. :[

> There is a very big difference between the two.  [...]

Sorry, after re-reading what I wrote I see that it was unclear. I meant:

   Of course there is little difference between passing a cleartext password
   from client to server as the URI of an HTTP request, and passing it from
   server to client embedded in an HREF in the body of a response.

IOW, if I send out an HTML document containing

then the cat is already out of the bag; Marc's password may easily be
found by a robot, or displayed on his screen where others can see it,
before he even thinks of actually following the link.

If OTOH I say that certain informations can be found at
  <A HREF="http:/www.znep.com/private/">Marc's private pages</A>
under username "marcs" and password "mypasswd" then yes, the risk of
accidental disclosure is less.

So where does that leave us with regard to the original question?
username:password was never part of the http: scheme in RFC 1738, and
its use in any scheme is strongly deprecated in the internet draft.
So it would be perverse to modify a server now to make such URIs "work".

--

  Chris Gray

 
 
 

Access to login:password containing URLs using Apache 1.2 as proxy.

Post by Simon Broo » Thu, 12 Mar 1998 04:00:00




<SNIP: long discussion about sending cleartext passwords in URLs>

Quote:> The IETF draft URI syntax (*), to which of course, it would be
> inappropriate to refer other than as a work-in-progress, replaces
> user:password by  "userinfo", and deliberately avoids any suggestion
> that it include cleartext passwords:

<SNIP>

Quote:

> Of course there is little difference between passing a cleartext password
> from client to server as the URI of an HTTP request, and passing it from
> server to client in the body of a response.  But come to that the way it
> is passed when using Basic Authentication is little better. :[

> What do we want? MD5 Digests!  When do we want it? Now!

Quite. It would be nice if the original HTML 2 spec had specified that
the value of the 'BASIC' authentication tokens (and of 'password'
input widgets) was passed already one-way encrypted; passing it as
plain text (as currently) is a horrible security hole. If you want
*secure* access to your web-site *by password*, the best solution
currently is to implement your own login widget in Java, which passes
an already encrypted authentication token to apecial  sserver-end
handler. All this is very non-standard, of course.

--

        A message from our sponsor: This site is now in free fall

 
 
 

Access to login:password containing URLs using Apache 1.2 as proxy.

Post by Michael Salm » Thu, 12 Mar 1998 04:00:00




|>
|> <SNIP: long discussion about sending cleartext passwords in URLs>
|>
|> > The IETF draft URI syntax (*), to which of course, it would be
|> > inappropriate to refer other than as a work-in-progress, replaces
|> > user:password by  "userinfo", and deliberately avoids any suggestion
|> > that it include cleartext passwords:
|>
|> <SNIP>
|> >
|> > Of course there is little difference between passing a cleartext password
|> > from client to server as the URI of an HTTP request, and passing it from
|> > server to client in the body of a response.  But come to that the way it
|> > is passed when using Basic Authentication is little better. :[
|> >
|> > What do we want? MD5 Digests!  When do we want it? Now!
|>
|> Quite. It would be nice if the original HTML 2 spec had specified that
|> the value of the 'BASIC' authentication tokens (and of 'password'
|> input widgets) was passed already one-way encrypted; passing it as
|> plain text (as currently) is a horrible security hole. If you want
|> *secure* access to your web-site *by password*, the best solution
|> currently is to implement your own login widget in Java, which passes
|> an already encrypted authentication token to apecial  sserver-end
|> handler. All this is very non-standard, of course.

Can you explain to me the difference between sending an encrypted
password in plain text and passing the password itself? You need
something much more powerful than just one way encrypted passwords,
even varying the salt each time wouldn't be enough as there are only
4096 of them. IMHO basic authentication is quite OK if used over SSL or
something similar.

/Michael
--
This space intentionally left non-blank.

 
 
 

Access to login:password containing URLs using Apache 1.2 as proxy.

Post by Ron Klatchk » Thu, 12 Mar 1998 04:00:00



> If you want
> *secure* access to your web-site *by password*, the best solution
> currently is to implement your own login widget in Java, which passes
> an already encrypted authentication token to apecial  sserver-end
> handler.

Perhaps you've thought this out further then you've explained here, but
this sounds mighty susceptible to replay attacks.

moo
----------------------------------------------------------------------
              Ron Klatchko - Senior Software Engineer
         UCSF Library and Center for Knowledge Management

 
 
 

Access to login:password containing URLs using Apache 1.2 as proxy.

Post by Mark Nottingh » Fri, 13 Mar 1998 04:00:00




> Quite. It would be nice if the original HTML 2 spec had specified that
> the value of the 'BASIC' authentication tokens (and of 'password'
> input widgets) was passed already one-way encrypted; passing it as
> plain text (as currently) is a horrible security hole. If you want
> *secure* access to your web-site *by password*, the best solution
> currently is to implement your own login widget in Java, which passes
> an already encrypted authentication token to apecial  sserver-end
> handler. All this is very non-standard, of course.

Oh, I don't know. IMHO, it'd be better to encrypt the whole session with
SSL, which is much more standardised than using a Java client. You'd be
surprised at how many people hate java enough to not install it.

If it hasn't been mentioned before, Apache does have the optional module
mod_digest. Works well. Problem is, I can't find a browser that uses it!
Oh, MSIE3 on mac supports it-- sort of. I had a chat with them; turns out
they implemented it, didn't have time to debug it, and left it in the
browser, broken.  Lovely.  How hard can it be, folks? *sigh*

--
Mark Nottingham
Web architecture, design and programming
Melbourne, Australia

 
 
 

1. Apache 1.2.5 Problem using Proxy and URLs of the form http://host/dir

I am running Apache 1.2.5 on a front-end server which takes requests and
then uses a ProxyPass directive to pass these requests to the back-end
machines (also running Apache 1.2.5) handling the workload.  The
ProxyPass directive looks like:

ProxyPass http://frontend.dom/Stuff  http://backend.dom/Stuff

This works fine but what I've found is that a request to
http://backend.dom/Stuff gets redirected to http://backend.dom/Stuff/
and this is where the problem is.  The reason for the proxy is to hide
the backend machines under the frontend.dom URL.  But, this redirection
causes the client to see the backend URL.  So, the user puts in
http://frontend.dom/Stuff and after the connection the URL in the
browser window is http://backend.dom/Stuff/.  I've tried a few things
without success, like putting a trailing '/' at the end of the two
arguments for ProxyPass but this then makes the URL
http://frontend.dom/Stuff invalid.

Currently, we have a workaround where we use a <VirtualHost> directive
set up on a second IP address with ServerName set to frontend.dom.
However, this seems unnecessarily complicated and a waste of an IP
address.  Is there a better way?

Thanks

--
Paul Schnake, WWW Administrator
National Center for Biotechnology Information
National Library of Medicine
301-435-5956
301-480-9241 FAX

2. Vacation help

3. Apache 1.2 and URL problem (spaces)

4. Where to buy Solaris in the UK & installation query.

5. Apache with access control vs proxy (Not apache AS proxy)

6. swap file vs swap partition

7. Apache 1.2 Proxy Inquiry

8. Mouse pointer customisation - KDE menus

9. Proxy Caching with Apache 1.2

10. Getting Apache Proxy (1.2 or 1.3) to modify pages on the fly ?

11. Apache 1.2.x proxy cache fixes

12. How to make apache 1.2 a proxy server as well?

13. Logging Use of Internet with Apache 1.2 Proxy Enabled