----- Original Message ----- From: "William A. Rowe, Jr." <[EMAIL PROTECTED]> To: "Tomcat Developers List" <dev@tomcat.apache.org> Cc: <[EMAIL PROTECTED]> 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 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. > 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 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
