As far as I can tell the server chokes on the ClientHello message if the TLS version in the record layer doesn’t match the version in the client version field. This is a known area of compatibility issues (see RFC 5246, Appendix E).

If this is indeed the issue, then the workaround of selecting TLSv1.2 as the desired version should work. At least the server should not unceremoniously close the TCP connection (assuming it is configured to support TLSv1.2), though it might still fail with a handshake error. If you have a reproducible example of a connection that fails even when the version is constrained, can you share the details?

As the RFC mentions, there is no easy answer for universal interoperability. It may take several handshake attempts to connect to a ‘broken’ server. HTTPoison does not perform these retries for you, so you’d have to add some logic to your app to try and recover from failed requests.

It looks like the issue has been resolved in OTP 20. So the workaround to force the connection to use TLS 1.2 should no longer be needed.

From the release notes:

OTP-13820    Application(s): ssl

             *** HIGHLIGHT ***

             TLS-1.2 clients will now always send hello messages on
             its own format, as opposed to earlier versions that
             will send the hello on the lowest supported version,
             this is a change supported by the latest RFC.

             This will make interoperability with some newer servers
             smoother. Potentially, but unlikely, this could cause a
             problem with older servers if they do not adhere to the
             RFC and ignore unknown extensions.

I’ve had a similar issue with the Microsoft Outlook servers Unable to send email using office365 smtp servers · Issue #114 · gen-smtp/gen_smtp · GitHub The Outlook servers close the connection as soon as an SSL request is sent before a subsequent TLS request. However, the Google Email servers didn’t seem to have this problem. The problem with erlang ssl is that during the tls connection setup it first (incorrectly) sends an SSL request and then tries to send a TLS request. The fix for this is to always pass [{:versions, [:'tlsv1.2']}] as an option while doing ssl connections.