Closed hzeus closed 1 year ago
Can you (similarly to #5835 ;-) ) use option {log_level, debug} for comparing the processing for both versions and share logs?
Thanks for your quick response (again)!
I created two log files of the two versions and I try to summarize the differences I see in a diff tool. I can also send you the complete files if this helps (via Mail?), but I do not want to share them publicly as they contain our customer's name in the certificates.
The first thing I notice is that right at the beginning in the release candidate, our server sends two messages, but the final release only one (left side is the RC; and the additional message ends with , protocol: :record, direction: :outbound]
)
Still within the ClientHello I see some differences within extensions (again, left side is RC, right side the final release):
The next significant change seems to be directly after Handshake, ServerHelloDone
, and the final release seems to send an empty list of certificates.
I omitted some diffs in between, as I do not see any significant differences other than e.g. the session ID.
It would help if you could share the signature algorithm used by your client certificate. You do not need to share the whole certificate.
You can get the information by in an erlang shell (elexir shell works to with adjusted syntax):
{ok, Pem} = file:read_file("yourcert.pem"). [{_, DerCert, _}| _] =public_key:pem_decode(Pem). Cert = public_key:pkix_decode_cert(DerCert, otp).
Share appropriate part of last command with us.
This is the output I get (the outputs are the same for the rc and the final version):
{'OTPCertificate',
{'OTPTBSCertificate',v3,5530876617007198567,
{'SignatureAlgorithm',{1,2,840,113549,1,1,11},'NULL'},
{rdnSequence,
[[{'AttributeTypeAndValue',{2,5,4,6},"DE"}],
[{'AttributeTypeAndValue',
{2,5,4,7},
{utf8String,<<"XXX">>}}],
[{'AttributeTypeAndValue',
{2,5,4,8},
{utf8String,<<"XXX">>}}],
[{'AttributeTypeAndValue',
{2,5,4,10},
{utf8String,
<<"XXX">>}}],
[{'AttributeTypeAndValue',
{2,5,4,11},
{utf8String,<<"XXX">>}}],
[{'AttributeTypeAndValue',
{2,5,4,3},
{utf8String,<<"XXX">>}}],
[{'AttributeTypeAndValue',
{1,2,840,113549,1,9,1},
"XXX"}]]},
{'Validity',
{utcTime,"210121082300Z"},
{utcTime,"260121082300Z"}},
{rdnSequence,
[[{'AttributeTypeAndValue',{2,5,4,6},"--"}],
[{'AttributeTypeAndValue',
{2,5,4,8},
{printableString,"XXX"}}],
[{'AttributeTypeAndValue',
{2,5,4,7},
{printableString,"XXX"}}],
[{'AttributeTypeAndValue',
{2,5,4,10},
{printableString,
"XXX"}}],
[{'AttributeTypeAndValue',
{2,5,4,11},
{utf8String,<<"XXXt">>}}],
[{'AttributeTypeAndValue',
{2,5,4,3},
{printableString,"XXX"}}],
[{'AttributeTypeAndValue',
{1,2,840,113549,1,9,1},
"XXX"}]]},
{'OTPSubjectPublicKeyInfo',
{'PublicKeyAlgorithm',{1,2,840,113549,1,1,1},'NULL'},
{'RSAPublicKey',
233...,
65537}},
asn1_NOVALUE,asn1_NOVALUE,
[{'Extension',
{2,5,29,14},
false,
<<185,253,64,225,49,181,158,232,221,81,41,...>>},
{'Extension',
{2,5,29,35},
false,
{'AuthorityKeyIdentifier',
<<123,194,183,112,183,157,31,10,...>>,
asn1_NOVALUE,asn1_NOVALUE}},
{'Extension',{2,5,29,37},false,[{1,3,6,1,5,5,7,3,...}]},
{'Extension',
{2,5,29,17},
false,
[{iPAddress,<<160,83,1,248>>},
{iPAddress,<<80,156,207,8>>}]}]},
{'SignatureAlgorithm',{1,2,840,113549,1,1,11},'NULL'},
<<67,211,123,80,110,75,232,0,240,108,131,60,32,154,79,
214,107,225,120,53,38,176,41,113,164,...>>}
Thank you, and yes of course the certificate will not have changed. I wanted to know the signature algorithm, which corresponds to public_key (ASN-1) macro:
-define('sha256WithRSAEncryption', {1,2,840,113549,1,1,11}).
Which should still be supported by default. We have changed the defaults in the RC (removed default support for algorithms considered weak) and we missed one that was included in the release but not in the RC. However you are not using that one. Another change that was done fairly late was that we made a new function to list signature algorithms to facilitate customization for those how need to interop with legacy systems. When doing this function we realized that some algorithms where duplicated in the default list due to the same algorithm having a TLS-1.2 and TLS-1.3 name, so we decide that the TLS-1.3 name should be used if both versions are supported.
Could you try setting signature_algs
in your client to
{signature_algs, [eddsa_ed25519,eddsa_ed448,ecdsa_secp521r1_sha512, ecdsa_secp384r1_sha384,ecdsa_secp256r1_sha256, rsa_pss_pss_sha512,rsa_pss_pss_sha384,rsa_pss_pss_sha256, rsa_pss_rsae_sha512,rsa_pss_rsae_sha384,rsa_pss_rsae_sha256, rsa_pkcs1_sha512,rsa_pkcs1_sha384, {sha256, rsa}, {sha512,ecdsa}, {sha384,ecdsa}, {sha256,ecdsa}]
Note that I change the algorithm name of your cert to TLS-1.2 format. This should not matter but we might have uncovered a bug in filtering/conversion functions.
I would also be interested to see the server hello messages form your scenarios.
I did this, and with this change, I could successfully make the request in the final version.
This is the output of the the ServerHello Part in the final version:
[debug] [message: {:server_hello, {3, 3}, <<244, 11, 12, 94, 183, 192, 212, 113, 88, 157, 132, 97, 89, 49, 139, 65, 30, 247, 187, 227, 113, 68, 185, 15, 208, 199, 8, 88, 105, 208, 157, 159>>, <<157, 89, 214, 74, 33, 13, 251, 31, 229, 0, 56, 249, 234, 52, 3, 135, 184, 25, 90, 119, 236, 122, 19, 131, 32, 76, 4, 102, 121, 132, 19, 86>>, <<192, 48>>, 0, %{alpn: :undefined, ec_point_formats: {:ec_point_formats, [0]}, next_protocol_negotiation: :undefined, renegotiation_info: {:renegotiation_info, <<0>>}}}, protocol: :handshake, direction: :inbound]
<<< TLS 1.2 Handshake, ServerHello
[{server_version,{3,3}},
{random,<<244,11,12,94,183,192,212,113,88,157,132,97,89,49,139,65,30,247,187,
227,113,68,185,15,208,199,8,88,105,208,157,159>>},
{session_id,<<157,89,214,74,33,13,251,31,229,0,56,249,234,52,3,135,184,25,90,
119,236,122,19,131,32,76,4,102,121,132,19,86>>},
{cipher_suite,"TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384"},
{compression_method,0},
{extensions,#{alpn => undefined,
ec_point_formats => {ec_point_formats,[0]},
next_protocol_negotiation => undefined,
renegotiation_info => {renegotiation_info,<<0>>}}}]
[debug] [message: {:ssl_tls, 22, {3, 3}, <<11, 0, 9, 20, 0, 9, 17, 0, 4, 150, 48, 130, 4, 146, 48, 130, 3, 122, 160, 3, 2, 1, 2, 2, 8, 96, 101, 2, 111, 140, 30, 223, 102, 48, 13, 6, 9, 42, 134, 72, 134, 247, 13, 1, 1, ...>>, false}, protocol: :record, direction: :inbound]
reading (2333 bytes) TLS 1.2 Record Protocol, handshake
0000 - 16 03 03 09 18 0b 00 09 14 00 09 11 00 04 96 30 ...............0
0010 - 82 04 92 30 82 03 7a a0 03 02 01 02 02 08 60 65 ...0..z.......`e
0020 - 02 6f 8c 1e df 66 30 0d 06 09 2a 86 48 86 f7 0d .o...f0...*.H...
0030 - 01 01 0b 05 00 30 81 b8 31 0b 30 09 06 03 55 04 .....0..1.0...U.
0040 - 06 13 02 44 45 31 14 30 12 06 03 55 04 07 0c 0b ...DE1.0...U....
(...)
[debug] [message: {:ssl_tls, 22, {3, 3}, <<12, 0, 1, 73, 3, 0, 23, 65, 4, 125, 168, 130, 114, 189, 216, 23, 228, 34, 221, 255, 40, 89, 96, 98, 87, 43, 41, 142, 96, 125, 107, 44, 146, 191, 154, 4, 235, 203, 208, 140, 30, 137, 46, 254, 215, ...>>, false}, protocol: :record, direction: :inbound]
reading (338 bytes) TLS 1.2 Record Protocol, handshake
0000 - 16 03 03 01 4d 0c 00 01 49 03 00 17 41 04 7d a8 ....M...I...A.}.
0010 - 82 72 bd d8 17 e4 22 dd ff 28 59 60 62 57 2b 29 .r...."..(Y`bW+)
0020 - 8e 60 7d 6b 2c 92 bf 9a 04 eb cb d0 8c 1e 89 2e .`}k,...........
[debug] [message: {:certificate, [<<48, 130, 4, 146, 48, 130, 3, 122, 160, 3, 2, 1, 2, 2, 8, 96, 101, 2, 111, 140, 30, 223, 102, 48, 13, 6, 9, 42, 134, 72, 134, 247, 13, 1, 1, 11, 5, 0, 48, 129, 184, 49, 11, 48, 9, 6, ...>>, <<48, 130, 4, 113, 48, 130, 3, 89, 160, 3, 2, 1, 2, 2, 6, 31, 34, 17, 189, 105, 23, 48, 13, 6, 9, 42, 134, 72, 134, 247, 13, 1, 1, 11, 5, 0, 48, 129, 184, 49, 11, 48, 9, 6, 3, ...>>]}, protocol: :handshake, direction: :inbound]
<<< Handshake, Certificate
[{asn1_certificates,[<<48,130,4,146,48,130,3,122,160,3,2,1,2,2,8,...>>,
<<48,130,4,113,48,130,3,89,160,3,2,1,2,2,6,31,34,17,
189,105,23,48,13,6,9,42,134,72,134,247,13...>>]}]
[debug] [message: {:server_key_exchange, <<3, 0, 23, 65, 4, 125, 168, 130, 114, 189, 216, 23, 228, 34, 221, 255, 40, 89, 96, 98, 87, 43, 41, 142, 96, 125, 107, 44, 146, 191, 154, 4, 235, 203, 208, 140, 30, 137, 46, 254, 215, 164, 217, 39, 21, 193, 18, ...>>}, protocol: :handshake, direction: :inbound]
<<< Handshake, ServerKeyExchange
[{exchange_keys,<<3,0,23,65,4,125,168,...>>}]
[debug] [message: {:ssl_tls, 22, {3, 3}, <<13, 0, 0, 221, 3, 1, 2, 64, 0, 24, 4, 1, 4, 2, 4, 3, 5, 1, 5, 2, 5, 3, 6, 1, 6, 2, 6, 3, 2, 1, 2, 2, 2, 3, 0, 189, 0, 187, 48, 129, 184, 49, 11, 48, 9, ...>>, false}, protocol: :record, direction: :inbound]
reading (230 bytes) TLS 1.2 Record Protocol, handshake
0000 - 16 03 03 00 e1 0d 00 00 dd 03 01 02 40 00 18 04 ............@...
0010 - 01 04 02 04 03 05 01 05 02 05 03 06 01 06 02 06 ................
...
[debug] [message: {:ssl_tls, 22, {3, 3}, <<14, 0, 0, 0>>, false}, protocol: :record, direction: :inbound]
reading (9 bytes) TLS 1.2 Record Protocol, handshake
0000 - 16 03 03 00 04 0e 00 00 00 .........
[debug] [message: {:certificate_request, <<1, 2, 64>>, {:hash_sign_algos, [sha256: :rsa, sha256: :dsa, sha256: :ecdsa, sha384: :rsa, sha384: :dsa, sha384: :ecdsa, sha512: :rsa, sha512: :dsa, sha512: :ecdsa, sha: :rsa, sha: :dsa, sha: :ecdsa]}, [rdnSequence: xxx]]]}, protocol: :handshake, direction: :inbound]
<<< Handshake, CertificateRequest
[{certificate_types,<<1,2,64>>},
{hashsign_algorithms,
{hash_sign_algos,
[{sha256,rsa},
{sha256,dsa},
{sha256,ecdsa},
{sha384,rsa},
{sha384,dsa},
{sha384,ecdsa},
{sha512,rsa},
{sha512,dsa},
{sha512,ecdsa},
{sha,rsa},
{sha,dsa},
{sha,ecdsa}]}},
{certificate_authorities,
[{rdnSequence,
[[{'AttributeTypeAndValue',{2,5,4,6},"DE"}],
(...)}]
[debug] [message: {:server_hello_done}, protocol: :handshake, direction: :inbound]
<<< Handshake, ServerHelloDone
I do not see any signicant differences between the final version and the release candidate; does this help?
It does help, I realized it was actually the server certificate request that I wanted to see and not the server hello. Anyway I it was not a bug in the conversion functions, but rather that the where not run due to a legacy clause matching. I think I have a solution, I will make a PR as soon as the test suites have run. (Takes a while to run the TLS suites).
@hzeus Once I fixed the first problem it turned out there was some more things needing adjusting too. But now I think my PR should solve your problem. I will work on an additional test case.
@IngelaAndin Thank you very much! I just tested your branch with our application and could successfully make a request 🎉
I have now added client certification to some test cases that will regression test this. If all goes well we should be able to merge this tomorrow and I will schedule it for upcoming OTP-26 patch.
@IngelaAndin Sorry to bother you again: I just tried to perform the HTTP Request after upgrading to 26.0.1, but I got the same error message as before - it seems that I either did a mistake when I tried the request some weeks ago, or that there was some kind of regression that was introduced in one of the later commits.
Do you want me to open another issue for that? And should I be doing the same debugging steps as before, or do you already have enough information?
@hzeus Please make a new run with logging of the handshake messages. I would prefer you make a new issue if it is not obviously the same problem.
Thanks! This is the output I get; I cannot really tell whether this is the same problem or another one; can you check and tell me if If should open a new issue or not?
[debug] [message: {:client_hello, {3, 3}, <<3, 191, 219, 2, ...], [0], %{srp: :undefined, client_hello_versions: {:client_hello_versions, [{3, 4}, {3, 3}]}, signature_algs: {:signature_algorithms, [:eddsa_ed25519, :eddsa_ed448, :ecdsa_secp521r1_sha512, :ecdsa_secp384r1_sha384, :ecdsa_secp256r1_sha256, :rsa_pss_pss_sha512, :rsa_pss_pss_sha384, :rsa_pss_pss_sha256, :rsa_pss_rsae_sha512, :rsa_pss_rsae_sha384, :rsa_pss_rsae_sha256, :rsa_pkcs1_sha512, :rsa_pkcs1_sha384, :rsa_pkcs1_sha256, {:sha512, :ecdsa}, {:sha384, :ecdsa}, {:sha256, :ecdsa}]}, signature_algs_cert: :undefined, use_srtp: :undefined, elliptic_curves: {:supported_groups, [:x25519, :x448, :secp256r1, :secp384r1]}, sni: {:sni, '....de'}, max_frag_enum: :undefined, alpn: :undefined, ec_point_formats: {:ec_point_formats, [0]}, next_protocol_negotiation: :undefined, renegotiation_info: {:renegotiation_info, :undefined}, key_share: {:key_share_client_hello, [{:key_share_entry, :x25519, <<42, 190, 255, 32, 102, 198, 19, 179, 143, 125, 110, 64, 232, 223, 163, 122, 159, 106, 226, 223, 250, 234, ...>>}]}}}, protocol: :handshake, direction: :outbound]
[debug] [message: [<<22, 3, 3, 1, 63>>, [1, <<0, 1, 59>>, <<3, 3, 3, 191, 219, 201, 169, 129, 195, 192, 171, 207, 49, 190, 199, 199, 181, 93, 235, 60, 25, 139, 124, 56, 77, 106, 141, 162, 229, 166, 43, 179, 237, 207, 32, 71, 155, 231, 227, 128, 125, 56, 86, 246, ...>>]], protocol: :record, direction: :outbound]
>>> TLS 1.3 Handshake, ClientHello
[{client_version,{3,3}},
{random,
<<3,191,219,201,169,129,195,192,171,207,49,190,199,199,181,93,235,60,25,
139,124,56,77,106,141,162,229,166,43,179,237,207>>},
{session_id,
<<71,155,231,227,128,125,56,86,246,225,40,156,109,214,75,106,80,146,246,
177,17,216,210,94,229,3,5,81,10,89,197,254>>},
{cookie,undefined},
{cipher_suites,
["TLS_EMPTY_RENEGOTIATION_INFO_SCSV","TLS_AES_256_GCM_SHA384",
"TLS_AES_128_GCM_SHA256","TLS_CHACHA20_POLY1305_SHA256",
"TLS_AES_128_CCM_SHA256","TLS_AES_128_CCM_8_SHA256",
"TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384",
"TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384",
"TLS_ECDHE_ECDSA_WITH_AES_256_CCM","TLS_ECDHE_ECDSA_WITH_AES_256_CCM_8",
"TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384",
"TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384",
"TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256",
"TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256",
"TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256",
"TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256",
"TLS_ECDHE_ECDSA_WITH_AES_128_CCM","TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8",
"TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384",
"TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384",
"TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384",
"TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384",
"TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256",
"TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256",
"TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256",
"TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256",
"TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256",
"TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256",
"TLS_DHE_RSA_WITH_AES_256_GCM_SHA384",
"TLS_DHE_DSS_WITH_AES_256_GCM_SHA384",
"TLS_DHE_RSA_WITH_AES_256_CBC_SHA256",
"TLS_DHE_DSS_WITH_AES_256_CBC_SHA256",
"TLS_DHE_RSA_WITH_AES_128_GCM_SHA256",
"TLS_DHE_DSS_WITH_AES_128_GCM_SHA256",
"TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256",
"TLS_DHE_RSA_WITH_AES_128_CBC_SHA256",
"TLS_DHE_DSS_WITH_AES_128_CBC_SHA256",
"TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA",
"TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA",
"TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA",
"TLS_ECDH_RSA_WITH_AES_256_CBC_SHA",
"TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA",
"TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA",
"TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA",
"TLS_ECDH_RSA_WITH_AES_128_CBC_SHA","TLS_DHE_RSA_WITH_AES_256_CBC_SHA",
"TLS_DHE_DSS_WITH_AES_256_CBC_SHA","TLS_DHE_RSA_WITH_AES_128_CBC_SHA",
"TLS_DHE_DSS_WITH_AES_128_CBC_SHA"]},
{compression_methods,[0]},
{extensions,
#{srp => undefined,
client_hello_versions => {client_hello_versions,[{3,4},{3,3}]},
signature_algs =>
{signature_algorithms,
[eddsa_ed25519,eddsa_ed448,ecdsa_secp521r1_sha512,
ecdsa_secp384r1_sha384,ecdsa_secp256r1_sha256,
rsa_pss_pss_sha512,rsa_pss_pss_sha384,rsa_pss_pss_sha256,
rsa_pss_rsae_sha512,rsa_pss_rsae_sha384,rsa_pss_rsae_sha256,
rsa_pkcs1_sha512,rsa_pkcs1_sha384,rsa_pkcs1_sha256,
{sha512,ecdsa},
{sha384,ecdsa},
{sha256,ecdsa}]},
signature_algs_cert => undefined,use_srtp => undefined,
elliptic_curves => {supported_groups,[x25519,x448,secp256r1,secp384r1]},
sni => {sni,"xxx.de"},
max_frag_enum => undefined,alpn => undefined,
ec_point_formats => {ec_point_formats,[0]},
next_protocol_negotiation => undefined,
renegotiation_info => {renegotiation_info,undefined},
key_share =>
{key_share_client_hello,
[{key_share_entry,x25519,
<<42,190,255,32,102,198,19,179,143,125,110,64,232,
223,163,122,159,106,226,223,250,234,55,84,4,110,
210,153,158,228,250,34>>}]}}}]
writing (324 bytes) TLS 1.2 Record Protocol, handshake
0000 - 16 03 03 01 3f 01 00 01 3b 03 03 03 bf db c9 a9 ....?...;.......
0010 - 81 c3 c0 ab cf 31 be c7 c7 b5 5d eb 3c 19 8b 7c .....1....].<..|
... ....
[debug] [message: {:ssl_tls, 22, {3, 3}, <<2, 0, 0, 83, 3, 3, 82, 208, 93, 69, 226, 203, 114, 34, 74, 8, 96, 160, 82, 231, 193, 37, 45, 194, 234, 200, 91, 139, 207, 225, 236, 168, 6, 47, 96, 124, 255, 40, 32, 149, 241, 142, 163, 152, 37, ...>>, false}, protocol: :record, direction: :inbound]
reading (92 bytes) TLS 1.2 Record Protocol, handshake
0000 - 16 03 03 00 57 02 00 00 53 03 03 52 d0 5d 45 e2 ....W...S..R.]E.
... ............
[debug] [message: {:server_hello, {3, 3}, <<82, 208, 93, 69, 226, 203, 114, 34, 74, 8, 96, 160, 82, 231, 193, 37, 45, 194, 234, 200, 91, 139, 207, 225, 236, 168, 6, 47, 96, 124, 255, 40>>, <<149, 241, 142, 163, 152, 37, 50, 246, 220, 152, 140, 51, 96, 76, 59, 94, 148, 52, 150, 93, 100, 153, 18, 232, 85, 244, 175, 62, 241, 156, 75, 46>>, <<192, 48>>, 0, %{alpn: :undefined, ec_point_formats: {:ec_point_formats, [0]}, next_protocol_negotiation: :undefined, renegotiation_info: {:renegotiation_info, <<0>>}}}, protocol: :handshake, direction: :inbound]
<<< TLS 1.2 Handshake, ServerHello
[{server_version,{3,3}},
{random,<<82,208,93,69,226,203,114,34,74,8,96,160,82,231,193,37,45,194,234,
200,91,139,207,225,236,168,6,47,96,124,255,40>>},
{session_id,<<149,241,142,163,152,37,50,246,220,152,140,51,96,76,59,94,148,
52,150,93,100,153,18,232,85,244,175,62,241,156,75,46>>},
{cipher_suite,"TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384"},
{compression_method,0},
{extensions,#{alpn => undefined,
ec_point_formats => {ec_point_formats,[0]},
next_protocol_negotiation => undefined,
renegotiation_info => {renegotiation_info,<<0>>}}}]
[debug] [message: {:ssl_tls, 22, {3, 3}, <<11, 0, 9, 20, 0, 9, 17, 0, 4, 150, 48, 130, 4, 146, 48, 130, 3, 122, 160, 3, 2, 1, 2, 2, 8, 96, 101, 2, 111, 140, 30, 223, 102, 48, 13, 6, 9, 42, 134, 72, 134, 247, 13, 1, 1, ...>>, false}, protocol: :record, direction: :inbound]
reading (2333 bytes) TLS 1.2 Record Protocol, handshake
0000 - 16 03 03 09 18 0b 00 09 14 00 09 11 00 04 96 30 ...............0
0010 - 82 04 92 30 82 03 7a a0 03 02 01 02 02 08 60 65 ...0..z.......`e
0020 - 02 6f 8c 1e df 66 30 0d 06 09 2a 86 48 86 f7 0d .o...f0...*.H...
0030 - 01 01 0b 05 00 30 81 b8 31 0b 30 09 06 03 55 04 .....0..1.0...U.
0040 - 06 13 02 44 45 31 14 30 12 06 03 55 04 07 0c 0b ...DE1.0...U....
...
[debug] [message: {:ssl_tls, 22, {3, 3}, <<12, 0, 1, 73, 3, 0, 23, 65, 4, 9, 78, 64, 128, 156, 195, 83, 228, 144, 117, 26, 248, 167, 128, 152, 165, 172, 254, 180, 159, 195, 106, 240, 123, 191, 19, 103, 65, 171, 69, 5, 13, 120, 18, 93, 97, ...>>, false}, protocol: :record, direction: :inbound]
reading (338 bytes) TLS 1.2 Record Protocol, handshake
0000 - 16 03 03 01 4d 0c 00 01 49 03 00 17 41 04 09 4e ....M...I...A..N
0010 - 40 80 9c c3 53 e4 90 75 1a f8 a7 80 98 a5 ac fe @...S..u........
... ..
[debug] [message: {:certificate, [<<48, 130, 4, 146, 48, 130, 3, 122, 160, 3, 2, 1, 2, 2, 8, 96, 101, 2, 111, 140, 30, 223, 102, 48, 13, 6, 9, 42, 134, 72, 134, 247, 13, 1, 1, 11, 5, 0, 48, 129, 184, 49, 11, 48, 9, 6, ...>>, <<48, 130, 4, 113, 48, 130, 3, 89, 160, 3, 2, 1, 2, 2, 6, 31, 34, 17, 189, 105, 23, 48, 13, 6, 9, 42, 134, 72, 134, 247, 13, 1, 1, 11, 5, 0, 48, 129, 184, 49, 11, 48, 9, 6, 3, ...>>]}, protocol: :handshake, direction: :inbound]
<<< Handshake, Certificate
[{asn1_certificates,[<<48,130,4,146,48,130,3,122,160,3,2,1,2,2,8,96,101,2,111,
140,30,223,102,48,13,6,9,42,134,72,134,247,13,1,1,11,5,
0,48,129,184,49,11,48,9,6,3,85,4,6,19,2,68,69,49,20,48,
18,6,3,85,4,7,12,11,68,117,101,115,115,101,108,100,111,
114,102,49,12,48,10,6,3,85,4,8,12,3,78,82,87,49,42,48,
40,6,3,85,4,10,12,33,87,69,65,84,32,69,108,101,99,116,
...>>,
<<48,130,4,113,48,130,3,89,160,3,2,1,2,2,6,31,34,17,
189,105,23,48,13,6,9,42,134,72,134,247,13,1,1,11,5,0,
48,129,184,49,11,48,9,6,3,85,4,6,19,2,68,69,49,20,48,
18,6,3,85,4,7,12,11,68,117,101,115,115,101,108,100,
111,114,102,49,12,48,10,6,3,85,4,8,12,3,78,82,87,49,
...>>]}]
[debug] [message: {:server_key_exchange, <<3, 0, 23, 65, 4, 9, 78, 64, 128, 156, 195, 83, 228, 144, 117, 26, 248, 167, 128, 152, 165, 172, 254, 180, 159, 195, 106, 240, 123, 191, 19, 103, 65, 171, 69, 5, 13, 120, 18, 93, 97, 182, 68, 172, 76, 70, 152, ...>>}, protocol: :handshake, direction: :inbound]
<<< Handshake, ServerKeyExchange
[{exchange_keys,<<3,0,23,65,4,9,78,64,128,156,195,83,228,144,117,26,248,167,
128,152,165,172,254,180,159,195,106,240,123,191,19,103,65,
171,69,5,13,120,18,93,97,182,68,172,76,70,152,0,167,58,171,
224,140,193,206,63,117,166,37,129,218,106,141,88,116,215,
204,69,0,4,1,1,0,160,87,222,113,131,217,229,153,233,167,
229,198,35,123,181,223,148,189,14,91,203,50,153,97,20,33,
206,184,231,28,15,56,144,27,64,154,154,28,233,133,123,195,
144,17,109,150,7,139,119,20,229,172,114,113,173,33,233,119,
113,105,50,194,168,219,110,15,239,168,33,26,229,44,132,191,
184,120,249,64,229,7,53,107,114,44,131,154,104,111,64,23,
28,130,129,159,97,147,156,230,191,201,87,207,224,17,236,
245,190,134,100,39,38,19,16,173,72,209,52,111,88,17,196,19,
84,6,87,30,77,46,126,104,226,27,237,9,219,164,129,70,215,
85,28,209,64,15,158,211,59,56,16,120,105,8,98,149,104,82,
91,217,114,208,173,252,185,20,95,77,99,139,1,18,28,134,90,
76,111,191,97,211,162,181,14,245,85,139,84,53,187,118,145,
11,122,175,104,158,223,119,19,181,29,211,154,142,152,2,99,
242,213,244,78,92,194,14,78,226,19,237,57,5,124,84,154,36,
174,57,181,25,28,37,255,108,229,195,46,102,160,204,43,176,
227,240,223,12,121,43,95,13,245,232,220,83,160,88,195,243,
235,218>>}]
[debug] [message: {:ssl_tls, 22, {3, 3}, <<13, 0, 0, 221, 3, 1, 2, 64, 0, 24, 4, 1, 4, 2, 4, 3, 5, 1, 5, 2, 5, 3, 6, 1, 6, 2, 6, 3, 2, 1, 2, 2, 2, 3, 0, 189, 0, 187, 48, 129, 184, 49, 11, 48, 9, ...>>, false}, protocol: :record, direction: :inbound]
reading (230 bytes) TLS 1.2 Record Protocol, handshake
0000 - 16 03 03 00 e1 0d 00 00 dd 03 01 02 40 00 18 04 ............@...
...
[debug] [message: {:ssl_tls, 22, {3, 3}, <<14, 0, 0, 0>>, false}, protocol: :record, direction: :inbound]
reading (9 bytes) TLS 1.2 Record Protocol, handshake
0000 - 16 03 03 00 04 0e 00 00 00 .........
[debug] [message: {:certificate_request, <<1, 2, 64>>, {:hash_sign_algos, [sha256: :rsa, sha256: :dsa, sha256: :ecdsa, sha384: :rsa, sha384: :dsa, sha384: :ecdsa, sha512: :rsa, sha512: :dsa, sha512: :ecdsa, sha: :rsa, sha: :dsa, sha: :ecdsa]}, [rdnSequence: [[{:AttributeTypeAndValue, {2, 5, 4, 6}, 'DE'}], [{:AttributeTypeAndValue, {2, 5, 4, 7}, ...]]]}, protocol: :handshake, direction: :inbound]
<<< Handshake, CertificateRequest
[{certificate_types,<<1,2,64>>},
{hashsign_algorithms,
{hash_sign_algos,
[{sha256,rsa},
{sha256,dsa},
{sha256,ecdsa},
{sha384,rsa},
{sha384,dsa},
{sha384,ecdsa},
{sha512,rsa},
{sha512,dsa},
{sha512,ecdsa},
{sha,rsa},
{sha,dsa},
{sha,ecdsa}]}},
{certificate_authorities,
[{rdnSequence,
[[{'AttributeTypeAndValue',{2,5,4,6},"DE"}],
...]]}]}]
[debug] [message: {:server_hello_done}, protocol: :handshake, direction: :inbound]
<<< Handshake, ServerHelloDone
[]
[debug] [message: {:certificate, []}, protocol: :handshake, direction: :outbound]
>>> Handshake, Certificate
[{asn1_certificates,[]}]
[debug] [message: [<<22, 3, 3, 0, 7>>, <<11, 0, 0, 3, 0, 0, 0>>], protocol: :record, direction: :outbound]
writing (12 bytes) TLS 1.2 Record Protocol, handshake
0000 - 16 03 03 00 07 0b 00 00 03 00 00 00 ............
[debug] [message: {:client_key_exchange, {:client_ec_diffie_hellman_public, <<4, 0, 55, 239, 49, 34, 34, 199, 83, 239, 130, 189, 64, 248, 158, 235, 110, 153, 136, 71, 72, 92, 240, 194, 55, 118, 41, 152, 220, 247, 72, 129, 22, 161, 43, 53, 147, 222, 71, 157, 87, 146, 248, 67, 178, ...>>}}, protocol: :handshake, direction: :outbound]
[debug] [message: [<<22, 3, 3, 0, 70>>, <<16, 0, 0, 66, 65, 4, 0, 55, 239, 49, 34, 34, 199, 83, 239, 130, 189, 64, 248, 158, 235, 110, 153, 136, 71, 72, 92, 240, 194, 55, 118, 41, 152, 220, 247, 72, 129, 22, 161, 43, 53, 147, 222, 71, 157, 87, 146, ...>>], protocol: :record, direction: :outbound]
[debug] [message: [<<20, 3, 3, 0, 1>>, <<1>>], protocol: :record, direction: :outbound]
>>> Handshake, ClientKeyExchange
[{exchange_keys,
{client_ec_diffie_hellman_public,
<<4,0,55,239,49,34,34,199,83,239,130,189,64,248,158,235,110,153,
136,71,72,92,240,194,55,118,41,152,220,247,72,129,22,161,43,53,
147,222,71,157,87,146,248,67,178,201,86,142,38,98,162,178,73,57,
202,184,173,139,65,167,9,156,74,83,95>>}}]
writing (75 bytes) TLS 1.2 Record Protocol, handshake
0000 - 16 03 03 00 46 10 00 00 42 41 04 00 37 ef 31 22 ....F...BA..7.1"
0010 - 22 c7 53 ef 82 bd 40 f8 9e eb 6e 99 88 47 48 5c ".S...@...n..GH\
0020 - f0 c2 37 76 29 98 dc f7 48 81 16 a1 2b 35 93 de ..7v)...H...+5..
0030 - 47 9d 57 92 f8 43 b2 c9 56 8e 26 62 a2 b2 49 39 G.W..C..V.&b..I9
0040 - ca b8 ad 8b 41 a7 09 9c 4a 53 5f ....A...JS_
writing (6 bytes) TLS 1.2 Record Protocol, change_cipher_spec
0000 - 14 03 03 00 01 01 ......
[debug] [message: {:finished, <<10, 208, 105, 48, 220, 224, 243, 154, 241, 62, 97, 191>>}, protocol: :handshake, direction: :outbound]
>>> Handshake, Finished
[{verify_data,<<10,208,105,48,220,224,243,154,241,62,97,191>>}]
[debug] [message: [<<22, 3, 3, 0, 40>>, <<48, 205, 223, 33, 137, 109, 140, 31, 193, 81, 14, 2, 49, 132, 20, 188, 180, 189, 110, 39, 92, 224, 203, 49, 24, 188, 153, 213, 78, 211, 106, 55, 225, 106, 35, 244, 236, 233, 36, 112>>], protocol: :record, direction: :outbound]
writing (45 bytes) TLS 1.2 Record Protocol, handshake
0000 - 16 03 03 00 28 30 cd df 21 89 6d 8c 1f c1 51 0e ....(0..!.m...Q.
0010 - 02 31 84 14 bc b4 bd 6e 27 5c e0 cb 31 18 bc 99 .1.....n'\..1...
0020 - d5 4e d3 6a 37 e1 6a 23 f4 ec e9 24 70 .N.j7.j#...$p
[debug] [message: {:ssl_tls, 21, {3, 3}, <<2, 46>>, false}, protocol: :record, direction: :inbound]
reading (7 bytes) TLS 1.2 Record Protocol, alert
0000 - 15 03 03 00 02 02 2e .......
[notice] TLS :client: In state :cipher received SERVER ALERT: Fatal - Certificate Unknown
@hzeus I think that the problem is likely that the client is not able to verify that its certificate chain is signed by a root CA that is present in the certificate_authorities presented by the server in its certificate-request message. This could possible be because the client is only configured with its own cert and does not have it chain certificates. It is possible to configure an erlang TLS server to not send an certificate_authorities extension and then it might accept a client that only send its own cert and not the chain, if the server is able to recreate the chain. But the client is suppose to send it whole chain. And if the certificate_authorites extension is sent the client will only send a certifcate that adheres to it.
Before I dig deeper into the tls algorithm: I just checked your previous suggestion with setting the signature_algs
- Parameter; and could successfully make a request.
I could then boil it down to setting signature_algs
to only [{sha256, rsa}]
and make a successful request. Is there any chance this might be a regression bug in detecting the correct algorithm? (@IngelaAndin )
@hzeus I think you should take a look at the following PR https://github.com/erlang/otp/pull/7372 , it might help clarify things!
@IngelaAndin Thank you, that helped 👍
Describe the bug After upgrading to OTP 26, we cannot establish a ssl connection to a server that requires a client certificate, instead we receive
The error message is the same one that we received after the update to OTP 24.3 last year, so maybe this is a regression of https://github.com/erlang/otp/issues/5835 ?
Affected versions
asdf
)Additional context The error happens when we are trying to connect to the same server as in https://github.com/erlang/otp/issues/5835 which was resolved in https://github.com/erlang/otp/pull/5919 . Please let me know if I can help with tracing / debugging.