In most applications, the decision whether a given TLS peer is trusted is determined by a global policy: either all is well (known issuer, not expired, correct hostname, etc.) or something is wrong, the decision does not depend on any kind of context. TLS session resumption and HTTP keep-alive are performance optimisations that work very well as long as this assumption holds.

In my talk I mentioned testing (automatic, or manual) as a scenario where these features can lead to unexpected results, and I pointed out how to disable them to get predictable results. But I do believe most users will want to leave them enabled in production.

In the scenario you describe, where some other process establishes unverified TLS connections, the real solution is of course to get that other process fixed.

If this is not possible, you’d have to take control of some of the lower layers yourself, to keep the secure and insecure parts of your application separate. At the HTTP layer you may be able to set up different connection pools (in :httpc, define a custom ‘profile’ and use it instead of the default one; the profile is the ‘reference’ you mentioned, it’s just that there is an implicit default). At the TLS layer you’d have to disable connection reuse, or manage it yourself using the client_reuse_sessions: :save and client_reuse_session options.

Mint only helps in that it does not use a connection pool, but at the TLS layer it uses the standard :ssl application, with the same connection reuse behaviour as other HTTP clients.

Thanks!

I found hackney / httpc reuses http connection across different function calls, even they do not pass same references. This is bad behavior - as your SSL option might not be honored if other process calls the “bad cert” URL with verify_none. Wow.

I really hope mint get adopted. No state MUST be shared without explicit passing references!