<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <p><br>
    </p>
    <br>
    <div class="moz-cite-prefix">On 5/20/16 7:52 PM, Randall,Matt wrote:<br>
    </div>
    <blockquote
      cite="mid:9812d21f51074a4081fedf5bf9a310cd@CERNMSGKC2EX02D.cerner.net"
      type="cite">
      <meta http-equiv="Content-Type" content="text/html;
        charset=windows-1252">
      <meta name="Generator" content="Microsoft Exchange Server">
      <!-- converted from rtf -->
      <style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style>
      <font size="2" face="Calibri"><span style="font-size:11pt;">
          <div>We encountered a fairly esoteric problem in upgrading
            org.opensaml openws-1.5.5 to openws-1.5.6 in that we can no
            longer make SOAP calls (or fetch metadata) against TLS
            implementations that do not provide TLS session resume
            capabilities.  This appears
            to be associated with this commit [1] where a check for
            SSLSession.isValid() was introduced, which checks if an SSL
            session can be resumed.  I couldn’t infer from the JIRA [2]
            if the repercussions of this particular change were
            understood.</div>
        </span></font></blockquote>
    <br>
    No, I don't think I understood anything there about TLS session
    resume.<br>
    <br>
    <br>
    <blockquote
      cite="mid:9812d21f51074a4081fedf5bf9a310cd@CERNMSGKC2EX02D.cerner.net"
      type="cite"><font size="2" face="Calibri"><span
          style="font-size:11pt;">
          <div> </div>
          <div>For background, isValid() returns false if .invalidate()
            [3] has been invoked on the SSLSession by another object, or
            if the remote connection does not support TLS session resume
            capabilities.  This functionally is generally used when
            needing to construct
            new socket connections with an existing SSL Session, and
            allows one to determine if a referenced session can be
            re-used in doing so.</div>
        </span></font></blockquote>
    <br>
    <br>
    I don't know whether the behavior you describe is a fundamental API
    contract, or just a detail of the particular Java impl you're
    using.   Just for the record, what is the Java platform and version
    you are using here?<br>
    <br>
    <br>
    <blockquote
      cite="mid:9812d21f51074a4081fedf5bf9a310cd@CERNMSGKC2EX02D.cerner.net"
      type="cite"><font size="2" face="Calibri"><span
          style="font-size:11pt;">
          <div>  I don’t believe it makes sense to call it in context of
            this particular code.</div>
        </span></font></blockquote>
    <br>
    Perhaps, perhaps not, it's not clear to me from the docs.  <br>
    <br>
    It could very well be that I misunderstood the API. Ironically it
    probably isn't necessary for the session isValid() call anymore
    anyway.  IIRC, the reason for that is we were originally and
    incorrectly obtaining the hostname against which to perform hostname
    validation from the SSLSession.  That returns null when the session
    isn't valid, so that was the reasons for the change.  But that was
    fixed in a later change for JOWS-47.  So the isValid() call is
    *probably* superfluous at this point (unless I'm misremembering or
    forgetting something, which is entirely possible...). <br>
    <br>
    But unfortunately it's moot at this point. v2 is EOL at end of July
    and there will be no more releases aside from important (through May
    31) and critical (through July 31) security vulnerability bug
    fixes.  And this isn't a security bug period, just a functionality
    bug.<br>
    <br>
    Because of that you should really be looking to migrate to v3 asap. 
    If you really have to stay on v2 for now, I guess your only option
    is to do a local patch and build.<br>
    <br>
  </body>
</html>