Very Computer

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

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

   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.

   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

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. :[

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

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.  [...]

   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

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

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!

--

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

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

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

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