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
