Ex: Re: : CAS proxy validation failure - Configured TLS trust engine was not used

[Paul B. Henson]

> From: Brent Putman
> Sent: Tuesday, August 18, 2020 3:28 PM
> 
> only the TCP socket.  But if that's wrong and it doesn't perform server TLS via
> JSSE on subsequent new HTTP requests over a cached connection, then that
> sounds like the culprit.

No, it's definitely doing TLS on every request; the CAS proxy callback is not available via http.

However, after enabling debugging at the JSSE layer and reviewing some packet captures of successful and failed attempts, I think I tracked it down. If I disable SSL session caching and SSL session tickets on the server side it works every time.

When resuming an existing cached session, it doesn't go through the full handshake process, it uses a more efficient abbreviated one. I bet it does not reverify the server certificate and rerun the trust engine for a session that has been previously validated and is simply being reused. I poked around in the JSSE code a bit but nothing jumped out as proving that hypothesis, but I'm pretty burned out of digging through obscure code so I might've missed it :). I would have thought it to be fairly common to have SSL session caching enabled on a server? I guess either Scott's endpoints are not doing SSL session caching or for some reason this bug is specific to the CAS use of the httpclient.

Hopefully you'll be able to get to the bottom of it, for now I can just leave SSL session caching disabled for my testing. It looks like you can disable SSL caching in the httpclient? I guess in the worst case you could do that or at least have an option so a user could do it if they run into the issue.

> request.  If not, we'll have to go from there.  (I don't think using their other
> connection pool impl BasicHttpClientConnectionManager is appropriate for a
> server-side multi-threaded use case.)

It would have worked around this issue :). I wasn't necessarily advocating for it as a permanent solution, but it would have been an interesting test to see how it behaved. Also, I am still seeing the issue from JSPT-102 I reported with 3.4.6 with 4.0.1 :(. I think that is also an issue on the httpclient side, it's never calling Socket.close() on the connection. I think this is also environment dependent, it only occurs when the server closes the connection rather than the client. Maybe while you are mucking around with httpclient internals you could sort this one out too :). I can do any further diagnosis or testing you need. Hmm, I guess as long as I am bugging you about stuff ;), I'd appreciate your feedback on the CAS PGT encoding patch in IDP-1655 whenever you have the time to look at it. It probably won't pass muster as is, but hopefully it is not too far off the mark.

Thanks much to both of you for your assistance with this issue, let me know if I can be of any further help fixing it.


java      27334           jetty  197u  IPv6 767903      0t0  TCP beric-dev.unx.cpp.edu:55750->davos.unx.cpp.edu:https (CLOSE_WAIT)
java      27334           jetty  198u  IPv6 767916      0t0  TCP beric-dev.unx.cpp.edu:55754->davos.unx.cpp.edu:https (CLOSE_WAIT)
java      27334           jetty  199u  IPv6 769592      0t0  TCP beric-dev.unx.cpp.edu:55756->davos.unx.cpp.edu:https (CLOSE_WAIT)
java      27334           jetty  200u  IPv6 769677      0t0  TCP beric-dev.unx.cpp.edu:55758->davos.unx.cpp.edu:https (CLOSE_WAIT)
java      27334           jetty  201u  IPv6 769846      0t0  TCP beric-dev.unx.cpp.edu:55760->davos.unx.cpp.edu:https (CLOSE_WAIT)
java      27334           jetty  202u  IPv6 770104      0t0  TCP beric-dev.unx.cpp.edu:55762->davos.unx.cpp.edu:https (CLOSE_WAIT)
java      27334           jetty  203u  IPv6 769892      0t0  TCP beric-dev.unx.cpp.edu:55764->davos.unx.cpp.edu:https (CLOSE_WAIT)
java      27334           jetty  204u  IPv6 771292      0t0  TCP beric-dev.unx.cpp.edu:55766->davos.unx.cpp.edu:https (CLOSE_WAIT)
java      27334           jetty  205u  IPv6 770399      0t0  TCP beric-dev.unx.cpp.edu:55768->davos.unx.cpp.edu:https (CLOSE_WAIT)
java      27334           jetty  206u  IPv6 771524      0t0  TCP beric-dev.unx.cpp.edu:55770->davos.unx.cpp.edu:https (CLOSE_WAIT)
java      27334           jetty  207u  IPv6 771013      0t0  TCP beric-dev.unx.cpp.edu:55774->davos.unx.cpp.edu:https (CLOSE_WAIT)
java      27334           jetty  208u  IPv6 771021      0t0  TCP beric-dev.unx.cpp.edu:55776->davos.unx.cpp.edu:https (CLOSE_WAIT)
java      27334           jetty  209u  IPv6 773529      0t0  TCP beric-dev.unx.cpp.edu:55778->davos.unx.cpp.edu:https (CLOSE_WAIT)