Handshake failure with DHE-DSS cipher suites

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Handshake failure with DHE-DSS cipher suites

Per Hedeland
Hi,

For no other reason than the fact that our documentation claims that we
support all the ciphers listed by ssl:cipher_suites(openssl) (users can
select a subset by configuring a list of OpenSSL names), I actually have
a test that tries them individually, and in OTP 20 ssl:ssl_accept()
fails with {error, {tls_alert,"handshake failure"}} for all the DHE-DSS
suites - i.e.

 DHE-DSS-AES256-SHA256
 DHE-DSS-AES128-SHA256
 DHE-DSS-AES256-SHA
 DHE-DSS-AES128-SHA
 DHE-DSS-AES256-GCM-SHA384
 DHE-DSS-AES128-GCM-SHA256

a.k.a.

 {dhe_dss,aes_256_cbc,sha256}
 {dhe_dss,aes_128_cbc,sha256}
 {dhe_dss,aes_256_cbc,sha}
 {dhe_dss,aes_128_cbc,sha}
 {dhe_dss,aes_256_gcm,aead,sha384}
 {dhe_dss,aes_128_gcm,aead,sha256}

After debugging a bit with the first one, I found that the failure was
due to a function_clause error, and that this change made it work:

--- a/lib/public_key/src/public_key.erl
+++ b/lib/public_key/src/public_key.erl
@@ -505,7 +505,9 @@ pkix_sign_types(?'ecdsa-with-SHA256') ->
 pkix_sign_types(?'ecdsa-with-SHA384') ->
     {sha384, ecdsa};
 pkix_sign_types(?'ecdsa-with-SHA512') ->
-    {sha512, ecdsa}.
+    {sha512, ecdsa};
+pkix_sign_types({2,16,840,1,101,3,4,3,2}) ->
+    {sha256, dsa}.

 %%--------------------------------------------------------------------
 -spec sign(binary() | {digest, binary()},

Some googling indicates that the oid-tuple could reasonably be named
'id-dsa-with-sha256', no real surprise there - a bit more surprising is
that the change actually makes *all* of those suites work. Now, I don't
really know what I'm doing here, so: Is this just an omission in the
public_key code and the above a reasonable fix, or is there some
fundamental reason that pkix_sign_types/1 shouldn't handle that oid?
(And if the latter, how can the DHE-DSS suites be made to work without
it?)

The test was run with 'openssl s_client' connecting to 20.3.6 - I can't
easily plug 21.0-rc1 into the test, but it seems at least
public_key:pkix_sign_types/1 is the same there.

Thanks

--Per Hedeland
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Handshake failure with DHE-DSS cipher suites

Ingela Andin
Hi!

I think that the oid is missing due to an oversight in adding it when crypto was updated to support it. For some reason (which I do not know)  early versions of crypto did only
support sha1 (sha) with dsa.  The correct oid name should be in the generated include file included in public_key.hrl 

Without looking into this further, I suspect that  the passing of the suites, could be due to that the  actual sha function used is a result of the "hash_sign negotiation"  that depends on the hash_sign hello extension.

Regards Ingela Erlang/OTP team - Ericsson AB

2018-05-14 19:54 GMT+02:00 Per Hedeland <[hidden email]>:
Hi,

For no other reason than the fact that our documentation claims that we
support all the ciphers listed by ssl:cipher_suites(openssl) (users can
select a subset by configuring a list of OpenSSL names), I actually have
a test that tries them individually, and in OTP 20 ssl:ssl_accept()
fails with {error, {tls_alert,"handshake failure"}} for all the DHE-DSS
suites - i.e.

 DHE-DSS-AES256-SHA256
 DHE-DSS-AES128-SHA256
 DHE-DSS-AES256-SHA
 DHE-DSS-AES128-SHA
 DHE-DSS-AES256-GCM-SHA384
 DHE-DSS-AES128-GCM-SHA256

a.k.a.

 {dhe_dss,aes_256_cbc,sha256}
 {dhe_dss,aes_128_cbc,sha256}
 {dhe_dss,aes_256_cbc,sha}
 {dhe_dss,aes_128_cbc,sha}
 {dhe_dss,aes_256_gcm,aead,sha384}
 {dhe_dss,aes_128_gcm,aead,sha256}

After debugging a bit with the first one, I found that the failure was
due to a function_clause error, and that this change made it work:

--- a/lib/public_key/src/public_key.erl
+++ b/lib/public_key/src/public_key.erl
@@ -505,7 +505,9 @@ pkix_sign_types(?'ecdsa-with-SHA256') ->
 pkix_sign_types(?'ecdsa-with-SHA384') ->
     {sha384, ecdsa};
 pkix_sign_types(?'ecdsa-with-SHA512') ->
-    {sha512, ecdsa}.
+    {sha512, ecdsa};
+pkix_sign_types({2,16,840,1,101,3,4,3,2}) ->
+    {sha256, dsa}.

 %%--------------------------------------------------------------------
 -spec sign(binary() | {digest, binary()},

Some googling indicates that the oid-tuple could reasonably be named
'id-dsa-with-sha256', no real surprise there - a bit more surprising is
that the change actually makes *all* of those suites work. Now, I don't
really know what I'm doing here, so: Is this just an omission in the
public_key code and the above a reasonable fix, or is there some
fundamental reason that pkix_sign_types/1 shouldn't handle that oid?
(And if the latter, how can the DHE-DSS suites be made to work without
it?)

The test was run with 'openssl s_client' connecting to 20.3.6 - I can't
easily plug 21.0-rc1 into the test, but it seems at least
public_key:pkix_sign_types/1 is the same there.

Thanks

--Per Hedeland
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Handshake failure with DHE-DSS cipher suites

Per Hedeland
On 2018-05-15 15:08, Ingela Andin wrote:
> Hi!
>
> I think that the oid is missing due to an oversight in adding it when crypto was updated to support it. For some reason (which I do not know)  early versions of crypto did only
> support sha1 (sha) with dsa.

Afer further digging, I think it's just a matter of "evolution" - the
'id-dsa-with-sha1' oid is defined in asn1/PKIX1Algorithms88.asn1, but
'id-dsa-with-sha256' is a more recent thing, and neither defined there
nor in any of the other modules i the asn1 directory, and I'm not sure
it "belongs" in any of them.

The definitions that can be found on the 'net agree on the numerical oid
elements, but there are actually at least two variants on the
(irrelevant here) naming of them - the one under "DSA with SHA-2 family"
on
https://csrc.nist.gov/Projects/Computer-Security-Objects-Register/Algorithm-Registration
seems pretty authoritative to me:-), but it's not given as part of any
ASN.1 module AFAIU. However
https://www.itu.int/ITU-T/formal-language/itu-t/x/x509/2016/AlgorithmObjectIdentifiers.html
seems to do that, with a module that also includes most but not all of
the definitions that are handled by public_key:pkix_sign_types/1...

> The correct oid name should be in the generated include file included in public_key.hrl

Well it isn't, since it isn't defined in any of the modules in the asn1
directory. But anyway, just dropping the definition from above into the
one of them that seems to have most of the definitions handled by
pkix_sign_types/1 makes for a slighly nicer diff (below).

> Without looking into this further, I suspect that  the passing of the suites, could be due to that the  actual sha function used is a result of the "hash_sign negotiation"  that depends on the
> hash_sign hello extension.

I'm not worried by that:-), but I'd like to make the DHE-DSS suites
work. I'll go with the below diff for now, but maybe OTP will fix it
"properly" in some future version?

--Per

diff --git a/lib/public_key/asn1/PKCS-1.asn1 b/lib/public_key/asn1/PKCS-1.asn1
index 117eacd..1df6719 100644
--- a/lib/public_key/asn1/PKCS-1.asn1
+++ b/lib/public_key/asn1/PKCS-1.asn1
@@ -87,6 +87,12 @@ id-sha512  OBJECT IDENTIFIER  ::=  { joint-iso-itu-t(2)
         nistalgorithm(4) hashalgs(2) 3 }


+-- This probably doesn't belong here, but...
+id-dsa-with-sha256  OBJECT IDENTIFIER  ::=  { joint-iso-itu-t(2)
+        country(16) us(840) organization(1) gov(101) csor(3)
+        nistalgorithm(4) sigalgs(3) 2 }
+
+
 RSAPublicKey ::= SEQUENCE {
     modulus           INTEGER,  -- n
     publicExponent    INTEGER   -- e
diff --git a/lib/public_key/src/public_key.erl b/lib/public_key/src/public_key.erl
index 0341266..75305cb 100644
--- a/lib/public_key/src/public_key.erl
+++ b/lib/public_key/src/public_key.erl
@@ -498,6 +498,8 @@ pkix_sign_types(?'id-dsa-with-sha1') ->
     {sha, dsa};
 pkix_sign_types(?'id-dsaWithSHA1') ->
     {sha, dsa};
+pkix_sign_types(?'id-dsa-with-sha256') ->
+    {sha256, dsa};
 pkix_sign_types(?'ecdsa-with-SHA1') ->
     {sha, ecdsa};
 pkix_sign_types(?'ecdsa-with-SHA256') ->
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Handshake failure with DHE-DSS cipher suites

Ingela Andin

I think it belongs in 

diff --git a/lib/public_key/asn1/PKIX1Algorithms88.asn1 b/lib/public_key/asn1/PKIX1Algorithms88.asn1
index 6cc6745..13ac6fa 100644
--- a/lib/public_key/asn1/PKIX1Algorithms88.asn1
+++ b/lib/public_key/asn1/PKIX1Algorithms88.asn1
@@ -40,6 +40,12 @@
   }
    -- encoding for DSA signature generated with SHA-1 hash
 
+id-dsa-with-sha256  OBJECT IDENTIFIER  ::=  { joint-iso-itu-t(2)
++        country(16) us(840) organization(1) gov(101) csor(3)
++        nistalgorithm(4) sigalgs(3) 2 }
++
+   
+
    Dss-Sig-Value  ::=  SEQUENCE  {
       r       INTEGER,
       s       INTEGER  }

You are welcome to submit a PR.

Regards Ingela Erlang/OTP - Team Ericsson AB

2018-05-15 18:12 GMT+02:00 Per Hedeland <[hidden email]>:
On 2018-05-15 15:08, Ingela Andin wrote:
> Hi!
>
> I think that the oid is missing due to an oversight in adding it when crypto was updated to support it. For some reason (which I do not know)  early versions of crypto did only
> support sha1 (sha) with dsa.

Afer further digging, I think it's just a matter of "evolution" - the
'id-dsa-with-sha1' oid is defined in asn1/PKIX1Algorithms88.asn1, but
'id-dsa-with-sha256' is a more recent thing, and neither defined there
nor in any of the other modules i the asn1 directory, and I'm not sure
it "belongs" in any of them.

The definitions that can be found on the 'net agree on the numerical oid
elements, but there are actually at least two variants on the
(irrelevant here) naming of them - the one under "DSA with SHA-2 family"
on
https://csrc.nist.gov/Projects/Computer-Security-Objects-Register/Algorithm-Registration
seems pretty authoritative to me:-), but it's not given as part of any
ASN.1 module AFAIU. However
https://www.itu.int/ITU-T/formal-language/itu-t/x/x509/2016/AlgorithmObjectIdentifiers.html
seems to do that, with a module that also includes most but not all of
the definitions that are handled by public_key:pkix_sign_types/1...

> The correct oid name should be in the generated include file included in public_key.hrl

Well it isn't, since it isn't defined in any of the modules in the asn1
directory. But anyway, just dropping the definition from above into the
one of them that seems to have most of the definitions handled by
pkix_sign_types/1 makes for a slighly nicer diff (below).

> Without looking into this further, I suspect that  the passing of the suites, could be due to that the  actual sha function used is a result of the "hash_sign negotiation"  that depends on the
> hash_sign hello extension.

I'm not worried by that:-), but I'd like to make the DHE-DSS suites
work. I'll go with the below diff for now, but maybe OTP will fix it
"properly" in some future version?

--Per

diff --git a/lib/public_key/asn1/PKCS-1.asn1 b/lib/public_key/asn1/PKCS-1.asn1
index 117eacd..1df6719 100644
--- a/lib/public_key/asn1/PKCS-1.asn1
+++ b/lib/public_key/asn1/PKCS-1.asn1
@@ -87,6 +87,12 @@ id-sha512  OBJECT IDENTIFIER  ::=  { joint-iso-itu-t(2)
         nistalgorithm(4) hashalgs(2) 3 }


+-- This probably doesn't belong here, but...
+id-dsa-with-sha256  OBJECT IDENTIFIER  ::=  { joint-iso-itu-t(2)
+        country(16) us(840) organization(1) gov(101) csor(3)
+        nistalgorithm(4) sigalgs(3) 2 }
+
+
 RSAPublicKey ::= SEQUENCE {
     modulus           INTEGER,  -- n
     publicExponent    INTEGER   -- e
diff --git a/lib/public_key/src/public_key.erl b/lib/public_key/src/public_key.erl
index 0341266..75305cb 100644
--- a/lib/public_key/src/public_key.erl
+++ b/lib/public_key/src/public_key.erl
@@ -498,6 +498,8 @@ pkix_sign_types(?'id-dsa-with-sha1') ->
     {sha, dsa};
 pkix_sign_types(?'id-dsaWithSHA1') ->
     {sha, dsa};
+pkix_sign_types(?'id-dsa-with-sha256') ->
+    {sha256, dsa};
 pkix_sign_types(?'ecdsa-with-SHA1') ->
     {sha, ecdsa};
 pkix_sign_types(?'ecdsa-with-SHA256') ->


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions