SSL connection issue

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?

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)

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}]
]]

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

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'}}}

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?

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

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.

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 . Thanks everyone!

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.

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