<div dir="ltr">Hi!<div><br></div><div>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</div><div>support sha1 (sha) with dsa.  The correct oid name should be in the generated include file included in public_key.hrl </div><div><br></div><div>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.</div><div><br></div><div>Regards Ingela Erlang/OTP team - Ericsson AB<br><div><div><div class="gmail_extra"><br><div class="gmail_quote">2018-05-14 19:54 GMT+02:00 Per Hedeland <span dir="ltr"><<a href="mailto:per@hedeland.org" target="_blank">per@hedeland.org</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
For no other reason than the fact that our documentation claims that we<br>
support all the ciphers listed by ssl:cipher_suites(openssl) (users can<br>
select a subset by configuring a list of OpenSSL names), I actually have<br>
a test that tries them individually, and in OTP 20 ssl:ssl_accept()<br>
fails with {error, {tls_alert,"handshake failure"}} for all the DHE-DSS<br>
suites - i.e.<br>
<br>
 DHE-DSS-AES256-SHA256<br>
 DHE-DSS-AES128-SHA256<br>
 DHE-DSS-AES256-SHA<br>
 DHE-DSS-AES128-SHA<br>
 DHE-DSS-AES256-GCM-SHA384<br>
 DHE-DSS-AES128-GCM-SHA256<br>
<br>
a.k.a.<br>
<br>
 {dhe_dss,aes_256_cbc,sha256}<br>
 {dhe_dss,aes_128_cbc,sha256}<br>
 {dhe_dss,aes_256_cbc,sha}<br>
 {dhe_dss,aes_128_cbc,sha}<br>
 {dhe_dss,aes_256_gcm,aead,<wbr>sha384}<br>
 {dhe_dss,aes_128_gcm,aead,<wbr>sha256}<br>
<br>
After debugging a bit with the first one, I found that the failure was<br>
due to a function_clause error, and that this change made it work:<br>
<br>
--- a/lib/public_key/src/public_<wbr>key.erl<br>
+++ b/lib/public_key/src/public_<wbr>key.erl<br>
@@ -505,7 +505,9 @@ pkix_sign_types(?'ecdsa-with-<wbr>SHA256') -><br>
 pkix_sign_types(?'ecdsa-with-<wbr>SHA384') -><br>
     {sha384, ecdsa};<br>
 pkix_sign_types(?'ecdsa-with-<wbr>SHA512') -><br>
-    {sha512, ecdsa}.<br>
+    {sha512, ecdsa};<br>
+pkix_sign_types({2,16,840,1,<wbr>101,3,4,3,2}) -><br>
+    {sha256, dsa}.<br>
<br>
 %%----------------------------<wbr>------------------------------<wbr>----------<br>
 -spec sign(binary() | {digest, binary()},<br>
<br>
Some googling indicates that the oid-tuple could reasonably be named<br>
'id-dsa-with-sha256', no real surprise there - a bit more surprising is<br>
that the change actually makes *all* of those suites work. Now, I don't<br>
really know what I'm doing here, so: Is this just an omission in the<br>
public_key code and the above a reasonable fix, or is there some<br>
fundamental reason that pkix_sign_types/1 shouldn't handle that oid?<br>
(And if the latter, how can the DHE-DSS suites be made to work without<br>
it?)<br>
<br>
The test was run with 'openssl s_client' connecting to 20.3.6 - I can't<br>
easily plug 21.0-rc1 into the test, but it seems at least<br>
public_key:pkix_sign_types/1 is the same there.<br>
<br>
Thanks<br>
<span class="gmail-HOEnZb"><font color="#888888"><br>
--Per Hedeland<br>
______________________________<wbr>_________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/<wbr>listinfo/erlang-questions</a><br>
</font></span></blockquote></div><br></div></div></div></div></div>