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

[Brent Putman]

On 8/19/20 4:06 AM, Paul B. Henson wrote:
>> From: Paul B. Henson
>> Sent: Tuesday, August 18, 2020 10:05 PM
>>
>> 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.
> If it's not possible to force the trust engine to run when resuming a cached SSL session, I guess the question is whether or not the trust engine configuration/criteria could change between the first call which processes a full handshake and a subsequent call which reuses an existing session? It seems like it could, the call to configure the criteria occurs on the connections which reuse an existing SSL session, then those criteria are not reevaluated. If it couldn't, you might be able to note that the session was reused and the validity confirmed on a previous connection and not abort. But I'm guessing if there's no way to make the trust engine run every time regardless of cached session, session caching will have to be disabled on the client…


Again, thanks for the follow-up.  TLS session resumption and/or tickets 
sound like the root cause here.

I doubt any of the right info is exposed at the higher levels of the 
HttpClient components.  So probably can't do anything at that level.

I think the cleanest solution will be to see if we can detect the 
session resumption and abbreviated handshake from the SSLSocket info, 
and handle that case in our TLS socket factory impl by simply setting 
the flag that says the TrustEnginve eval was successful (which is was 
earlier by inference).  Not sure yet.

I'll do any followup in the issue.

--Brent

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20200819/41b521f1/attachment.htm>