tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <cos...@gmail.com>
Subject Re: Status/Authority of AJP/1.5
Date Tue, 25 Oct 2005 16:44:14 GMT
Yes, this is a valid case, but as I said, I think it could be added
without breaking binary compatibility. But if we just can't find one -
I think it would be far better to use a real protocol, with some
build-in extensibility - rather than invent our own brand-new protocol
or ( even worse ) patch ajp12. DBUS is a good example in IMO - I'm not
saying to use their impl, which doesn't fit, just the protocol spec. I
used to think RPC/XDR would be good too - light enough, well-defined,
etc - but right now it looks dbus is a bit better ( there are few
dubious things there as well..).

I was referring was authentication for the apache-tomcat connection -
and this can be done by making a first set of HTTP request to a
special URL ( not starting with /, so it's invalid ), and on top of
this any auth.

Costin


On 10/25/05, William A. Rowe, Jr. <wrowe@rowe-clan.net> wrote:
> 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 looks
> for X-PROTOCOL=HTTPS, for example, passing this from the proxy as a typical
> header is simply wrong for security reasons.  It's too trivial to fake, and
> it's too expensive to guard against.
>
> The safe way is to have two header-types, one, a client HTTP-type header.  The
> other, proxy metadata such as the protocol, SSL keys and other server variables.
> These wouldn't be relayed as HTTP-style headers, so therefore all sorts of proxy
> to backend data can be trusted.
>
> (FYI - w.r.t. the client/server certs, I don't suggest a full blown mod_ssl
> type of decomposition.  If they want to tear apart the certificates, it sure
> makes sense to introspect them through jsse, no?)
>
> Bill
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message