aboutsummaryrefslogtreecommitdiffstats
path: root/lib/ssl/src/ssl_handshake.erl
diff options
context:
space:
mode:
authorIngela Anderton Andin <[email protected]>2018-05-04 17:42:28 +0200
committerIngela Anderton Andin <[email protected]>2018-05-15 16:41:47 +0200
commit70e282c5c2e9a3282475ee330e811a392ff4c378 (patch)
tree60cb903a8a6bbe875ff105145ab8d9178b68de7f /lib/ssl/src/ssl_handshake.erl
parentf770320ddc583c1059d33ff756ad986b53848517 (diff)
downloadotp-70e282c5c2e9a3282475ee330e811a392ff4c378.tar.gz
otp-70e282c5c2e9a3282475ee330e811a392ff4c378.tar.bz2
otp-70e282c5c2e9a3282475ee330e811a392ff4c378.zip
ssl: Correct key_usage check
The Key Usage extension is described in section 4.2.1.3 of X.509, with the following possible flags: KeyUsage ::= BIT STRING { digitalSignature (0), nonRepudiation (1), -- recent editions of X.509 have -- renamed this bit to contentCommitment keyEncipherment (2), dataEncipherment (3), keyAgreement (4), keyCertSign (5), cRLSign (6), encipherOnly (7), decipherOnly (8) } In SSL/TLS, when the server certificate contains a RSA key, then: either a DHE or ECDHE cipher suite is used, in which case the RSA key is used for a signature (see section 7.4.3 of RFC 5246: the "Server Key Exchange" message); this exercises the digitalSignature key usage; or "plain RSA" is used, with a random value (the 48-byte pre-master secret) being encrypted by the client with the server's public key (see section 7.4.7.1 of RFC 5246); this is right in the definition of the keyEncipherment key usage flag. dataEncipherment does not apply, because what is encrypted is not directly meaningful data, but a value which is mostly generated randomly and used to derive symmetric keys. keyAgreement does not apply either, because that one is for key agreement algorithms which are not a case of asymmetric encryption (e.g. Diffie-Hellman). The keyAgreement usage flag would appear in a certificate which contains a DH key, not a RSA key. nonRepudiation is not used, because whatever is signed as part of a SSL/TLS key exchange cannot be used as proof for a third party (there is nothing in a SSL/TLS tunnel that the client could record and then use to convince a judge when tring to sue the server itself; the data which is exchanged within the tunnel is not signed by the server). When a ECDSA key is used then "keyAgreement" flag is needed for beeing ECDH "capable" (as opposed to ephemeral ECDHE)
Diffstat (limited to 'lib/ssl/src/ssl_handshake.erl')
-rw-r--r--lib/ssl/src/ssl_handshake.erl5
1 files changed, 2 insertions, 3 deletions
diff --git a/lib/ssl/src/ssl_handshake.erl b/lib/ssl/src/ssl_handshake.erl
index 090e7b69b7..ebbb633b22 100644
--- a/lib/ssl/src/ssl_handshake.erl
+++ b/lib/ssl/src/ssl_handshake.erl
@@ -2233,13 +2233,12 @@ sign_algo(Alg) ->
is_acceptable_hash_sign(Algos, _, _, KeyExAlgo, SupportedHashSigns) when
KeyExAlgo == dh_dss;
KeyExAlgo == dh_rsa;
- KeyExAlgo == ecdh_ecdsa;
KeyExAlgo == ecdh_rsa;
KeyExAlgo == ecdh_ecdsa
->
%% *dh_* could be called only *dh in TLS-1.2
is_acceptable_hash_sign(Algos, SupportedHashSigns);
-is_acceptable_hash_sign(Algos, rsa, ecdsa, ecdh_rsa, SupportedHashSigns) ->
+is_acceptable_hash_sign(Algos, rsa, ecdsa, ecdhe_rsa, SupportedHashSigns) ->
is_acceptable_hash_sign(Algos, SupportedHashSigns);
is_acceptable_hash_sign({_, rsa} = Algos, rsa, _, dhe_rsa, SupportedHashSigns) ->
is_acceptable_hash_sign(Algos, SupportedHashSigns);
@@ -2270,7 +2269,7 @@ is_acceptable_hash_sign(_, _, _, KeyExAlgo, _) when
KeyExAlgo == ecdhe_anon
->
true;
-is_acceptable_hash_sign(_,_, _,_,_) ->
+is_acceptable_hash_sign(_,_,_,_,_) ->
false.
is_acceptable_hash_sign(Algos, SupportedHashSigns) ->
lists:member(Algos, SupportedHashSigns).