[erlang-questions] 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 <per@REDACTED>:

> 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
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20180515/99874f93/attachment.htm>