Repository navigation
SSL peers aren't verfied #1
Description
The Erlang :ssl module is very strict in its certification checking.
The result of that is that, if I understand correctly, verify_peer option works when everything is basically done correctly.
What I found out is that the internet is obviously broken everywhere, the :ssl module reliably connects to just about zero of the sites I tried when verifying the peer with CA certs from erlang-certifi.
So I tried using the verify_fun option with ssl_verify_fun.erl, plus the partial_chain based off of hackney's implementation... But it didn't work.
After that I tried a bunch of other stuff and made some progress, changed some more stuff only to find that it still didn't work. So I threw my hands up and made everything insecure by default.
TLDR;
I'm not smart enough to make the :ssl module's verify_peer work correctly.
Activity
[-]SSL Connections aren't secure[/-][+]SSL peers aren't verfied[/+]xlphs commentedon Jun 13, 2017
Not sure what you are trying to accomplish but you could simply pass ssl options on. I wrote a short article on
verify_funthat shows how to do certificate pinning, hopefully it helps.Azolo commentedon Jun 13, 2017
@xlphs Cool, thanks for that article. It actually shows me a different way that the
sslmodule could be used and I need to keep that in mind.What I am trying to accomplish is just being able to open a tcp socket to a site like
https://google.comand verify that I am in fact connecting tohttps://google.comthrough the certificate verification. Erlang's:sslmodule seems super picky about how you do that.khodzha commentedon Jul 9, 2017
maybe you should take a look at elixir-socket?
i was trying to connect to wss://eu-central434.discord.gg:80, elixir-socket could connect, yet websockex returns %WebSockex.ConnError{original: {:tls_alert, 'record overflow'}}
Azolo commentedon Jul 9, 2017
@khodzha Thanks for the info. I think it's possible that
elixir-socketis ignoring the:80and using port 443 because of thewssprotocol. I don't think that Discord is handleSSLconnections on port 80.khodzha commentedon Jul 9, 2017
yeah, sorry for trouble
discord docs were quite confusing there, connecting without port and with some query params works as expected
👌
brian-petersen commentedon Nov 22, 2021
I spent a good part of yesterday working with Erlang's
:sslto get it to work with[verify: :verify_peer]. I too found it a bit confusing and hard to work with. I followed Hackney's:sslsetup as best I could (as documented here).I got it working to a point -- but I'm not leveraging https://github.com/deadtrickster/ssl_verify_fun.erl like the Hackney project is. I'm not sure what state this puts it in -- but this is the workin 8000 g code I have so far:
The
CAStore.file_path()call comes from https://github.com/elixir-mint/castore.As far I can tell, the only thing really missing from this setup is something like this:
(Notice that
check_hostnameis a charlist.) Hope this helps someone!Merge pull request #1 from henkoch/master
Merge pull request #1 from ZenHive/fix/ping-pong-payload-handling
Verify TLS peers by default
neilberkman commentedon Oct 22, 2026
PR #144 verifies peers by default:
verify: :verify_peerwith the OS trust store from:public_key.cacerts_get/0on OTP 25+,:castoreas a fallback, hostname matching with the:httpsmatch function, andinsecure: trueas the explicit opt-out.cacerts:andssl_options:keep their precedence. On older OTP with no trust store available,open_socket/1returns aConnErrorthat names the options instead of raising.Context for the timing: OTP 26 made
verify_peerthesslclient default, so the library default is now the remaining gap, and it reached downstream users this week as req_llm's GHSA-6vww-5m28-f26v (API keys and OAuth tokens over unverified TLS). The PR also regenerates the test certificates with a subjectAltName, since OTP 29 rejects CN-only certificates and three TLS tests onmasteralready fail for that reason.