zkessin

HTTPS handshake error: Fatal - Handshake Failure

I am trying to hit an HTTPS endpoint and when I call it HTTPoison returns this error

 {:error, %HTTPoison.Error{id: nil, reason: {:tls_alert, {:handshake_failure, 'TLS client: In state hello received SERVER ALERT: Fatal - Handshake Failure\n'}}}}

I am passing these options to the get command

   http_options = [ssl: [versions: [:"tlsv1.2"], verify: :verify_none]]
    {:ok, results} = get(url, [], http_options)

I have been banging my head on this for a few days now and my google-fu has failed me, any suggestions on how to fix this?

16 comments

#httpoison #hackney

0 7821 16

2023-03-17 03:42:21 UTC

Most Liked

rjk

just to add as a helper to debug these calls: :hackney_trace.enable(:max, :io) logs your requests to STDOUT on the REPL/console (it shows the enabled cipers for example).

Post #11

voltone

Ah, of course, I had forgotten all about the removal of RSA key exchange already. One would expect a site such as this to support (EC)DHE: I mean, it is 2021…

Anyway, keep in mind that :ssl.cipher_suites/1,2 is deprecated. The ‘official’ way to select custom ciphers would be something like:

defaults = :ssl.cipher_suites(:default, :"tlsv1.2")
rsa_kx =
  :ssl.cipher_suites(:all, :"tlsv1.2")
  |> :ssl.filter_cipher_suites(
    key_exchange: &(&1 == :rsa),
    cipher: &(&1 in [:aes_128_cbc, :aes_128_gcm, :aes_256_cbc, :aes_256_gcm]),
  )
HTTPoison.get!("https://api.etrade.com", [], ssl: [ciphers: defaults ++ rsa_kx])

Also, and more importantly, as @Exadra37 pointed out, passing custom ssl options to Hackney/HTTPoison will override its secure defaults, including verify: :verify_peer and the CA trust store. So actually, for a secure connection you’d have to call:

HTTPoison.get!("https://api.etrade.com", [], ssl: [
  ciphers: defaults ++ rsa_kx,
  verify: :verify_peer,
  cacertfile: :certifi.cacertfile(),
  depth: 3,
  customize_hostname_check: [
    match_fun: :public_key.pkix_verify_hostname_match_fun(:https)
  ]
])

Post #10

voltone

The server aborts the handshake, so it looks like it doesn’t like something the client sends. Unfortunately the server does not (cannot) indicate exactly what it didn’t like through the TLS alert mechanism. It might record more details in its local log, but I’m guessing you don’t have access to that log.

I would trace a successful handshake (using curl or openssl) and an unsuccessful one with Wireshark, and compare. You can also trace the handshake by adding log_level: :debug to the ssl options in the client, but that might be hard to compare with the output of other clients.

Post #3

Last Post!

tmariaz

Still same error when calling the api… Do I have to look for the log?

When I run the following I get the TLS info.

curl -I -v --tlsv1.2 --tls-max 1.2 https://myserver/api/endpoint
*   Trying myserver-ip-address:443...
* Connected to myserver (myserver-ip-address) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
*  CAfile: ~/ssl/cacert.pem
*  CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384

What am I missing?

Post #17