Jean-frederic Clere wrote:
Filip Hanik - Dev Lists wrote:
Jean-frederic Clere wrote:
Filip Hanik - Dev Lists wrote:
gents and ladies,
currently we are doing SSL a little bit differently between APR and
the Java connectors.
The APR connector requires an attribute sslEngine="On" to kick in.
I believe this attribute to be useful for two reasons:
1.
Config should be as consistent as possible.
2.
If I use a SSL network card, or apache doing SSL etc, I would like
to trick Tomcat into thinking it is running in SSL
for example:
Apache Port 80 -> mod_proxy(http) -> Tomcat 8080
<Connector protocol="HTTP/1.1" port="8080"/>
Apache Port 443 -> mod_proxy(http) -> Tomcat 8081
<Connector protocol="HTTP/1.1" port="8081" secure="true"
scheme="https" sslEngine="off"/>
This example here is with Apache, but if you use any kind of SSL
accelerator, be it a network card or an appliance,
there is a risk of getting stuck in a redirect loop when using
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
in web.xml
Currently, you have to work around it using Valves or filters, but
it can get a little messy.
Useful?
What would you propose if we use HTTP/AJP + SSL between Apache httpd
and TC?
AJP doesn't support SSL, so its not affected.
Well. That would be protocol="AJP" sslEngine="on" secure="value"
scheme="value".
AJP doesn't support SSL, so I am not sure what the sslEngine attribute
would do.
and SSL info was passed in AJP package, not sure if that affects
getSecure or getScheme, but I would assume it does
BTW: Apache httpd does not yet support SSL proxy.
ProxyPass /servlets-examplex
https://anotherhost:8443/servlets-examples is not yet supported.
Or do I miss something?
this is supported, but this is also what we don't want, we dont want to
do SSL twice, thats the point of my whole proposal.
BTW: In TC 5.x the secure="true" or secure="false" does not behave
as in the documentation (See PR 40766).
yes, this is what we are trying to avoid, secure="value" should just
result in request.getSecure to return value, and so on.
sslEngine="on" actually kicks in the SSL enc/dec
+1
Cheers
Jean-Frederic
Filip
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
