the secp384r1 is not getting accepted by a few mail servers.
the upstream server is TLS 1.2 and advertises:
{0xC0, 0x2C} TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
{0xCC, 0xA9} TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
{0xC0, 0x2B} TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
{0xC0, 0x24} TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
{0xC0, 0x23} TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
{0xC0, 0x09} TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
the connection fails with:
client connection error: Error: C0E703901F7F0000:error:0A0000C1:SSL routines:tls_post_process_client_hello:no shared cipher:../deps/openssl/openssl/ssl/statem/statem_srvr.c:2241:
node's current cipher list is https://nodejs.org/api/tls.html#modifying-the-default-tls-cipher-suite.
It says default cipher suite prefers GCM ciphers. ECDHE-ECDSA-AES256-GCM-SHA384 and ECDHE-ECDSA-AES128-GCM-SHA256
are the valid TLS 1.2 options but neither of these are selected.
the public key strength is somehow tied to cipher selection, I am not entirely sure how. from what i remember
`ecdsa_secp384r1_sha384` was listed in signature_algorithms extension.
Note that one document I found said that exchange server has a further _P256 and _P384 to cipher combinations.
Which suggests to me that one can also select specific curve+cipher combination.
anyway, with this curve, atleast the connection work with TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
Currently, we only have one field for the name. The first part is
first name. The rest is last name. Obviously, this won't work in all
cases but is the best we can do for the moment.
this causes a bug in the backupcleaner when it tries to prune
empty directories when using the filesystem backend.
the bug is hit when a box backup is getting cleaned up but
one or more app backups are preserved.
