SSL connection issue

Questions / Help
,
1

Hi there,
I’ve encountered ssl handshake issue, details:

Elixir 1.4.2, Erlang 19.3
code:

HTTPoison.get("https://api.searchads.apple.com/...", [], [ssl: [keyfile: "...pem", certfile: "...cert.pem", ]])
# [error] SSL: :certify: tls_connection.erl:715:Fatal error: handshake failure - malformed_handshake_data

This specific query works perfectly fine via curl and python.

After investigating a bit (wireshark etc), the exact issue was found: server wants specifically TLS_RSA_WITH_AES_128_GCM_SHA256

… aaand elixir/erlang do not list such thing in its handshake

:ssl.cipher_suites(:openssl)
['ECDHE-ECDSA-AES256-GCM-SHA384', ...] #- no mentions of required chipher

:ssl.cipher_suites(:erlang)
 [{:ecdhe_ecdsa, :aes_256_gcm, :null, :sha384},
 {:ecdhe_rsa, :aes_256_gcm, :null, :sha384},
 ...
 {:rsa, :aes_128_gcm, :null, :sha256} # <-- that's it

Also, present in the source code: https://github.com/erlang/otp/blob/maint-19/lib/ssl/src/ssl_cipher.erl#L703

Still, i can’t switch it on:

... , versions: [:'tlsv1'], ciphers: ["TLS-RSA-WITH-AES-128-GCM-SHA256"] # -> same error
... , versions: [:'tlsv1'], ciphers: ["TLS_RSA_WITH_AES_128_GCM_SHA256"] # -> same error
... , versions: [:'tlsv1'], ciphers: [{:rsa, :aes_128_gcm, :null, :sha256}] # -> same error
... , ciphers: [{:rsa, :aes_128_gcm, :null, :sha256}] # -> same error
etc

Wireshark confirms elixir/erlang still sending list of cipher suits that not intersect with desired cipher (weirdly, it is different a bit each time, adding/removing some useless outdated ciphers).

Behavior confirmed on OSX brew installation and linux docker one (alpine)

Any thoughts how to proceed?

1 Like
2

This thread on the Erlang mailing list seems to discuss a similar issue. The linked post suggests that what you tried with explicitly setting the ciphers should work. However, I now see you are using Elixir strings for the cipher identifiers, but I’m pretty sure the erlang ssl module expects erlang string (char lists in Elixir). Maybe that’s the problem?

3

Tried erlang strings already, don’t work at all, throwing errors (whereas elixir strings and tuples are silently accepted):

... , ciphers: ['TLS_RSA_WITH_AES_128_GCM_SHA256']
# ->
{:error,
 %HTTPoison.Error{id: nil,
  reason: {:options, {:ciphers, ['TLS-RSA-WITH-AES-128-GCM-SHA256']}}}}

...
{:error,
 %HTTPoison.Error{id: nil,
  reason: {:options, {:ciphers, ['TLS_RSA_WITH_AES_128_GCM_SHA256']}}}}

(atoms, just in case, throw the same error)

4

Specifying the cipher as a tuple as returned from :ssl.cipher_suites/1 seems to work though:

HTTPoison.get "https://google.com", [], [ssl: [ciphers: [{:rsa, :aes_128_gcm, :null, :sha256}]
]]
1 Like
7

seems to work though:

well, kinda - after playing with params i got cipher suite activated:

 Cipher Suites (2 suites)
                Cipher Suite: TLS_EMPTY_RENEGOTIATION_INFO_SCSV (0x00ff)
                Cipher Suite: TLS_RSA_WITH_AES_128_GCM_SHA256 (0x009c)

yet it didn’t help much, there are some other blocking issue exists :frowning:

still getting

[error] SSL: :certify: tls_connection.erl:715:Fatal error: handshake failure - malformed_handshake_data
{:error, %HTTPoison.Error{id: nil, reason: {:tls_alert, 'handshake failure'}}}
8

This is a bit of a long shot, but… the server requires a client certificate, and I’ve seen lots of unhelpful alert responses and log messages when things go wrong with client certs.

Does the client certificate include an intermediate cert? The way Erlang builds the chain of certs that is sent to the server is a bit different from some other tools. Instead of just sending all the certificates it finds in the PEM file, it expects to find just the end-certificate in there. It then scans the cacerts file (the same one that holds the trusted roots for verifying the server) for any intermediates that can be chained to it.

So, if the client cert file does indeed contain more than one cert, did you copy the intermediate CAs to the cacerts file?

9

Thank you, that could be the reason. Certificate contains 3 CERTIFICATE sections. Playing with it atm.
No progress so far though

... [ssl: [keyfile: "some.key", certfile: "cert-1.pem",  cacertfile: "certs-1,3.pem", ciphers: [{:rsa, :aes_128_gcm, :null, :sha256}], versions: [:"tlsv1.2"]]])

# cert 1
[error] SSL: :certify: tls_connection.erl:715:Fatal error: handshake failure - malformed_handshake_data
{:error, %HTTPoison.Error{id: nil, reason: {:tls_alert, 'handshake failure'}}}
# cert 2 and 3
[info] [83, 83, 76, 32, 87, 65, 82, 78, 73, 78, 71, 58, 32, 73, 103, 110, 111, 114, 105, 110, 103, 32, 97, 32, 67, 65, 32, 99, 101, 114, 116, 32, 97, 115, 32, 105, 116, 32, 99, 111, 117, 108, 100, 32, 110, 111, 116, 32, 98, 101, ...]
{:error, %HTTPoison.Error{id: nil, reason: :closed}}

decoded numbers: SSL WARNING: Ignoring a CA cert as it could not be (probably ends with correctly decoded)
Probably i’m not doing something right, just extracted one section to separate file and included other two as cacert.
Looks like it’s correct direction to dig in, thanks @voltone

P.S. cURL’s cacert bundle didn’t help as well

10

Instead of using the :cacertfile use the :cacerts option.

cert1 = File.read!("path/to/cert1.pem") |> :public_key.pem_decode
cert2 = File.read!("path/to/cert2.pem") |> :public_key.pem_decode

cacerts = [cert1, cert2]

SSL in Erlang is the most confusing thing ever.

3 Likes
11

Thanks for the tip.
The most powerful, flexible, counterintuitive and illogical ssl implementation i’ve encountered.
providing cacerts as cacerts: [cert1, cert2] doesn’t work either, producing the same SSL WARNING: Ignoring a CA cert as it could not be... warning per line + handshake failure or reason: :closed
:public_key.pem_decode works just fine, producing parsed data. tried some other formats - no luck as well.

At this moment i gave up and just wrote wrapper which uses curl . :frowning: Thanks everyone!

12

I agree, even after looking at and trying to replicate hackney’s implementation for SSL connections, I still can’t get SSL connections working correctly.

It’s absolutely mind-boggling how crazy it is to establish a client SSL connection.

13

I can’t remember if I ever tried using the ssl_verify_fun package myself, but I have tried Erlang/OTP 20’s built-in :public_key.pkix_verify_hostname and it seems to work as advertised:

https://blog.voltone.net/post/11

14

You can verify each of the PEM certificates by copy & pasting them (one at a time) into openssl x509 -text -noout: presumably if something is wrong with the PEM file contents, OpenSSL would also throw an error. In the output, note the subject and issuer, so you’ll know which PEM certificate is which, i.e. which one needs to be referenced from certfile and which ones need to go in the CA store.

The server tells me (when connecting using openssl s_client -connect api.searchads.apple.com:443) that it expects a client certificate that can be traced back to one of these root CAs:

Acceptable client certificate CA names
/CN=Apple Corporate Root CA/OU=Certification Authority/O=Apple Inc./C=US
/CN=Apple Corporate External Authentication CA 1/OU=Certification Authority/O=Apple Inc./C=US

Presumably the intermediate CAs linking your end-certificate to one of these root CAs are in the PEM file.

2 Likes
15

That’s actually useful, thanks!
openssl says all good, 1st one (out of 3 bundled) is personal and others are intermediate (which is expected).
And of course i’ve tried it this way, always getting handshake failure - malformed_handshake_data as a response. I fear the root is deeper, maybe some misbehaving elliptic curve or something like that, and that’s not distro-dependent (tried various OSes, erlang versions, including 18.x). It wastes way too much time :frowning:

16

I was having this same problem. The solutions provided here worked if you’re using a weak encryption AES128 but does not work for AES256.

HTTPoison supports the full list of SSL supported by erlang’s ssl. To get HTTPoison to work correctly with ssl specify the options like this.

HTTPoison.get! “https://google.com”, [], [ssl: [ciphers: [“ECDHE-ECDSA-AES128-SHA256”,“ECDHE-ECDSA-AES128-SHA”]]]

that should solve the problem.

1 Like
17

Unfortunately don’t work for me, there are some another issue persists. Using wrapped curl for now