This is a good reminder that whenever you’re using TLS, you want to make sure to add a case to the test suite that checks whether it will connect to a server where the certs don’t match.
Yep. What’s interesting is that even if we had tests for it (we don’t and tend to mock out Hex to avoid pummeling it with fake requests, but I should add one that pings a loopback host with a self-signed cert), they would need to be specifically for that code path; other uses of TLS (I.e. when fetching code updates or other types of dependencies) are actually properly working. This ends up being more areas to cover than it initially looks like, but would be useful.
Taking my own advice, it looks like I may have found a bug in maven-resolver (used by Leiningen) in how it validates wildcard certificates! I had manually tested previously with some configurations of bad TLS servers, but the specific misconfiguration on https://wrong.host.badssl.com seems to uncover a new problem we weren’t aware of. (it’s not catastrophically bad, but it really looks like a legitimate if difficult-to-exploit bug to me)
Yep. But for mix users there’s generally no risk because they use us for an Erlang project build interface, but take over dependency fetching on their own.
This is a good reminder that whenever you’re using TLS, you want to make sure to add a case to the test suite that checks whether it will connect to a server where the certs don’t match.
https://wrong.host.badssl.com/ is a handy tool for this.
Yep. What’s interesting is that even if we had tests for it (we don’t and tend to mock out Hex to avoid pummeling it with fake requests, but I should add one that pings a loopback host with a self-signed cert), they would need to be specifically for that code path; other uses of TLS (I.e. when fetching code updates or other types of dependencies) are actually properly working. This ends up being more areas to cover than it initially looks like, but would be useful.
Taking my own advice, it looks like I may have found a bug in maven-resolver (used by Leiningen) in how it validates wildcard certificates! I had manually tested previously with some configurations of bad TLS servers, but the specific misconfiguration on https://wrong.host.badssl.com seems to uncover a new problem we weren’t aware of. (it’s not catastrophically bad, but it really looks like a legitimate if difficult-to-exploit bug to me)
Huh, hadn’t expected this to pop up here. Thanks for the extra visibility and hopefully the post is informative.
I remember hex SSL being flakey as hell a few years back…is this related to that?
Unrelated as far as I know. Might just be the CDN setup that is now better than it used to be.
Thank you! Also, thanks for all your work in the ecosystem. :)
Edit:
For Elixir users, this should be
$ mix local.rebar, right?Yep. But for mix users there’s generally no risk because they use us for an Erlang project build interface, but take over dependency fetching on their own.