tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Barker" <>
Subject Re: Status/Authority of AJP/1.5
Date Tue, 25 Oct 2005 17:04:02 GMT

----- Original Message -----
From: "William A. Rowe, Jr." <>
To: "Tomcat Developers List" <>
Cc: <>
Sent: Tuesday, October 25, 2005 9:03 AM
Subject: Re: Status/Authority of AJP/1.5

> Costin Manolache wrote:
> >
> > Security ( i.e. authentication ) might be the only reason to extend
> > AJP - but even this can be done on top of the existing protocol, using
> > a custom header and connection initiation.
> Only partly true.  Let's take the HTTPS state, for example... if tomcat
> for X-PROTOCOL=HTTPS, for example, passing this from the proxy as a
> header is simply wrong for security reasons.  It's too trivial to fake,
> it's too expensive to guard against.
> The safe way is to have two header-types, one, a client HTTP-type header.
> other, proxy metadata such as the protocol, SSL keys and other server
> These wouldn't be relayed as HTTP-style headers, so therefore all sorts of
> to backend data can be trusted.

Urm, all of this is already part of the AJP/1.3 protocol, and now that BZ
#36883 is fixed, is working well in mod_proxy_ajp.  The main limitation with
the current protocol here is that AJP/1.3 only sends actual client-cert
instead of the entire chain.

One idea would be to expose the SSL data via a callback Msg, so that
Servlets that aren't going to look at it don't have to waste time asking
mod_ssl for the data.  But it's probably not that big of a deal.

> (FYI - w.r.t. the client/server certs, I don't suggest a full blown
> type of decomposition.  If they want to tear apart the certificates, it
> makes sense to introspect them through jsse, no?)
> Bill
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

This message is intended only for the use of the person(s) listed above as the intended recipient(s),
and may contain information that is PRIVILEGED and CONFIDENTIAL.  If you are not an intended
recipient, you may not read, copy, or distribute this message or any attachment. If you received
this communication in error, please notify us immediately by e-mail and then delete all copies
of this message and any attachments.

In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet
is not secure. Do not send confidential or sensitive information, such as social security
numbers, account numbers, personal identification numbers and passwords, to us via ordinary
(unencrypted) e-mail.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message