<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>Thx Sean,<br>
      <br>
      So just to be sure that I get you correctly, that means there is
      only a static way to disable that ? No way to configure it
      differently for each SslSocket or SslEngine?<br>
    </p>
    <p>For example, If I have a java application with 1  socket for
      https (e.g. a REST API) and another socket on for coaps+tcp (e.g. 
      to handle IoT devices), both using SunJSEE,  I can only enable or
      disable renegotiation for both or none of them  ?<br>
      <br>
      In my case, I implement an open source library which implement
      LWM2M protocol, so ideally I should provide a LWM2M Server without
      renegotiation by default but changing<code class="codeph">
        `jdk.tls.rejectClientInitiatedRenegotiation` </code>programmatically
      is not an option as this will affect all other library/code which
      could be used with that library.<br>
      <br>
      So, If there is no other option, I will not be able to provide a
      default configuration which follow "TLS / DTLS profiles for the
      IoT", too bad.<br>
      <br>
      Simon<br>
    </p>
    <div class="moz-cite-prefix">Le 23/04/2024 à 15:29, Sean Mullan a
      écrit :<br>
    </div>
    <blockquote type="cite"
      cite="mid:6765cb7b-dd8b-47d8-9b1c-9bcc02251e38@oracle.com">
      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
      <br>
      <br>
      <div class="moz-cite-prefix">On 4/23/24 5:54 AM, Simon Bernard
        wrote:<br>
      </div>
      <blockquote type="cite"
        cite="mid:3cbc5556-228c-4e96-a3b2-7919f0f61939@simonbernard.eu">
        <p>Hi,<br>
          <br>
          I'm implementing coaps+tcp (Coap over TLS) for LWM2M protocol.<br>
          <br>
          In this context, I would like to disable TLS renegotiation
          because : <br>
        </p>
        <ul>
          <li>by the past we faces security issue about it</li>
          <li>it doesn't really make sense to use it  with those
            protocols (<span _d-id="5101"
              class="--l --r sentence_highlight"><span _d-id="5103"
                class=" --l --r">better</span> <span _d-id="5107"
                class=" --l --r">to</span> <span _d-id="5111"
                class=" --l --r">not</span> <span _d-id="5115"
                class=" --l --r">increase</span> <span _d-id="5119"
                class=" --l --r">the</span> <span _d-id="5123"
                class=" --l --r">attack</span> <span _d-id="5127"
                class=" --l --r">surface</span> <span _d-id="5131"
                class=" --l --r">for</span> <span _d-id="5135"
                class=" --l --r">nothing)</span></span></li>
          <li>(TLS) / (DTLS) Profiles for the Internet of Things
            strongly recommend (mandate?) to disable it : <a
              class="moz-txt-link-freetext"
href="https://datatracker.ietf.org/doc/html/rfc7925#section-17"
              moz-do-not-send="true">https://datatracker.ietf.org/doc/html/rfc7925#section-17</a><br>
          </li>
        </ul>
        <p>So what is the right way to deactivate it  (for SslSocket and
          SslEngine) ? I searched for a programmatically way to do
          that (maybe using SSLParam) but didn't find it.<br>
          <br>
          Only find a system properties : <code class="codeph">jdk.tls.rejectClientInitiatedRenegotiation</code>
          to <i>"Rejects client-initiated renegotiation on the server
            side. If this system property is <code class="codeph">true</code>,
            then the server will not accept client initiated
            renegotiations and will fail with a fatal <code
              class="codeph">handshake_failure</code> alert. Rejects
            server-side client-initialized renegotiation." <br>
            <br>
          </i>But the documentation says :<i> </i><span><i>"This system
              property is currently used by the JSSE implementation, but
              it is not guaranteed to be examined and used by other
              implementations. If it <span class="variable">is</span>
              examined by another implementation, then that
              implementation should handle it in the same manner as the
              JSSE implementation does. There is no guarantee the
              property will continue to exist or be of the same type
              (system or security) in future releases."</i></span></p>
        <p>(source : <a class="moz-txt-link-freetext"
href="https://docs.oracle.com/en/java/javase/21/security/java-secure-socket-extension-jsse-reference-guide.html#GUID-A41282C3-19A3-400A-A40F-86F4DA22ABA9"
            moz-do-not-send="true">https://docs.oracle.com/en/java/javase/21/security/java-secure-socket-extension-jsse-reference-guide.html#GUID-A41282C3-19A3-400A-A40F-86F4DA22ABA9</a>)<br>
          <span></span></p>
        <p><span>Which sounds not so good and is only documented for
            java 17 and 21 (I just checked LTS version), not java 8 or
            11. <i><br>
            </i></span></p>
      </blockquote>
      That property is supported in JDK 8 and up. It was originally
      introduced in JDK 8. It is supported in the SunJSSE provider. If
      you are using a different JSSE provider, it may not be supported.
      But most (all?) implementations of OpenJDK probably include the
      SunJSSE provider.<br>
      <br>
      The docs for JDK 8 and 11 should document this property - I'll
      file an issue to have them updated.<br>
      <br>
      --Sean<br>
    </blockquote>
  </body>
</html>