krekeltronics / node-mbed-dtls Goto Github PK

Ensure that SSL cookie contexts' are properly handled and memory is freed.

• Memory use should not increase after multiple connection handshakes.
• Memory use needs to recover when clients disconnect.

When a server and client negotiate a cipher-suite they will try to agree on the strongest cipher possible.

Expose an optional callback to node-js that will report the actual cipher used for the connection.

This can be integrated into the SSL cookie callback defined in #1.

Refer to the section "Server-side only: Cookies for client verification" in this document https://tls.mbed.org/kb/how-to/dtls-tutorial.

We need the two callbacks mentioned mbedtls_ssl_cookie_write_t and mbedtls_ssl_cookie_check_t to be optionally exposed to node.js so that our server backend can handle them.

Make registering these optional, so if the user does not decide to use them the current use of the default handlers is preserved.

Write an example server and client that show how to test and use these callbacks by persisting a connection cookie across multiple client connects and add the example to the example/test directory.

When the DTLS connection is negotiated, mbedtls will attempt to verify the certificate. Depending on the setting, the connection will be refused when the certificate fails or a warning will be issued and the connection established anyways.

To support these two scenarios we need to

1. Expose the verification setting to node js. Specifying this setting should be made mandatory in the API. ( MBEDTLS_SSL_VERIFY_NONE, MBEDTLS_SSL_VERIFY_OPTIONAL and MBEDTLS_SSL_VERIFY_REQUIRED)

2. Expose an optional callback that can be registered from nodejs for the server to be notified about whether verification has succeeded when set to MBEDTLS_SSL_VERIFY_OPTIONAL.

To verify that the setting works, create test/example programs and associated Keys and Certificates that will demonstrate

1. Handshake with only keys and MBEDTLS_SSL_VERIFY_NONE.

2. With MBEDTLS_SSL_VERIFY_OPTIONAL
   a. Handshake with successful verification reported by the callback.
   b. Handshake with failed verification reported by the callback.

3. With MBEDTLS_SSL_VERIFY_REQUIRED
   a. Successful verification
   b. failed verification

The RFC standards specify a long list of cipher-suites that can be used for DTLS communication.

Expose an optional setting to node-js that can configure which cipher-suites a server will accept. Validate them against the use of PSK and Key authentication. If PSK callback is registered then require at least one PSK-capable ciphersuite to be enabled. If a server key is specified, then require at least one key-capable ciphersuite to be enabled.

Create node-js user friendly defines for the specification of the ciphers. See here for DTLS ciphers https://tools.ietf.org/html/rfc4492#section-6.

Create examples demonstrating at least

1. A PSK configuration where
   a. the ciphersuite requirements are ok
   b. no ciphersuite suitable for PSK is set resulting in a node error exception.

2. A key configuration where
   a. a the ciphersuit requirements are ok
   b. no ciphersuite suitable for key exchange is selected resulting in a node error exception.