Hi all, This email is about a potential MITM attack, I would like to get some input on my proposed solution. *Disclaimer: I'm not an oslo.messaging expert or even versed in its codebase but I have a good* * number of hours working with TLS already.* Back in September, there was a fix[1] in py-amqp to stop to use deprecated method ssl.wrap_socket. Although I didn't follow anything about oslo.messaging, the PR was brought to my attention by Hervé, another oslo core, who sees me as an SME on TLS among the oslo cores. I didn't follow the entire conversation back then, I was only able to give some quick input, but Hervé was able to finish the PR with the help of another developer. Then earlier this month, another PR[2] was reintroducing a couple of parameters that got dropped in the deprecation fix. At that point it was raised the possibility of a MITM attack in an issue[3] and by reintroducing the dropped parameters, the problem should be fixed. A couple of days went by and I started to have a hunch that there could still be more to fix. I went to py-amqp codebase instead of just looking to the diffs on GitHub and noticed a not straightforward logic on how verify_mode and check_hostname were being set. Today I had time to go back to the py-amqp codebase and rework the _wrap_socket_sni() method. I've put up this PR[4] and it is already failing in my travis[5] for integration tests which make me believe that the client sockets were actually not validating the server certs. There are a few more comments on the fix in the description of PR[4]. [1]: https://github.com/celery/py-amqp/pull/327 [2]: https://github.com/celery/py-amqp/pull/344 [3]: https://github.com/celery/py-amqp/issues/342 [4]: https://github.com/celery/py-amqp/pull/347 [5]: https://travis-ci.com/github/moisesguimaraes/py-amqp/builds/204747399 Thanks, -- Moisés Guimarães Software Engineer Red Hat <https://www.redhat.com> <https://red.ht/sig>