Disable TLS Renegociation ?

[Simon Bernard]

Thx Sean,

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?

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  ?

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|`jdk.tls.rejectClientInitiatedRenegotiation` |programmatically 
is not an option as this will affect all other library/code which could 
be used with that library.

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.

Simon

Le 23/04/2024 à 15:29, Sean Mullan a écrit :
>
>
> On 4/23/24 5:54 AM, Simon Bernard wrote:
>>
>> Hi,
>>
>> I'm implementing coaps+tcp (Coap over TLS) for LWM2M protocol.
>>
>> In this context, I would like to disable TLS renegotiation because :
>>
>>   * by the past we faces security issue about it
>>   * it doesn't really make sense to use it  with those protocols
>>     (better to not increase the attack surface for nothing)
>>   * (TLS) / (DTLS) Profiles for the Internet of Things strongly
>>     recommend (mandate?) to disable it :
>>     https://datatracker.ietf.org/doc/html/rfc7925#section-17
>>
>> 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.
>>
>> Only find a system properties : 
>> |jdk.tls.rejectClientInitiatedRenegotiation| to /"Rejects 
>> client-initiated renegotiation on the server side. If this system 
>> property is |true|, then the server will not accept client initiated 
>> renegotiations and will fail with a fatal |handshake_failure| alert. 
>> Rejects server-side client-initialized renegotiation."
>>
>> /But the documentation says :///"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 is 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."/
>>
>> (source : 
>> https://docs.oracle.com/en/java/javase/21/security/java-secure-socket-extension-jsse-reference-guide.html#GUID-A41282C3-19A3-400A-A40F-86F4DA22ABA9)
>>
>> Which sounds not so good and is only documented for java 17 and 21 (I 
>> just checked LTS version), not java 8 or 11. /
>> /
>>
> 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.
>
> The docs for JDK 8 and 11 should document this property - I'll file an 
> issue to have them updated.
>
> --Sean
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20240424/129457e4/attachment.htm>