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.
notes:
* backup root cannot come from backend. for dynamic mounts backend cannot know where it is mounted
* backupConfig is 3 parts - format / mount / password . there is also this rootPath (which should not be in db)
* password should be stored separately in settings at some point
* format has to be passed along everywhere because we allow restore from same backupConfig but different format. we do this by saving the format in the backups table
fixes#819
