On Wed, Apr 1, 2015 at 11:50 AM, Rainer Jung <rainer.j...@kippdata.de>
wrote:
> Am 31.03.2015 um 15:19 schrieb Wesley Acheson:
>
> Currently I'm trying to use <tracking-mode>SSL</tracking-mode> in web.xml
>> but just running some local tests it appears that there are a number of
>> problems when using the JK connector and using this mechanism.
>>
>> First issue: Even though the requests are going through AJP which
>> supports
>> the SSL context information propegation, It appears I need to add a second
>> connector to serve over https. This is because the logic in
>> ApplicationConnector.java
>>
>> for (Connector connector : connectors) {
>> if (Boolean.TRUE.equals(connector.getAttribute("SSLEnabled")))
>> {
>> supportedSessionTrackingModes.
>> add(SessionTrackingMode.SSL);
>> break;
>> }
>> }
>>
>> Looks like the AJP connector doesn't accept that attribute.
>>
>
> Something we could fix, but you found a workaround.
>
>
Yeah I'm not sure if that is still an issue in TC8. When I'm not trying to
get something working in deadlines I'll try to provide a bug report maybe a
patch but I'm not sure if its the validation logic thats wrong or if the
connector should instead should have that property.
>
> Second issue: This is the actual issue that blocks us.
>>
>> When going over mod_jk to a tomcat instance it appears that the request
>> attribute SSL_SESSION_ID isn't populated on the first few requests to the
>> server. However it is populated on subsequent requests.
>>
>> This is causing the following exception.
>>
>> java.lang.NullPointerException
>> at
>> org.apache.catalina.connector.CoyoteAdapter.parseSessionSslId(
>> CoyoteAdapter.java:985)
>> at
>> org.apache.catalina.connector.CoyoteAdapter.postParseRequest(
>> CoyoteAdapter.java:765)
>> at
>> org.apache.catalina.connector.CoyoteAdapter.service(
>> CoyoteAdapter.java:416)
>> at org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:190)
>> at
>> org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.
>> process(AbstractProtocol.java:611)
>> at
>> org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.
>> run(JIoEndpoint.java:314)
>> at
>> java.util.concurrent.ThreadPoolExecutor.runWorker(
>> ThreadPoolExecutor.java:1142)
>> at
>> java.util.concurrent.ThreadPoolExecutor$Worker.run(
>> ThreadPoolExecutor.java:617)
>> at
>> org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(
>> TaskThread.java:61)
>> at java.lang.Thread.run(Thread.java:745)
>>
>> Closing and repopening the browser causes the same issue to occur again.
>> Which means that I'm going to have to go back to posting the id, after
>> places where we don't control redirects back to our domain, I'm going to
>> have to issue a one time session lookup token to lookup the session Id.
>> This means sharing a data source with the Valve and the web applications.
>> (basically a string->string hashmap) Hopefully I can use JNDI or similar
>> for a local map if not its going to be needed to be backed by a database.
>>
>> So remaining questions are two: How to get the SSL_SESSION_ID populated
>> on
>> initial requests? Can I share some object in memory with tomcat as the
>> container(in a valve) and the web application?
>>
>
> I currently see no reason, why it shouldn't be populated right from the
> start. Could you please check
>
> - whether Apache always provides SSL_SESSION_ID:
>
> Set "SSLOptions +StdEnvVars" and add %{SSL_SESSION_ID}X to your access log
> (using CustomLog and a LogFormat).
>
What I did before is I added the ssl options to apache and did an ngrep on
port 8009 loopback interface, apache was not sending it over the wire. It
was sending other SSL parameters
Now this could be just some error in my configuration I don't have it here
to check. I used whatever apache was installed by default by apt-get in
mint. And I couldn't find a precompiled mod_jk.so so I ended up compiling
it.
>
> This will log the ssl session id with every request that is handled by
> Apache in the Apache access log. If the field does not contain an id, then
> mod_jk has no chance of forwarding it and we need to solve that part.
>
I'm not at the computer where I saw this behaviour and as above I'm not
sure if its my fault. When I am back at the computer unfortunately I've
other things to solve. (such as my hacked together session tracking).
It looks like I'm way off the beaten path with trying SSL session over
mod_jk so I'm not sure if a fix is all that usefull to anyone?
>
> - whether Tomcat sees the right IDs:
>
> You can add %{javax.servlet.request.ssl_session}r to the pattern of the
> AccessLogValve to add the ssl session id to your Tomcat access log.
>
> If you can see the ID for the problematic cases in the httpd access log
> but not in the Tomcat one, I'll do a little test here to reproduce.
>
> Regards,
>
> Rainer
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
