Affected: faye-websocket

In faye-websocket before version 0.11.0, there is a lack of certification validation in TLS handshakes. The `Faye::WebSocket::Client` class uses the `EM::Connection#start_tls` method in EventMachine to implement the TLS handshake whenever a `wss:` URL is used for the connection. This method does not implement certificate verification by default, meaning that it does not check that the server presents a valid and trusted TLS certificate for the expected hostname. That means that any `wss:` connection made using this library is vulnerable to a man-in-the-middle attack, since it does not confirm the identity of the server it is connected to. For further background information on this issue, please see the referenced GitHub Advisory. Upgrading `faye-websocket` to v0.11.0 is recommended.

Affected: RubyGems: faye-websocket

The `Faye::WebSocket::Client` class uses the [`EM::Connection#start_tls`][1] method in [EventMachine][2] to implement the TLS handshake whenever a `wss:` URL is used for the connection. This method does not implement certificate verification by default, meaning that it does not check that the server presents a valid and trusted TLS certificate for the expected hostname. That means that any `wss:` connection made using this library is vulnerable to a man-in-the-middle attack, since it does not confirm the identity of the server it is connected to.

This has been a requested feature in EventMachine for many years now; see for example [#275][3], [#378][4], and [#814][5]. In June 2020, [em-http-request][6] published an [advisory][7] related to this problem and fixed it by [implementing TLS verification][8] in their own codebase; although EventMachine does not implement certificate verification itself, it provides an extension point for the caller to implement it, called [`ssl_verify_peer`][9]. Based on this implementation, we have incorporated similar functionality into [faye-websocket for Ruby][10], such that we use the `OpenSSL` module to perform two checks:

- The chain of certificates presented by the server is valid and ultimately trusted by your root certificate set -- either your system default root certificates, or a set provided at runtime - The final certificate presented by the server is valid for the hostname used in the request URI; if the connection is made via a p…