-
Notifications
You must be signed in to change notification settings - Fork 423
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Specific api for setting the DTLS version #1461
Comments
Unless you are using the wolfSSL TLS library, only DTLS1.2 will get negotiated and used for any DTLS session. This is enforced in the OpenSSL library by calling SSL_CTX_set_min_proto_version(). You can try using OpenSSL's s_client to force different protocol versions against a libcoap server run as
As mentioned in #1285, I don't see why someone cannot come up with a libcoap public API which gives the ability to define min/max (D)TLS versions (stored in coap_context_t). These values are then used when initiating (D)TLS. Whatever is done needs to be generic enough to support the different ways that all the libcoap supported TLS libraries implement the max/min protos. |
How do you say this first statement can I print the DTLS version and check, can I add logs somewhere to check this? sslv3/TLS is TLS 1.1 if I am not wrong how does it relate to DTLS here could you please explain it's bit confusing for me. |
Excellent - good detective work. |
I am trying to set the client min_proto version to DTLS1_version and server min_proto_version to DTLS1_2_version. My expectation here is when client request server with DTLS1_version server should reject in the handshake part itself and session should end. But what's happening here is little weird, Server logs: Jul 12 05:59:04.807 DEBG created DTLS endpoint 127.0.0.1:9909 Client logs: I dont understand what is 131071 because I have set client version to DTLS1_version which is 65279 and in next it changes to DTLS1_2_version which is 65277 from where is the change happening. I tried to run the client without the server still the change in version happens, Jul 12 06:14:42.380 DEBG ***127.0.0.1:56477 <-> 127.0.0.1:9909 DTLS: new outgoing session |
131071 is 0x1ffff. As per openssl source
this means the version has not been decided yet. DTLS 1.1 never happened as per RFC6347 1. Introduction. Furthermore, the CoAP base RFC 7252 refers to RFC6347 for use of DTLS RFC 7252 1.1 Features. So, DTLS 1.0 (nor the never happened DTLS1.1) is not supported for CoAP. |
I am trying to figure out if the libcoap library uses DTLS 1.2 or what exactly it uses. I verified from the libcoap code that the minimum version required is set to DTLS1_2_VERSION but what is it exactly.
I have a client code which is almost similar to libcoap_minimal client with DTLS enabled and I have set these based on my requirements,
dtls.version = COAP_DTLS_PKI_SETUP_VERSION;
dtls.verify_peer_cert = 0; // Verify peer certificate
dtls.check_common_ca = 0; // Require a server certificate
dtls.allow_self_signed = 1; // Allow self signed certificate
dtls.allow_expired_certs = 1; // No expired certificates
dtls.cert_chain_validation = 1; // Validate the chain
dtls.check_cert_revocation = 0; // Check the revocation list
dtls.cert_chain_verify_depth = 2; // Depth of validation.
dtls.pki_key.key_type = COAP_PKI_KEY_DEFINE
when I run my client I can see these logs in wireshark from libcoap library,
I understand that these logs are generated by libcoap but is there any log in libcoap where I can get the DTLS version used ?
likewise will I be able to get the DTLS version printed in logs?
I am aiming to address these 2 points,
I need to check and confirm the version of dtls being using.
Any DTLS connections with a version less than 1.2 should be rejected by the coap dtls server (Here I understand that we have already set the DTLS version to 1.2 using the SSL_CTX_set_min_proto_version API but using a dtls client will I be able to set some specific version so that my server will reject the connection throwing these log that DTLS version is unsupported. Do you see any possibility here).
The text was updated successfully, but these errors were encountered: