<html>

  <head>

    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">

  </head>

  <body>

    <p><br>

    </p>

    <div class="moz-cite-prefix">On 8/19/20 4:06 AM, Paul B. Henson

      wrote:<br>

    </div>

    <blockquote type="cite"

cite="mid:BYAPR01MB4966E769C38262DC133E08CAD25D0@BYAPR01MB4966.prod.exchangelabs.com">

      <blockquote type="cite">

        <pre class="moz-quote-pre" wrap="">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.

</pre>

      </blockquote>

      <pre class="moz-quote-pre" wrap="">

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…</pre>

    </blockquote>

    <p><br>

    </p>

    <p>Again, thanks for the follow-up.  TLS session resumption and/or

      tickets sound like the root cause here.</p>

    <p>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.<br>

    </p>

    <p>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.<br>

    </p>

    <p>I'll do any followup in the issue.</p>

    <p>--Brent<br>

    </p>

    <p>

    </p>

    <blockquote type="cite"

cite="mid:BYAPR01MB4966E769C38262DC133E08CAD25D0@BYAPR01MB4966.prod.exchangelabs.com"></blockquote>

  </body>

</html>