Enable sha384 ciphers #168
Conversation
These functions work with general public keys and are not RSA-specific
This just changes a comment. These are neither used nor needed in TLS, and have e.g. been withdrawn from OpenSSL.
With version >= TLS12 the PRF is cipher dependent. We throw in the version as an ignored parameter as future-proofing. The caller will pass in the protocol version and the PRF from the appropriate cipher.
This is needed for SHA384 ciphers in TLS12 and later.
Also fix typos:
cipher_ECDHE_RSA_AES256CBC_SHA384: cipherID
cipher_ECDHE_RSA_AES256GCM_SHA384: cipherName
vdukhovni
force-pushed
the
enable-sha384-ciphers
branch
3 times, most recently
from
620dfe2
to
d2a0db1
Compare
|
With ECDSA enabled this also fixes #152. |
|
Good to kill two birds with one stone. I was working to fix interoperability with OpenSSL-based stacks such as Postfix, initially because leaving out support for SHA384 ciphersuites meant that OpenSSL servers that preempt the client's cipher list order will choose AES256CBC over AESGCM128, and I wanted to see AEAD used. I was pleased to find that adding the missing bits was simpler than I expected. It would be good if a few folks looked at the updated lists for And yes, I've successfully tested working ECDHE_ECDSA_AES256GCM_SHA384, ... against an OpenSSL server. It would be good to add test cases for this to the test suite, but the master branch does not yet have support for server-side ECDSA credentials (the ECDSA private key code seems to be missing). Perhaps someone can fill in the gap... This does also require haskell-tls/hs-certificate#80 so that all the usual NIST curves are recognized. |
vdukhovni
force-pushed
the
enable-sha384-ciphers
branch
from
d2a0db1
to
5feecd3
Compare
The optional cipherPRFHash field determines the Hash in the PRF HMAC (which otherwise defaults to SHA256), while the required cipherHash field determines the Hash used in the Finished message (and as MAC for non-AEAD ciphers).
Two are AES256GCM-SHA384 variants of existing AES128GCM-SHA256 ciphers:
DHE-RSA-AES256GCM-SHA384
ECDHE-ECDSA-AES256GCM-SHA384
Two more are CBC alternatives to GCM for ECDHE-ECDSA with SHA2:
ECDHE-ECDSA-AES128CBC-SHA256
ECDHE-ECDSA-AES256CBC-SHA384
Two more are 128/256-bit GCM alternatives to CBC for non-DHE
RSA key-exchange:
RSA-AES128GCM-SHA256
RSA-AES256GCM-SHA384
The last two flesh out ECDHE-ECDSA support with CBC+SHA1
ECDHE-ECDSA-AES128CBC-SHA
ECDHE-ECDSA-AES256CBC-SHA
We also note that:
cipher_RSA_3DES_EDE_CBC_SHA1
cipher_RC4_128_MD5
cipher_RC4_128_SHA1
cipher_null_MD5
cipher_DHE_DSS_RC4_SHA1
are obsolete and possibly non-standard (hintint that they should
not be used).
"ciphersuite_default" is "ciphersuite_all", minus the obsolete stuff. Suggest using this as the "Supported" set of ciphers.
Signal ECDSA signatures as part of the TLS12 signature algorithms extension. It is not uncommon to find secp384r1 as a server's sole ECDHE curve. Add it to the supported curve list.
|
FYI, did a force push to simplify needlessly complex definitions of getPRF and getHash (use guards on the function itself instead of Pattern Guards on |
|
Now would probably be a good time to change also If no objection I would also replace the lists in other debug utilities (for example |
This PR implements support for TLS12 ciphersuites with SHA384 (or other, though none yet in use) PRFs.
It also adds some new cipher code points that fill existing gaps.
With this done ECDSA signature algorithms are enabled, and secp384r1 is added to the supported curves. See individual commit logs for more detail.