faye

Faye uses em-http-request and faye-websocket in the Ruby version of its client. Those libraries both use 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 https: or wss: connection made using these libraries is vulnerable to a man-in-the-middle attack, since it does not confirm the identity of the server it is connected to.

The first request a Faye client makes is always sent via normal HTTP, but later messages may be sent via WebSocket. Therefore it is vulnerable to the same problem that these underlying libraries are, and we needed both libraries to support TLS verification before Faye could claim to do the same. Your client would still be insecure if its initial HTTPS request was verified, but later WebSocket connections were not.

This has been a requested feature in EventMachine for many years now; see for example #275, #378, and #814. In June 2020, em-http-request published an advisory related to this problem and fixed it by implementing TLS verification 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. Based on this implementation, we have incorporated similar functionality into faye-websocket.

After implementing verification in v1.1.6, em-http-request has elected to leave the :verify_peer option switched off by default. We have decided to enable this option by default in Faye, but are publishing a minor release with added functionality for configuring it. We are mindful of the fact that this may break existing programs, but we consider it much more important that all clients have TLS verification turned on by default. A client that is not carrying out verification is either:

• talking to the expected server, and will not break under this change
• being attacked, and would benefit from being alerted to this fact
• deliberately talking to a server that would be rejected by verification

The latter case includes situations like talking to a non-public server using a self-signed certificate. We consider this use case to be "working by accident", rather than functionality that was actively supported, and it should be properly and explicitly supported instead.

We are releasing Faye v1.4.0, which enables verification by default and provides a way to opt out of it:

client = Faye::Client.new('https://example.com/', tls: { verify_peer: false })

Unfortunately we can't offer an equivalent of the :root_cert_file option that has been added to faye-websocket, because em-http-request does not support it. If you need to talk to servers whose certificates are not recognised by your default root certificates, then you need to add its certificate (or another one that can verify it) to your system's root set.

The same functionality is now supported in the Node.js version, with a tls option whose values will be passed to the https and tls modules as appropriate when making connections. For example, you can provide your own CA certificate:

var client = new faye.Client('https://example.com/', {
  tls: {
    ca: fs.readFileSync('path/to/certificate.pem')
  }
});

For further background information on this issue, please see faye#524 and faye-websocket#129. We would like to thank Tero Marttila and Daniel Morsing for providing invaluable assistance and feedback on this issue.

Faye uses em-http-request and faye-websocket in the Ruby version of its client. Those libraries both use 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 https: or wss: connection made using these libraries is vulnerable to a man-in-the-middle attack, since it does not confirm the identity of the server it is connected to.

The first request a Faye client makes is always sent via normal HTTP, but later messages may be sent via WebSocket. Therefore it is vulnerable to the same problem that these underlying libraries are, and we needed both libraries to support TLS verification before Faye could claim to do the same. Your client would still be insecure if its initial HTTPS request was verified, but later WebSocket connections were not.

This has been a requested feature in EventMachine for many years now; see for example #275, #378, and #814. In June 2020, em-http-request published an advisory related to this problem and fixed it by implementing TLS verification 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. Based on this implementation, we have incorporated similar functionality into faye-websocket.

After implementing verification in v1.1.6, em-http-request has elected to leave the :verify_peer option switched off by default. We have decided to enable this option by default in Faye, but are publishing a minor release with added functionality for configuring it. We are mindful of the fact that this may break existing programs, but we consider it much more important that all clients have TLS verification turned on by default. A client that is not carrying out verification is either:

• talking to the expected server, and will not break under this change
• being attacked, and would benefit from being alerted to this fact
• deliberately talking to a server that would be rejected by verification

The latter case includes situations like talking to a non-public server using a self-signed certificate. We consider this use case to be "working by accident", rather than functionality that was actively supported, and it should be properly and explicitly supported instead.

We are releasing Faye v1.4.0, which enables verification by default and provides a way to opt out of it:

client = Faye::Client.new('https://example.com/', tls: { verify_peer: false })

Unfortunately we can't offer an equivalent of the :root_cert_file option that has been added to faye-websocket, because em-http-request does not support it. If you need to talk to servers whose certificates are not recognised by your default root certificates, then you need to add its certificate (or another one that can verify it) to your system's root set.

The same functionality is now supported in the Node.js version, with a tls option whose values will be passed to the https and tls modules as appropriate when making connections. For example, you can provide your own CA certificate:

var client = new faye.Client('https://example.com/', {
  tls: {
    ca: fs.readFileSync('path/to/certificate.pem')
  }
});

For further background information on this issue, please see faye#524 and faye-websocket#129. We would like to thank Tero Marttila and Daniel Morsing for providing invaluable assistance and feedback on this issue.

Faye uses em-http-request and faye-websocket in the Ruby version of its client. Those libraries both use 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 https: or wss: connection made using these libraries is vulnerable to a man-in-the-middle attack, since it does not confirm the identity of the server it is connected to.

The first request a Faye client makes is always sent via normal HTTP, but later messages may be sent via WebSocket. Therefore it is vulnerable to the same problem that these underlying libraries are, and we needed both libraries to support TLS verification before Faye could claim to do the same. Your client would still be insecure if its initial HTTPS request was verified, but later WebSocket connections were not.

This has been a requested feature in EventMachine for many years now; see for example #275, #378, and #814. In June 2020, em-http-request published an advisory related to this problem and fixed it by implementing TLS verification 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. Based on this implementation, we have incorporated similar functionality into faye-websocket.

After implementing verification in v1.1.6, em-http-request has elected to leave the :verify_peer option switched off by default. We have decided to enable this option by default in Faye, but are publishing a minor release with added functionality for configuring it. We are mindful of the fact that this may break existing programs, but we consider it much more important that all clients have TLS verification turned on by default. A client that is not carrying out verification is either:

• talking to the expected server, and will not break under this change
• being attacked, and would benefit from being alerted to this fact
• deliberately talking to a server that would be rejected by verification

The latter case includes situations like talking to a non-public server using a self-signed certificate. We consider this use case to be "working by accident", rather than functionality that was actively supported, and it should be properly and explicitly supported instead.

We are releasing Faye v1.4.0, which enables verification by default and provides a way to opt out of it:

client = Faye::Client.new('https://example.com/', tls: { verify_peer: false })

Unfortunately we can't offer an equivalent of the :root_cert_file option that has been added to faye-websocket, because em-http-request does not support it. If you need to talk to servers whose certificates are not recognised by your default root certificates, then you need to add its certificate (or another one that can verify it) to your system's root set.

The same functionality is now supported in the Node.js version, with a tls option whose values will be passed to the https and tls modules as appropriate when making connections. For example, you can provide your own CA certificate:

var client = new faye.Client('https://example.com/', {
  tls: {
    ca: fs.readFileSync('path/to/certificate.pem')
  }
});

For further background information on this issue, please see faye#524 and faye-websocket#129. We would like to thank Tero Marttila and Daniel Morsing for providing invaluable assistance and feedback on this issue.

Faye uses em-http-request and faye-websocket in the Ruby version of its client. Those libraries both use 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 https: or wss: connection made using these libraries is vulnerable to a man-in-the-middle attack, since it does not confirm the identity of the server it is connected to.

The first request a Faye client makes is always sent via normal HTTP, but later messages may be sent via WebSocket. Therefore it is vulnerable to the same problem that these underlying libraries are, and we needed both libraries to support TLS verification before Faye could claim to do the same. Your client would still be insecure if its initial HTTPS request was verified, but later WebSocket connections were not.

This has been a requested feature in EventMachine for many years now; see for example #275, #378, and #814. In June 2020, em-http-request published an advisory related to this problem and fixed it by implementing TLS verification 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. Based on this implementation, we have incorporated similar functionality into faye-websocket.

After implementing verification in v1.1.6, em-http-request has elected to leave the :verify_peer option switched off by default. We have decided to enable this option by default in Faye, but are publishing a minor release with added functionality for configuring it. We are mindful of the fact that this may break existing programs, but we consider it much more important that all clients have TLS verification turned on by default. A client that is not carrying out verification is either:

• talking to the expected server, and will not break under this change
• being attacked, and would benefit from being alerted to this fact
• deliberately talking to a server that would be rejected by verification

The latter case includes situations like talking to a non-public server using a self-signed certificate. We consider this use case to be "working by accident", rather than functionality that was actively supported, and it should be properly and explicitly supported instead.

We are releasing Faye v1.4.0, which enables verification by default and provides a way to opt out of it:

client = Faye::Client.new('https://example.com/', tls: { verify_peer: false })

Unfortunately we can't offer an equivalent of the :root_cert_file option that has been added to faye-websocket, because em-http-request does not support it. If you need to talk to servers whose certificates are not recognised by your default root certificates, then you need to add its certificate (or another one that can verify it) to your system's root set.

The same functionality is now supported in the Node.js version, with a tls option whose values will be passed to the https and tls modules as appropriate when making connections. For example, you can provide your own CA certificate:

var client = new faye.Client('https://example.com/', {
  tls: {
    ca: fs.readFileSync('path/to/certificate.pem')
  }
});

For further background information on this issue, please see faye#524 and faye-websocket#129. We would like to thank Tero Marttila and Daniel Morsing for providing invaluable assistance and feedback on this issue.

Faye uses em-http-request and faye-websocket in the Ruby version of its client. Those libraries both use 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 https: or wss: connection made using these libraries is vulnerable to a man-in-the-middle attack, since it does not confirm the identity of the server it is connected to.

The first request a Faye client makes is always sent via normal HTTP, but later messages may be sent via WebSocket. Therefore it is vulnerable to the same problem that these underlying libraries are, and we needed both libraries to support TLS verification before Faye could claim to do the same. Your client would still be insecure if its initial HTTPS request was verified, but later WebSocket connections were not.

This has been a requested feature in EventMachine for many years now; see for example #275, #378, and #814. In June 2020, em-http-request published an advisory related to this problem and fixed it by implementing TLS verification 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. Based on this implementation, we have incorporated similar functionality into faye-websocket.

After implementing verification in v1.1.6, em-http-request has elected to leave the :verify_peer option switched off by default. We have decided to enable this option by default in Faye, but are publishing a minor release with added functionality for configuring it. We are mindful of the fact that this may break existing programs, but we consider it much more important that all clients have TLS verification turned on by default. A client that is not carrying out verification is either:

• talking to the expected server, and will not break under this change
• being attacked, and would benefit from being alerted to this fact
• deliberately talking to a server that would be rejected by verification

The latter case includes situations like talking to a non-public server using a self-signed certificate. We consider this use case to be "working by accident", rather than functionality that was actively supported, and it should be properly and explicitly supported instead.

We are releasing Faye v1.4.0, which enables verification by default and provides a way to opt out of it:

client = Faye::Client.new('https://example.com/', tls: { verify_peer: false })

Unfortunately we can't offer an equivalent of the :root_cert_file option that has been added to faye-websocket, because em-http-request does not support it. If you need to talk to servers whose certificates are not recognised by your default root certificates, then you need to add its certificate (or another one that can verify it) to your system's root set.

The same functionality is now supported in the Node.js version, with a tls option whose values will be passed to the https and tls modules as appropriate when making connections. For example, you can provide your own CA certificate:

var client = new faye.Client('https://example.com/', {
  tls: {
    ca: fs.readFileSync('path/to/certificate.pem')
  }
});

For further background information on this issue, please see faye#524 and faye-websocket#129. We would like to thank Tero Marttila and Daniel Morsing for providing invaluable assistance and feedback on this issue.

On 20 April 2020 it was reported to me that the potential for authentication bypass exists in Faye's extension system. This vulnerability has existed in the Node.js and Ruby versions of the server since version 0.5.0, when extensions were first introduced, in July 2010. It is patched in versions 1.0.4, 1.1.3 and 1.2.5, which we are releasing today.

The vulnerability allows any client to bypass checks put in place by server-side extensions, by appending extra segments to the message channel. For example, the Faye extension docs suggest that users implement access control for subscriptions by checking incoming messages for the /meta/subscribe channel, for example:

server.addExtension({
  incoming: function(message, callback) {
    if (message.channel === '/meta/subscribe') {
      if (message.ext.authToken !== 'my super secret password') {
        message.error = 'Invalid auth token';
      }
    }
    callback(message);
  }
});

A bug in the server's code for recognising the special /meta/* channels, which trigger connection and subscription events, means that a client can bypass this check by sending a message to /meta/subscribe/x rather than /meta/subscribe:

{
  "channel": "/meta/subscribe/x",
  "clientId": "3jrc6602npj4gyp6bn5ap2wqzjtb2q3",
  "subscription": "/foo"
}

This message will not be checked by the above extension, as it checks the message's channel is exactly equal to /meta/subscribe. But it will still be processed as a subscription request by the server, so the client becomes subscribed to the channel /foo without supplying the necessary credentials.

The vulnerability is caused by the way the Faye server recognises meta channels. It will treat a message to any channel that's a prefix-match for one of the special channels /meta/handshake, /meta/connect, /meta/subscribe, /meta/unsubscribe or /meta/disconnect, as though it were an exact match for that channel. So, a message to /meta/subscribe/x is still processed as a subscription request, for example.

An authentication bypass for subscription requests is the most serious effect of this but all other meta channels are susceptible to similar manipulation.

This parsing bug in the server is fixed in versions 1.0.4, 1.1.3 and 1.2.5. These should be drop-in replacements for prior versions and you should upgrade immediately if you are running any prior version.

If you are unable to install one of these versions, you can make your extensions catch all messages the server would process by checking the channel begins with the expected channel name, for example:

server.addExtension({
  incoming: function(message, callback) {
    if (message.channel.startsWith('/meta/subscribe')) {
      // authentication logic
    }
    callback(message);
  }
});

Faye uses em-http-request and faye-websocket in the Ruby version of its client. Those libraries both use 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 https: or wss: connection made using these libraries is vulnerable to a man-in-the-middle attack, since it does not confirm the identity of the server it is connected to.

The first request a Faye client makes is always sent via normal HTTP, but later messages may be sent via WebSocket. Therefore it is vulnerable to the same problem that these underlying libraries are, and we needed both libraries to support TLS verification before Faye could claim to do the same. Your client would still be insecure if its initial HTTPS request was verified, but later WebSocket connections were not.

This has been a requested feature in EventMachine for many years now; see for example #275, #378, and #814. In June 2020, em-http-request published an advisory related to this problem and fixed it by implementing TLS verification 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. Based on this implementation, we have incorporated similar functionality into faye-websocket.

After implementing verification in v1.1.6, em-http-request has elected to leave the :verify_peer option switched off by default. We have decided to enable this option by default in Faye, but are publishing a minor release with added functionality for configuring it. We are mindful of the fact that this may break existing programs, but we consider it much more important that all clients have TLS verification turned on by default. A client that is not carrying out verification is either:

• talking to the expected server, and will not break under this change
• being attacked, and would benefit from being alerted to this fact
• deliberately talking to a server that would be rejected by verification

The latter case includes situations like talking to a non-public server using a self-signed certificate. We consider this use case to be "working by accident", rather than functionality that was actively supported, and it should be properly and explicitly supported instead.

We are releasing Faye v1.4.0, which enables verification by default and provides a way to opt out of it:

client = Faye::Client.new('https://example.com/', tls: { verify_peer: false })

Unfortunately we can't offer an equivalent of the :root_cert_file option that has been added to faye-websocket, because em-http-request does not support it. If you need to talk to servers whose certificates are not recognised by your default root certificates, then you need to add its certificate (or another one that can verify it) to your system's root set.

The same functionality is now supported in the Node.js version, with a tls option whose values will be passed to the https and tls modules as appropriate when making connections. For example, you can provide your own CA certificate:

var client = new faye.Client('https://example.com/', {
  tls: {
    ca: fs.readFileSync('path/to/certificate.pem')
  }
});

For further background information on this issue, please see faye#524 and faye-websocket#129. We would like to thank Tero Marttila and Daniel Morsing for providing invaluable assistance and feedback on this issue.

On 20 April 2020 it was reported to me that the potential for authentication bypass exists in Faye's extension system. This vulnerability has existed in the Node.js and Ruby versions of the server since version 0.5.0, when extensions were first introduced, in July 2010. It is patched in versions 1.0.4, 1.1.3 and 1.2.5, which we are releasing today.

The vulnerability allows any client to bypass checks put in place by server-side extensions, by appending extra segments to the message channel. For example, the Faye extension docs suggest that users implement access control for subscriptions by checking incoming messages for the /meta/subscribe channel, for example:

server.addExtension({
  incoming: function(message, callback) {
    if (message.channel === '/meta/subscribe') {
      if (message.ext.authToken !== 'my super secret password') {
        message.error = 'Invalid auth token';
      }
    }
    callback(message);
  }
});

A bug in the server's code for recognising the special /meta/* channels, which trigger connection and subscription events, means that a client can bypass this check by sending a message to /meta/subscribe/x rather than /meta/subscribe:

{
  "channel": "/meta/subscribe/x",
  "clientId": "3jrc6602npj4gyp6bn5ap2wqzjtb2q3",
  "subscription": "/foo"
}

This message will not be checked by the above extension, as it checks the message's channel is exactly equal to /meta/subscribe. But it will still be processed as a subscription request by the server, so the client becomes subscribed to the channel /foo without supplying the necessary credentials.

The vulnerability is caused by the way the Faye server recognises meta channels. It will treat a message to any channel that's a prefix-match for one of the special channels /meta/handshake, /meta/connect, /meta/subscribe, /meta/unsubscribe or /meta/disconnect, as though it were an exact match for that channel. So, a message to /meta/subscribe/x is still processed as a subscription request, for example.

An authentication bypass for subscription requests is the most serious effect of this but all other meta channels are susceptible to similar manipulation.

This parsing bug in the server is fixed in versions 1.0.4, 1.1.3 and 1.2.5. These should be drop-in replacements for prior versions and you should upgrade immediately if you are running any prior version.

If you are unable to install one of these versions, you can make your extensions catch all messages the server would process by checking the channel begins with the expected channel name, for example:

server.addExtension({
  incoming: function(message, callback) {
    if (message.channel.startsWith('/meta/subscribe')) {
      // authentication logic
    }
    callback(message);
  }
});

Faye uses em-http-request and faye-websocket in the Ruby version of its client. Those libraries both use 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 https: or wss: connection made using these libraries is vulnerable to a man-in-the-middle attack, since it does not confirm the identity of the server it is connected to.

The first request a Faye client makes is always sent via normal HTTP, but later messages may be sent via WebSocket. Therefore it is vulnerable to the same problem that these underlying libraries are, and we needed both libraries to support TLS verification before Faye could claim to do the same. Your client would still be insecure if its initial HTTPS request was verified, but later WebSocket connections were not.

This has been a requested feature in EventMachine for many years now; see for example #275, #378, and #814. In June 2020, em-http-request published an advisory related to this problem and fixed it by implementing TLS verification 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. Based on this implementation, we have incorporated similar functionality into faye-websocket.

After implementing verification in v1.1.6, em-http-request has elected to leave the :verify_peer option switched off by default. We have decided to enable this option by default in Faye, but are publishing a minor release with added functionality for configuring it. We are mindful of the fact that this may break existing programs, but we consider it much more important that all clients have TLS verification turned on by default. A client that is not carrying out verification is either:

• talking to the expected server, and will not break under this change
• being attacked, and would benefit from being alerted to this fact
• deliberately talking to a server that would be rejected by verification

The latter case includes situations like talking to a non-public server using a self-signed certificate. We consider this use case to be "working by accident", rather than functionality that was actively supported, and it should be properly and explicitly supported instead.

We are releasing Faye v1.4.0, which enables verification by default and provides a way to opt out of it:

client = Faye::Client.new('https://example.com/', tls: { verify_peer: false })

Unfortunately we can't offer an equivalent of the :root_cert_file option that has been added to faye-websocket, because em-http-request does not support it. If you need to talk to servers whose certificates are not recognised by your default root certificates, then you need to add its certificate (or another one that can verify it) to your system's root set.

The same functionality is now supported in the Node.js version, with a tls option whose values will be passed to the https and tls modules as appropriate when making connections. For example, you can provide your own CA certificate:

var client = new faye.Client('https://example.com/', {
  tls: {
    ca: fs.readFileSync('path/to/certificate.pem')
  }
});

For further background information on this issue, please see faye#524 and faye-websocket#129. We would like to thank Tero Marttila and Daniel Morsing for providing invaluable assistance and feedback on this issue.

On 20 April 2020 it was reported to me that the potential for authentication bypass exists in Faye's extension system. This vulnerability has existed in the Node.js and Ruby versions of the server since version 0.5.0, when extensions were first introduced, in July 2010. It is patched in versions 1.0.4, 1.1.3 and 1.2.5, which we are releasing today.

The vulnerability allows any client to bypass checks put in place by server-side extensions, by appending extra segments to the message channel. For example, the Faye extension docs suggest that users implement access control for subscriptions by checking incoming messages for the /meta/subscribe channel, for example:

server.addExtension({
  incoming: function(message, callback) {
    if (message.channel === '/meta/subscribe') {
      if (message.ext.authToken !== 'my super secret password') {
        message.error = 'Invalid auth token';
      }
    }
    callback(message);
  }
});

A bug in the server's code for recognising the special /meta/* channels, which trigger connection and subscription events, means that a client can bypass this check by sending a message to /meta/subscribe/x rather than /meta/subscribe:

{
  "channel": "/meta/subscribe/x",
  "clientId": "3jrc6602npj4gyp6bn5ap2wqzjtb2q3",
  "subscription": "/foo"
}

This message will not be checked by the above extension, as it checks the message's channel is exactly equal to /meta/subscribe. But it will still be processed as a subscription request by the server, so the client becomes subscribed to the channel /foo without supplying the necessary credentials.

The vulnerability is caused by the way the Faye server recognises meta channels. It will treat a message to any channel that's a prefix-match for one of the special channels /meta/handshake, /meta/connect, /meta/subscribe, /meta/unsubscribe or /meta/disconnect, as though it were an exact match for that channel. So, a message to /meta/subscribe/x is still processed as a subscription request, for example.

An authentication bypass for subscription requests is the most serious effect of this but all other meta channels are susceptible to similar manipulation.

This parsing bug in the server is fixed in versions 1.0.4, 1.1.3 and 1.2.5. These should be drop-in replacements for prior versions and you should upgrade immediately if you are running any prior version.

If you are unable to install one of these versions, you can make your extensions catch all messages the server would process by checking the channel begins with the expected channel name, for example:

server.addExtension({
  incoming: function(message, callback) {
    if (message.channel.startsWith('/meta/subscribe')) {
      // authentication logic
    }
    callback(message);
  }
});

Faye uses em-http-request and faye-websocket in the Ruby version of its client. Those libraries both use 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 https: or wss: connection made using these libraries is vulnerable to a man-in-the-middle attack, since it does not confirm the identity of the server it is connected to.

The first request a Faye client makes is always sent via normal HTTP, but later messages may be sent via WebSocket. Therefore it is vulnerable to the same problem that these underlying libraries are, and we needed both libraries to support TLS verification before Faye could claim to do the same. Your client would still be insecure if its initial HTTPS request was verified, but later WebSocket connections were not.

This has been a requested feature in EventMachine for many years now; see for example #275, #378, and #814. In June 2020, em-http-request published an advisory related to this problem and fixed it by implementing TLS verification 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. Based on this implementation, we have incorporated similar functionality into faye-websocket.

After implementing verification in v1.1.6, em-http-request has elected to leave the :verify_peer option switched off by default. We have decided to enable this option by default in Faye, but are publishing a minor release with added functionality for configuring it. We are mindful of the fact that this may break existing programs, but we consider it much more important that all clients have TLS verification turned on by default. A client that is not carrying out verification is either:

• talking to the expected server, and will not break under this change
• being attacked, and would benefit from being alerted to this fact
• deliberately talking to a server that would be rejected by verification

The latter case includes situations like talking to a non-public server using a self-signed certificate. We consider this use case to be "working by accident", rather than functionality that was actively supported, and it should be properly and explicitly supported instead.

We are releasing Faye v1.4.0, which enables verification by default and provides a way to opt out of it:

client = Faye::Client.new('https://example.com/', tls: { verify_peer: false })

Unfortunately we can't offer an equivalent of the :root_cert_file option that has been added to faye-websocket, because em-http-request does not support it. If you need to talk to servers whose certificates are not recognised by your default root certificates, then you need to add its certificate (or another one that can verify it) to your system's root set.

The same functionality is now supported in the Node.js version, with a tls option whose values will be passed to the https and tls modules as appropriate when making connections. For example, you can provide your own CA certificate:

var client = new faye.Client('https://example.com/', {
  tls: {
    ca: fs.readFileSync('path/to/certificate.pem')
  }
});

For further background information on this issue, please see faye#524 and faye-websocket#129. We would like to thank Tero Marttila and Daniel Morsing for providing invaluable assistance and feedback on this issue.

On 20 April 2020 it was reported to me that the potential for authentication bypass exists in Faye's extension system. This vulnerability has existed in the Node.js and Ruby versions of the server since version 0.5.0, when extensions were first introduced, in July 2010. It is patched in versions 1.0.4, 1.1.3 and 1.2.5, which we are releasing today.

The vulnerability allows any client to bypass checks put in place by server-side extensions, by appending extra segments to the message channel. For example, the Faye extension docs suggest that users implement access control for subscriptions by checking incoming messages for the /meta/subscribe channel, for example:

server.addExtension({
  incoming: function(message, callback) {
    if (message.channel === '/meta/subscribe') {
      if (message.ext.authToken !== 'my super secret password') {
        message.error = 'Invalid auth token';
      }
    }
    callback(message);
  }
});

A bug in the server's code for recognising the special /meta/* channels, which trigger connection and subscription events, means that a client can bypass this check by sending a message to /meta/subscribe/x rather than /meta/subscribe:

{
  "channel": "/meta/subscribe/x",
  "clientId": "3jrc6602npj4gyp6bn5ap2wqzjtb2q3",
  "subscription": "/foo"
}

This message will not be checked by the above extension, as it checks the message's channel is exactly equal to /meta/subscribe. But it will still be processed as a subscription request by the server, so the client becomes subscribed to the channel /foo without supplying the necessary credentials.

The vulnerability is caused by the way the Faye server recognises meta channels. It will treat a message to any channel that's a prefix-match for one of the special channels /meta/handshake, /meta/connect, /meta/subscribe, /meta/unsubscribe or /meta/disconnect, as though it were an exact match for that channel. So, a message to /meta/subscribe/x is still processed as a subscription request, for example.

An authentication bypass for subscription requests is the most serious effect of this but all other meta channels are susceptible to similar manipulation.

This parsing bug in the server is fixed in versions 1.0.4, 1.1.3 and 1.2.5. These should be drop-in replacements for prior versions and you should upgrade immediately if you are running any prior version.

If you are unable to install one of these versions, you can make your extensions catch all messages the server would process by checking the channel begins with the expected channel name, for example:

server.addExtension({
  incoming: function(message, callback) {
    if (message.channel.startsWith('/meta/subscribe')) {
      // authentication logic
    }
    callback(message);
  }
});

Faye uses em-http-request and faye-websocket in the Ruby version of its client. Those libraries both use 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 https: or wss: connection made using these libraries is vulnerable to a man-in-the-middle attack, since it does not confirm the identity of the server it is connected to.

The first request a Faye client makes is always sent via normal HTTP, but later messages may be sent via WebSocket. Therefore it is vulnerable to the same problem that these underlying libraries are, and we needed both libraries to support TLS verification before Faye could claim to do the same. Your client would still be insecure if its initial HTTPS request was verified, but later WebSocket connections were not.

This has been a requested feature in EventMachine for many years now; see for example #275, #378, and #814. In June 2020, em-http-request published an advisory related to this problem and fixed it by implementing TLS verification 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. Based on this implementation, we have incorporated similar functionality into faye-websocket.

After implementing verification in v1.1.6, em-http-request has elected to leave the :verify_peer option switched off by default. We have decided to enable this option by default in Faye, but are publishing a minor release with added functionality for configuring it. We are mindful of the fact that this may break existing programs, but we consider it much more important that all clients have TLS verification turned on by default. A client that is not carrying out verification is either:

• talking to the expected server, and will not break under this change
• being attacked, and would benefit from being alerted to this fact
• deliberately talking to a server that would be rejected by verification

The latter case includes situations like talking to a non-public server using a self-signed certificate. We consider this use case to be "working by accident", rather than functionality that was actively supported, and it should be properly and explicitly supported instead.

We are releasing Faye v1.4.0, which enables verification by default and provides a way to opt out of it:

client = Faye::Client.new('https://example.com/', tls: { verify_peer: false })

Unfortunately we can't offer an equivalent of the :root_cert_file option that has been added to faye-websocket, because em-http-request does not support it. If you need to talk to servers whose certificates are not recognised by your default root certificates, then you need to add its certificate (or another one that can verify it) to your system's root set.

The same functionality is now supported in the Node.js version, with a tls option whose values will be passed to the https and tls modules as appropriate when making connections. For example, you can provide your own CA certificate:

var client = new faye.Client('https://example.com/', {
  tls: {
    ca: fs.readFileSync('path/to/certificate.pem')
  }
});

For further background information on this issue, please see faye#524 and faye-websocket#129. We would like to thank Tero Marttila and Daniel Morsing for providing invaluable assistance and feedback on this issue.

On 20 April 2020 it was reported to me that the potential for authentication bypass exists in Faye's extension system. This vulnerability has existed in the Node.js and Ruby versions of the server since version 0.5.0, when extensions were first introduced, in July 2010. It is patched in versions 1.0.4, 1.1.3 and 1.2.5, which we are releasing today.

The vulnerability allows any client to bypass checks put in place by server-side extensions, by appending extra segments to the message channel. For example, the Faye extension docs suggest that users implement access control for subscriptions by checking incoming messages for the /meta/subscribe channel, for example:

server.addExtension({
  incoming: function(message, callback) {
    if (message.channel === '/meta/subscribe') {
      if (message.ext.authToken !== 'my super secret password') {
        message.error = 'Invalid auth token';
      }
    }
    callback(message);
  }
});

A bug in the server's code for recognising the special /meta/* channels, which trigger connection and subscription events, means that a client can bypass this check by sending a message to /meta/subscribe/x rather than /meta/subscribe:

{
  "channel": "/meta/subscribe/x",
  "clientId": "3jrc6602npj4gyp6bn5ap2wqzjtb2q3",
  "subscription": "/foo"
}

This message will not be checked by the above extension, as it checks the message's channel is exactly equal to /meta/subscribe. But it will still be processed as a subscription request by the server, so the client becomes subscribed to the channel /foo without supplying the necessary credentials.

The vulnerability is caused by the way the Faye server recognises meta channels. It will treat a message to any channel that's a prefix-match for one of the special channels /meta/handshake, /meta/connect, /meta/subscribe, /meta/unsubscribe or /meta/disconnect, as though it were an exact match for that channel. So, a message to /meta/subscribe/x is still processed as a subscription request, for example.

An authentication bypass for subscription requests is the most serious effect of this but all other meta channels are susceptible to similar manipulation.

This parsing bug in the server is fixed in versions 1.0.4, 1.1.3 and 1.2.5. These should be drop-in replacements for prior versions and you should upgrade immediately if you are running any prior version.

If you are unable to install one of these versions, you can make your extensions catch all messages the server would process by checking the channel begins with the expected channel name, for example:

server.addExtension({
  incoming: function(message, callback) {
    if (message.channel.startsWith('/meta/subscribe')) {
      // authentication logic
    }
    callback(message);
  }
});

Faye uses em-http-request and faye-websocket in the Ruby version of its client. Those libraries both use 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 https: or wss: connection made using these libraries is vulnerable to a man-in-the-middle attack, since it does not confirm the identity of the server it is connected to.

The first request a Faye client makes is always sent via normal HTTP, but later messages may be sent via WebSocket. Therefore it is vulnerable to the same problem that these underlying libraries are, and we needed both libraries to support TLS verification before Faye could claim to do the same. Your client would still be insecure if its initial HTTPS request was verified, but later WebSocket connections were not.

This has been a requested feature in EventMachine for many years now; see for example #275, #378, and #814. In June 2020, em-http-request published an advisory related to this problem and fixed it by implementing TLS verification 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. Based on this implementation, we have incorporated similar functionality into faye-websocket.

After implementing verification in v1.1.6, em-http-request has elected to leave the :verify_peer option switched off by default. We have decided to enable this option by default in Faye, but are publishing a minor release with added functionality for configuring it. We are mindful of the fact that this may break existing programs, but we consider it much more important that all clients have TLS verification turned on by default. A client that is not carrying out verification is either:

• talking to the expected server, and will not break under this change
• being attacked, and would benefit from being alerted to this fact
• deliberately talking to a server that would be rejected by verification

The latter case includes situations like talking to a non-public server using a self-signed certificate. We consider this use case to be "working by accident", rather than functionality that was actively supported, and it should be properly and explicitly supported instead.

We are releasing Faye v1.4.0, which enables verification by default and provides a way to opt out of it:

client = Faye::Client.new('https://example.com/', tls: { verify_peer: false })

Unfortunately we can't offer an equivalent of the :root_cert_file option that has been added to faye-websocket, because em-http-request does not support it. If you need to talk to servers whose certificates are not recognised by your default root certificates, then you need to add its certificate (or another one that can verify it) to your system's root set.

The same functionality is now supported in the Node.js version, with a tls option whose values will be passed to the https and tls modules as appropriate when making connections. For example, you can provide your own CA certificate:

var client = new faye.Client('https://example.com/', {
  tls: {
    ca: fs.readFileSync('path/to/certificate.pem')
  }
});

For further background information on this issue, please see faye#524 and faye-websocket#129. We would like to thank Tero Marttila and Daniel Morsing for providing invaluable assistance and feedback on this issue.

On 20 April 2020 it was reported to me that the potential for authentication bypass exists in Faye's extension system. This vulnerability has existed in the Node.js and Ruby versions of the server since version 0.5.0, when extensions were first introduced, in July 2010. It is patched in versions 1.0.4, 1.1.3 and 1.2.5, which we are releasing today.

The vulnerability allows any client to bypass checks put in place by server-side extensions, by appending extra segments to the message channel. For example, the Faye extension docs suggest that users implement access control for subscriptions by checking incoming messages for the /meta/subscribe channel, for example:

server.addExtension({
  incoming: function(message, callback) {
    if (message.channel === '/meta/subscribe') {
      if (message.ext.authToken !== 'my super secret password') {
        message.error = 'Invalid auth token';
      }
    }
    callback(message);
  }
});

A bug in the server's code for recognising the special /meta/* channels, which trigger connection and subscription events, means that a client can bypass this check by sending a message to /meta/subscribe/x rather than /meta/subscribe:

{
  "channel": "/meta/subscribe/x",
  "clientId": "3jrc6602npj4gyp6bn5ap2wqzjtb2q3",
  "subscription": "/foo"
}

This message will not be checked by the above extension, as it checks the message's channel is exactly equal to /meta/subscribe. But it will still be processed as a subscription request by the server, so the client becomes subscribed to the channel /foo without supplying the necessary credentials.

The vulnerability is caused by the way the Faye server recognises meta channels. It will treat a message to any channel that's a prefix-match for one of the special channels /meta/handshake, /meta/connect, /meta/subscribe, /meta/unsubscribe or /meta/disconnect, as though it were an exact match for that channel. So, a message to /meta/subscribe/x is still processed as a subscription request, for example.

An authentication bypass for subscription requests is the most serious effect of this but all other meta channels are susceptible to similar manipulation.

This parsing bug in the server is fixed in versions 1.0.4, 1.1.3 and 1.2.5. These should be drop-in replacements for prior versions and you should upgrade immediately if you are running any prior version.

If you are unable to install one of these versions, you can make your extensions catch all messages the server would process by checking the channel begins with the expected channel name, for example:

server.addExtension({
  incoming: function(message, callback) {
    if (message.channel.startsWith('/meta/subscribe')) {
      // authentication logic
    }
    callback(message);
  }
});

Faye uses em-http-request and faye-websocket in the Ruby version of its client. Those libraries both use 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 https: or wss: connection made using these libraries is vulnerable to a man-in-the-middle attack, since it does not confirm the identity of the server it is connected to.

The first request a Faye client makes is always sent via normal HTTP, but later messages may be sent via WebSocket. Therefore it is vulnerable to the same problem that these underlying libraries are, and we needed both libraries to support TLS verification before Faye could claim to do the same. Your client would still be insecure if its initial HTTPS request was verified, but later WebSocket connections were not.

This has been a requested feature in EventMachine for many years now; see for example #275, #378, and #814. In June 2020, em-http-request published an advisory related to this problem and fixed it by implementing TLS verification 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. Based on this implementation, we have incorporated similar functionality into faye-websocket.

After implementing verification in v1.1.6, em-http-request has elected to leave the :verify_peer option switched off by default. We have decided to enable this option by default in Faye, but are publishing a minor release with added functionality for configuring it. We are mindful of the fact that this may break existing programs, but we consider it much more important that all clients have TLS verification turned on by default. A client that is not carrying out verification is either:

• talking to the expected server, and will not break under this change
• being attacked, and would benefit from being alerted to this fact
• deliberately talking to a server that would be rejected by verification

The latter case includes situations like talking to a non-public server using a self-signed certificate. We consider this use case to be "working by accident", rather than functionality that was actively supported, and it should be properly and explicitly supported instead.

We are releasing Faye v1.4.0, which enables verification by default and provides a way to opt out of it:

client = Faye::Client.new('https://example.com/', tls: { verify_peer: false })

Unfortunately we can't offer an equivalent of the :root_cert_file option that has been added to faye-websocket, because em-http-request does not support it. If you need to talk to servers whose certificates are not recognised by your default root certificates, then you need to add its certificate (or another one that can verify it) to your system's root set.

The same functionality is now supported in the Node.js version, with a tls option whose values will be passed to the https and tls modules as appropriate when making connections. For example, you can provide your own CA certificate:

var client = new faye.Client('https://example.com/', {
  tls: {
    ca: fs.readFileSync('path/to/certificate.pem')
  }
});

For further background information on this issue, please see faye#524 and faye-websocket#129. We would like to thank Tero Marttila and Daniel Morsing for providing invaluable assistance and feedback on this issue.

On 20 April 2020 it was reported to me that the potential for authentication bypass exists in Faye's extension system. This vulnerability has existed in the Node.js and Ruby versions of the server since version 0.5.0, when extensions were first introduced, in July 2010. It is patched in versions 1.0.4, 1.1.3 and 1.2.5, which we are releasing today.

The vulnerability allows any client to bypass checks put in place by server-side extensions, by appending extra segments to the message channel. For example, the Faye extension docs suggest that users implement access control for subscriptions by checking incoming messages for the /meta/subscribe channel, for example:

server.addExtension({
  incoming: function(message, callback) {
    if (message.channel === '/meta/subscribe') {
      if (message.ext.authToken !== 'my super secret password') {
        message.error = 'Invalid auth token';
      }
    }
    callback(message);
  }
});

A bug in the server's code for recognising the special /meta/* channels, which trigger connection and subscription events, means that a client can bypass this check by sending a message to /meta/subscribe/x rather than /meta/subscribe:

{
  "channel": "/meta/subscribe/x",
  "clientId": "3jrc6602npj4gyp6bn5ap2wqzjtb2q3",
  "subscription": "/foo"
}

This message will not be checked by the above extension, as it checks the message's channel is exactly equal to /meta/subscribe. But it will still be processed as a subscription request by the server, so the client becomes subscribed to the channel /foo without supplying the necessary credentials.

The vulnerability is caused by the way the Faye server recognises meta channels. It will treat a message to any channel that's a prefix-match for one of the special channels /meta/handshake, /meta/connect, /meta/subscribe, /meta/unsubscribe or /meta/disconnect, as though it were an exact match for that channel. So, a message to /meta/subscribe/x is still processed as a subscription request, for example.

An authentication bypass for subscription requests is the most serious effect of this but all other meta channels are susceptible to similar manipulation.

This parsing bug in the server is fixed in versions 1.0.4, 1.1.3 and 1.2.5. These should be drop-in replacements for prior versions and you should upgrade immediately if you are running any prior version.

If you are unable to install one of these versions, you can make your extensions catch all messages the server would process by checking the channel begins with the expected channel name, for example:

server.addExtension({
  incoming: function(message, callback) {
    if (message.channel.startsWith('/meta/subscribe')) {
      // authentication logic
    }
    callback(message);
  }
});

Faye uses em-http-request and faye-websocket in the Ruby version of its client. Those libraries both use 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 https: or wss: connection made using these libraries is vulnerable to a man-in-the-middle attack, since it does not confirm the identity of the server it is connected to.

The first request a Faye client makes is always sent via normal HTTP, but later messages may be sent via WebSocket. Therefore it is vulnerable to the same problem that these underlying libraries are, and we needed both libraries to support TLS verification before Faye could claim to do the same. Your client would still be insecure if its initial HTTPS request was verified, but later WebSocket connections were not.

This has been a requested feature in EventMachine for many years now; see for example #275, #378, and #814. In June 2020, em-http-request published an advisory related to this problem and fixed it by implementing TLS verification 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. Based on this implementation, we have incorporated similar functionality into faye-websocket.

After implementing verification in v1.1.6, em-http-request has elected to leave the :verify_peer option switched off by default. We have decided to enable this option by default in Faye, but are publishing a minor release with added functionality for configuring it. We are mindful of the fact that this may break existing programs, but we consider it much more important that all clients have TLS verification turned on by default. A client that is not carrying out verification is either:

• talking to the expected server, and will not break under this change
• being attacked, and would benefit from being alerted to this fact
• deliberately talking to a server that would be rejected by verification

The latter case includes situations like talking to a non-public server using a self-signed certificate. We consider this use case to be "working by accident", rather than functionality that was actively supported, and it should be properly and explicitly supported instead.

We are releasing Faye v1.4.0, which enables verification by default and provides a way to opt out of it:

client = Faye::Client.new('https://example.com/', tls: { verify_peer: false })

Unfortunately we can't offer an equivalent of the :root_cert_file option that has been added to faye-websocket, because em-http-request does not support it. If you need to talk to servers whose certificates are not recognised by your default root certificates, then you need to add its certificate (or another one that can verify it) to your system's root set.

The same functionality is now supported in the Node.js version, with a tls option whose values will be passed to the https and tls modules as appropriate when making connections. For example, you can provide your own CA certificate:

var client = new faye.Client('https://example.com/', {
  tls: {
    ca: fs.readFileSync('path/to/certificate.pem')
  }
});

For further background information on this issue, please see faye#524 and faye-websocket#129. We would like to thank Tero Marttila and Daniel Morsing for providing invaluable assistance and feedback on this issue.

On 20 April 2020 it was reported to me that the potential for authentication bypass exists in Faye's extension system. This vulnerability has existed in the Node.js and Ruby versions of the server since version 0.5.0, when extensions were first introduced, in July 2010. It is patched in versions 1.0.4, 1.1.3 and 1.2.5, which we are releasing today.

The vulnerability allows any client to bypass checks put in place by server-side extensions, by appending extra segments to the message channel. For example, the Faye extension docs suggest that users implement access control for subscriptions by checking incoming messages for the /meta/subscribe channel, for example:

server.addExtension({
  incoming: function(message, callback) {
    if (message.channel === '/meta/subscribe') {
      if (message.ext.authToken !== 'my super secret password') {
        message.error = 'Invalid auth token';
      }
    }
    callback(message);
  }
});

A bug in the server's code for recognising the special /meta/* channels, which trigger connection and subscription events, means that a client can bypass this check by sending a message to /meta/subscribe/x rather than /meta/subscribe:

{
  "channel": "/meta/subscribe/x",
  "clientId": "3jrc6602npj4gyp6bn5ap2wqzjtb2q3",
  "subscription": "/foo"
}

This message will not be checked by the above extension, as it checks the message's channel is exactly equal to /meta/subscribe. But it will still be processed as a subscription request by the server, so the client becomes subscribed to the channel /foo without supplying the necessary credentials.

The vulnerability is caused by the way the Faye server recognises meta channels. It will treat a message to any channel that's a prefix-match for one of the special channels /meta/handshake, /meta/connect, /meta/subscribe, /meta/unsubscribe or /meta/disconnect, as though it were an exact match for that channel. So, a message to /meta/subscribe/x is still processed as a subscription request, for example.

An authentication bypass for subscription requests is the most serious effect of this but all other meta channels are susceptible to similar manipulation.

This parsing bug in the server is fixed in versions 1.0.4, 1.1.3 and 1.2.5. These should be drop-in replacements for prior versions and you should upgrade immediately if you are running any prior version.

If you are unable to install one of these versions, you can make your extensions catch all messages the server would process by checking the channel begins with the expected channel name, for example:

server.addExtension({
  incoming: function(message, callback) {
    if (message.channel.startsWith('/meta/subscribe')) {
      // authentication logic
    }
    callback(message);
  }
});

Faye uses em-http-request and faye-websocket in the Ruby version of its client. Those libraries both use 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 https: or wss: connection made using these libraries is vulnerable to a man-in-the-middle attack, since it does not confirm the identity of the server it is connected to.

The first request a Faye client makes is always sent via normal HTTP, but later messages may be sent via WebSocket. Therefore it is vulnerable to the same problem that these underlying libraries are, and we needed both libraries to support TLS verification before Faye could claim to do the same. Your client would still be insecure if its initial HTTPS request was verified, but later WebSocket connections were not.

This has been a requested feature in EventMachine for many years now; see for example #275, #378, and #814. In June 2020, em-http-request published an advisory related to this problem and fixed it by implementing TLS verification 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. Based on this implementation, we have incorporated similar functionality into faye-websocket.

After implementing verification in v1.1.6, em-http-request has elected to leave the :verify_peer option switched off by default. We have decided to enable this option by default in Faye, but are publishing a minor release with added functionality for configuring it. We are mindful of the fact that this may break existing programs, but we consider it much more important that all clients have TLS verification turned on by default. A client that is not carrying out verification is either:

• talking to the expected server, and will not break under this change
• being attacked, and would benefit from being alerted to this fact
• deliberately talking to a server that would be rejected by verification

The latter case includes situations like talking to a non-public server using a self-signed certificate. We consider this use case to be "working by accident", rather than functionality that was actively supported, and it should be properly and explicitly supported instead.

We are releasing Faye v1.4.0, which enables verification by default and provides a way to opt out of it:

client = Faye::Client.new('https://example.com/', tls: { verify_peer: false })

Unfortunately we can't offer an equivalent of the :root_cert_file option that has been added to faye-websocket, because em-http-request does not support it. If you need to talk to servers whose certificates are not recognised by your default root certificates, then you need to add its certificate (or another one that can verify it) to your system's root set.

The same functionality is now supported in the Node.js version, with a tls option whose values will be passed to the https and tls modules as appropriate when making connections. For example, you can provide your own CA certificate:

var client = new faye.Client('https://example.com/', {
  tls: {
    ca: fs.readFileSync('path/to/certificate.pem')
  }
});

For further background information on this issue, please see faye#524 and faye-websocket#129. We would like to thank Tero Marttila and Daniel Morsing for providing invaluable assistance and feedback on this issue.

On 20 April 2020 it was reported to me that the potential for authentication bypass exists in Faye's extension system. This vulnerability has existed in the Node.js and Ruby versions of the server since version 0.5.0, when extensions were first introduced, in July 2010. It is patched in versions 1.0.4, 1.1.3 and 1.2.5, which we are releasing today.

The vulnerability allows any client to bypass checks put in place by server-side extensions, by appending extra segments to the message channel. For example, the Faye extension docs suggest that users implement access control for subscriptions by checking incoming messages for the /meta/subscribe channel, for example:

server.addExtension({
  incoming: function(message, callback) {
    if (message.channel === '/meta/subscribe') {
      if (message.ext.authToken !== 'my super secret password') {
        message.error = 'Invalid auth token';
      }
    }
    callback(message);
  }
});

A bug in the server's code for recognising the special /meta/* channels, which trigger connection and subscription events, means that a client can bypass this check by sending a message to /meta/subscribe/x rather than /meta/subscribe:

{
  "channel": "/meta/subscribe/x",
  "clientId": "3jrc6602npj4gyp6bn5ap2wqzjtb2q3",
  "subscription": "/foo"
}

This message will not be checked by the above extension, as it checks the message's channel is exactly equal to /meta/subscribe. But it will still be processed as a subscription request by the server, so the client becomes subscribed to the channel /foo without supplying the necessary credentials.

The vulnerability is caused by the way the Faye server recognises meta channels. It will treat a message to any channel that's a prefix-match for one of the special channels /meta/handshake, /meta/connect, /meta/subscribe, /meta/unsubscribe or /meta/disconnect, as though it were an exact match for that channel. So, a message to /meta/subscribe/x is still processed as a subscription request, for example.

An authentication bypass for subscription requests is the most serious effect of this but all other meta channels are susceptible to similar manipulation.

This parsing bug in the server is fixed in versions 1.0.4, 1.1.3 and 1.2.5. These should be drop-in replacements for prior versions and you should upgrade immediately if you are running any prior version.

If you are unable to install one of these versions, you can make your extensions catch all messages the server would process by checking the channel begins with the expected channel name, for example:

server.addExtension({
  incoming: function(message, callback) {
    if (message.channel.startsWith('/meta/subscribe')) {
      // authentication logic
    }
    callback(message);
  }
});

Faye uses em-http-request and faye-websocket in the Ruby version of its client. Those libraries both use 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 https: or wss: connection made using these libraries is vulnerable to a man-in-the-middle attack, since it does not confirm the identity of the server it is connected to.

The first request a Faye client makes is always sent via normal HTTP, but later messages may be sent via WebSocket. Therefore it is vulnerable to the same problem that these underlying libraries are, and we needed both libraries to support TLS verification before Faye could claim to do the same. Your client would still be insecure if its initial HTTPS request was verified, but later WebSocket connections were not.

This has been a requested feature in EventMachine for many years now; see for example #275, #378, and #814. In June 2020, em-http-request published an advisory related to this problem and fixed it by implementing TLS verification 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. Based on this implementation, we have incorporated similar functionality into faye-websocket.

After implementing verification in v1.1.6, em-http-request has elected to leave the :verify_peer option switched off by default. We have decided to enable this option by default in Faye, but are publishing a minor release with added functionality for configuring it. We are mindful of the fact that this may break existing programs, but we consider it much more important that all clients have TLS verification turned on by default. A client that is not carrying out verification is either:

• talking to the expected server, and will not break under this change
• being attacked, and would benefit from being alerted to this fact
• deliberately talking to a server that would be rejected by verification

The latter case includes situations like talking to a non-public server using a self-signed certificate. We consider this use case to be "working by accident", rather than functionality that was actively supported, and it should be properly and explicitly supported instead.

We are releasing Faye v1.4.0, which enables verification by default and provides a way to opt out of it:

client = Faye::Client.new('https://example.com/', tls: { verify_peer: false })

Unfortunately we can't offer an equivalent of the :root_cert_file option that has been added to faye-websocket, because em-http-request does not support it. If you need to talk to servers whose certificates are not recognised by your default root certificates, then you need to add its certificate (or another one that can verify it) to your system's root set.

The same functionality is now supported in the Node.js version, with a tls option whose values will be passed to the https and tls modules as appropriate when making connections. For example, you can provide your own CA certificate:

var client = new faye.Client('https://example.com/', {
  tls: {
    ca: fs.readFileSync('path/to/certificate.pem')
  }
});

For further background information on this issue, please see faye#524 and faye-websocket#129. We would like to thank Tero Marttila and Daniel Morsing for providing invaluable assistance and feedback on this issue.

On 20 April 2020 it was reported to me that the potential for authentication bypass exists in Faye's extension system. This vulnerability has existed in the Node.js and Ruby versions of the server since version 0.5.0, when extensions were first introduced, in July 2010. It is patched in versions 1.0.4, 1.1.3 and 1.2.5, which we are releasing today.

The vulnerability allows any client to bypass checks put in place by server-side extensions, by appending extra segments to the message channel. For example, the Faye extension docs suggest that users implement access control for subscriptions by checking incoming messages for the /meta/subscribe channel, for example:

server.addExtension({
  incoming: function(message, callback) {
    if (message.channel === '/meta/subscribe') {
      if (message.ext.authToken !== 'my super secret password') {
        message.error = 'Invalid auth token';
      }
    }
    callback(message);
  }
});

A bug in the server's code for recognising the special /meta/* channels, which trigger connection and subscription events, means that a client can bypass this check by sending a message to /meta/subscribe/x rather than /meta/subscribe:

{
  "channel": "/meta/subscribe/x",
  "clientId": "3jrc6602npj4gyp6bn5ap2wqzjtb2q3",
  "subscription": "/foo"
}

This message will not be checked by the above extension, as it checks the message's channel is exactly equal to /meta/subscribe. But it will still be processed as a subscription request by the server, so the client becomes subscribed to the channel /foo without supplying the necessary credentials.

The vulnerability is caused by the way the Faye server recognises meta channels. It will treat a message to any channel that's a prefix-match for one of the special channels /meta/handshake, /meta/connect, /meta/subscribe, /meta/unsubscribe or /meta/disconnect, as though it were an exact match for that channel. So, a message to /meta/subscribe/x is still processed as a subscription request, for example.

An authentication bypass for subscription requests is the most serious effect of this but all other meta channels are susceptible to similar manipulation.

This parsing bug in the server is fixed in versions 1.0.4, 1.1.3 and 1.2.5. These should be drop-in replacements for prior versions and you should upgrade immediately if you are running any prior version.

If you are unable to install one of these versions, you can make your extensions catch all messages the server would process by checking the channel begins with the expected channel name, for example:

server.addExtension({
  incoming: function(message, callback) {
    if (message.channel.startsWith('/meta/subscribe')) {
      // authentication logic
    }
    callback(message);
  }
});

Faye uses em-http-request and faye-websocket in the Ruby version of its client. Those libraries both use 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 https: or wss: connection made using these libraries is vulnerable to a man-in-the-middle attack, since it does not confirm the identity of the server it is connected to.

The first request a Faye client makes is always sent via normal HTTP, but later messages may be sent via WebSocket. Therefore it is vulnerable to the same problem that these underlying libraries are, and we needed both libraries to support TLS verification before Faye could claim to do the same. Your client would still be insecure if its initial HTTPS request was verified, but later WebSocket connections were not.

This has been a requested feature in EventMachine for many years now; see for example #275, #378, and #814. In June 2020, em-http-request published an advisory related to this problem and fixed it by implementing TLS verification 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. Based on this implementation, we have incorporated similar functionality into faye-websocket.

After implementing verification in v1.1.6, em-http-request has elected to leave the :verify_peer option switched off by default. We have decided to enable this option by default in Faye, but are publishing a minor release with added functionality for configuring it. We are mindful of the fact that this may break existing programs, but we consider it much more important that all clients have TLS verification turned on by default. A client that is not carrying out verification is either:

• talking to the expected server, and will not break under this change
• being attacked, and would benefit from being alerted to this fact
• deliberately talking to a server that would be rejected by verification

The latter case includes situations like talking to a non-public server using a self-signed certificate. We consider this use case to be "working by accident", rather than functionality that was actively supported, and it should be properly and explicitly supported instead.

We are releasing Faye v1.4.0, which enables verification by default and provides a way to opt out of it:

client = Faye::Client.new('https://example.com/', tls: { verify_peer: false })

Unfortunately we can't offer an equivalent of the :root_cert_file option that has been added to faye-websocket, because em-http-request does not support it. If you need to talk to servers whose certificates are not recognised by your default root certificates, then you need to add its certificate (or another one that can verify it) to your system's root set.

The same functionality is now supported in the Node.js version, with a tls option whose values will be passed to the https and tls modules as appropriate when making connections. For example, you can provide your own CA certificate:

var client = new faye.Client('https://example.com/', {
  tls: {
    ca: fs.readFileSync('path/to/certificate.pem')
  }
});

For further background information on this issue, please see faye#524 and faye-websocket#129. We would like to thank Tero Marttila and Daniel Morsing for providing invaluable assistance and feedback on this issue.

On 20 April 2020 it was reported to me that the potential for authentication bypass exists in Faye's extension system. This vulnerability has existed in the Node.js and Ruby versions of the server since version 0.5.0, when extensions were first introduced, in July 2010. It is patched in versions 1.0.4, 1.1.3 and 1.2.5, which we are releasing today.

The vulnerability allows any client to bypass checks put in place by server-side extensions, by appending extra segments to the message channel. For example, the Faye extension docs suggest that users implement access control for subscriptions by checking incoming messages for the /meta/subscribe channel, for example:

server.addExtension({
  incoming: function(message, callback) {
    if (message.channel === '/meta/subscribe') {
      if (message.ext.authToken !== 'my super secret password') {
        message.error = 'Invalid auth token';
      }
    }
    callback(message);
  }
});

A bug in the server's code for recognising the special /meta/* channels, which trigger connection and subscription events, means that a client can bypass this check by sending a message to /meta/subscribe/x rather than /meta/subscribe:

{
  "channel": "/meta/subscribe/x",
  "clientId": "3jrc6602npj4gyp6bn5ap2wqzjtb2q3",
  "subscription": "/foo"
}

This message will not be checked by the above extension, as it checks the message's channel is exactly equal to /meta/subscribe. But it will still be processed as a subscription request by the server, so the client becomes subscribed to the channel /foo without supplying the necessary credentials.

The vulnerability is caused by the way the Faye server recognises meta channels. It will treat a message to any channel that's a prefix-match for one of the special channels /meta/handshake, /meta/connect, /meta/subscribe, /meta/unsubscribe or /meta/disconnect, as though it were an exact match for that channel. So, a message to /meta/subscribe/x is still processed as a subscription request, for example.

An authentication bypass for subscription requests is the most serious effect of this but all other meta channels are susceptible to similar manipulation.

This parsing bug in the server is fixed in versions 1.0.4, 1.1.3 and 1.2.5. These should be drop-in replacements for prior versions and you should upgrade immediately if you are running any prior version.

If you are unable to install one of these versions, you can make your extensions catch all messages the server would process by checking the channel begins with the expected channel name, for example:

server.addExtension({
  incoming: function(message, callback) {
    if (message.channel.startsWith('/meta/subscribe')) {
      // authentication logic
    }
    callback(message);
  }
});

Faye uses em-http-request and faye-websocket in the Ruby version of its client. Those libraries both use 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 https: or wss: connection made using these libraries is vulnerable to a man-in-the-middle attack, since it does not confirm the identity of the server it is connected to.

The first request a Faye client makes is always sent via normal HTTP, but later messages may be sent via WebSocket. Therefore it is vulnerable to the same problem that these underlying libraries are, and we needed both libraries to support TLS verification before Faye could claim to do the same. Your client would still be insecure if its initial HTTPS request was verified, but later WebSocket connections were not.

This has been a requested feature in EventMachine for many years now; see for example #275, #378, and #814. In June 2020, em-http-request published an advisory related to this problem and fixed it by implementing TLS verification 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. Based on this implementation, we have incorporated similar functionality into faye-websocket.

After implementing verification in v1.1.6, em-http-request has elected to leave the :verify_peer option switched off by default. We have decided to enable this option by default in Faye, but are publishing a minor release with added functionality for configuring it. We are mindful of the fact that this may break existing programs, but we consider it much more important that all clients have TLS verification turned on by default. A client that is not carrying out verification is either:

• talking to the expected server, and will not break under this change
• being attacked, and would benefit from being alerted to this fact
• deliberately talking to a server that would be rejected by verification

The latter case includes situations like talking to a non-public server using a self-signed certificate. We consider this use case to be "working by accident", rather than functionality that was actively supported, and it should be properly and explicitly supported instead.

We are releasing Faye v1.4.0, which enables verification by default and provides a way to opt out of it:

client = Faye::Client.new('https://example.com/', tls: { verify_peer: false })

Unfortunately we can't offer an equivalent of the :root_cert_file option that has been added to faye-websocket, because em-http-request does not support it. If you need to talk to servers whose certificates are not recognised by your default root certificates, then you need to add its certificate (or another one that can verify it) to your system's root set.

The same functionality is now supported in the Node.js version, with a tls option whose values will be passed to the https and tls modules as appropriate when making connections. For example, you can provide your own CA certificate:

var client = new faye.Client('https://example.com/', {
  tls: {
    ca: fs.readFileSync('path/to/certificate.pem')
  }
});

For further background information on this issue, please see faye#524 and faye-websocket#129. We would like to thank Tero Marttila and Daniel Morsing for providing invaluable assistance and feedback on this issue.

On 20 April 2020 it was reported to me that the potential for authentication bypass exists in Faye's extension system. This vulnerability has existed in the Node.js and Ruby versions of the server since version 0.5.0, when extensions were first introduced, in July 2010. It is patched in versions 1.0.4, 1.1.3 and 1.2.5, which we are releasing today.

The vulnerability allows any client to bypass checks put in place by server-side extensions, by appending extra segments to the message channel. For example, the Faye extension docs suggest that users implement access control for subscriptions by checking incoming messages for the /meta/subscribe channel, for example:

server.addExtension({
  incoming: function(message, callback) {
    if (message.channel === '/meta/subscribe') {
      if (message.ext.authToken !== 'my super secret password') {
        message.error = 'Invalid auth token';
      }
    }
    callback(message);
  }
});

A bug in the server's code for recognising the special /meta/* channels, which trigger connection and subscription events, means that a client can bypass this check by sending a message to /meta/subscribe/x rather than /meta/subscribe:

{
  "channel": "/meta/subscribe/x",
  "clientId": "3jrc6602npj4gyp6bn5ap2wqzjtb2q3",
  "subscription": "/foo"
}

This message will not be checked by the above extension, as it checks the message's channel is exactly equal to /meta/subscribe. But it will still be processed as a subscription request by the server, so the client becomes subscribed to the channel /foo without supplying the necessary credentials.

The vulnerability is caused by the way the Faye server recognises meta channels. It will treat a message to any channel that's a prefix-match for one of the special channels /meta/handshake, /meta/connect, /meta/subscribe, /meta/unsubscribe or /meta/disconnect, as though it were an exact match for that channel. So, a message to /meta/subscribe/x is still processed as a subscription request, for example.

An authentication bypass for subscription requests is the most serious effect of this but all other meta channels are susceptible to similar manipulation.

This parsing bug in the server is fixed in versions 1.0.4, 1.1.3 and 1.2.5. These should be drop-in replacements for prior versions and you should upgrade immediately if you are running any prior version.

If you are unable to install one of these versions, you can make your extensions catch all messages the server would process by checking the channel begins with the expected channel name, for example:

server.addExtension({
  incoming: function(message, callback) {
    if (message.channel.startsWith('/meta/subscribe')) {
      // authentication logic
    }
    callback(message);
  }
});

Faye uses em-http-request and faye-websocket in the Ruby version of its client. Those libraries both use 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 https: or wss: connection made using these libraries is vulnerable to a man-in-the-middle attack, since it does not confirm the identity of the server it is connected to.

The first request a Faye client makes is always sent via normal HTTP, but later messages may be sent via WebSocket. Therefore it is vulnerable to the same problem that these underlying libraries are, and we needed both libraries to support TLS verification before Faye could claim to do the same. Your client would still be insecure if its initial HTTPS request was verified, but later WebSocket connections were not.

This has been a requested feature in EventMachine for many years now; see for example #275, #378, and #814. In June 2020, em-http-request published an advisory related to this problem and fixed it by implementing TLS verification 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. Based on this implementation, we have incorporated similar functionality into faye-websocket.

After implementing verification in v1.1.6, em-http-request has elected to leave the :verify_peer option switched off by default. We have decided to enable this option by default in Faye, but are publishing a minor release with added functionality for configuring it. We are mindful of the fact that this may break existing programs, but we consider it much more important that all clients have TLS verification turned on by default. A client that is not carrying out verification is either:

• talking to the expected server, and will not break under this change
• being attacked, and would benefit from being alerted to this fact
• deliberately talking to a server that would be rejected by verification

The latter case includes situations like talking to a non-public server using a self-signed certificate. We consider this use case to be "working by accident", rather than functionality that was actively supported, and it should be properly and explicitly supported instead.

We are releasing Faye v1.4.0, which enables verification by default and provides a way to opt out of it:

client = Faye::Client.new('https://example.com/', tls: { verify_peer: false })

Unfortunately we can't offer an equivalent of the :root_cert_file option that has been added to faye-websocket, because em-http-request does not support it. If you need to talk to servers whose certificates are not recognised by your default root certificates, then you need to add its certificate (or another one that can verify it) to your system's root set.

The same functionality is now supported in the Node.js version, with a tls option whose values will be passed to the https and tls modules as appropriate when making connections. For example, you can provide your own CA certificate:

var client = new faye.Client('https://example.com/', {
  tls: {
    ca: fs.readFileSync('path/to/certificate.pem')
  }
});

For further background information on this issue, please see faye#524 and faye-websocket#129. We would like to thank Tero Marttila and Daniel Morsing for providing invaluable assistance and feedback on this issue.

On 20 April 2020 it was reported to me that the potential for authentication bypass exists in Faye's extension system. This vulnerability has existed in the Node.js and Ruby versions of the server since version 0.5.0, when extensions were first introduced, in July 2010. It is patched in versions 1.0.4, 1.1.3 and 1.2.5, which we are releasing today.

The vulnerability allows any client to bypass checks put in place by server-side extensions, by appending extra segments to the message channel. For example, the Faye extension docs suggest that users implement access control for subscriptions by checking incoming messages for the /meta/subscribe channel, for example:

server.addExtension({
  incoming: function(message, callback) {
    if (message.channel === '/meta/subscribe') {
      if (message.ext.authToken !== 'my super secret password') {
        message.error = 'Invalid auth token';
      }
    }
    callback(message);
  }
});

A bug in the server's code for recognising the special /meta/* channels, which trigger connection and subscription events, means that a client can bypass this check by sending a message to /meta/subscribe/x rather than /meta/subscribe:

{
  "channel": "/meta/subscribe/x",
  "clientId": "3jrc6602npj4gyp6bn5ap2wqzjtb2q3",
  "subscription": "/foo"
}

This message will not be checked by the above extension, as it checks the message's channel is exactly equal to /meta/subscribe. But it will still be processed as a subscription request by the server, so the client becomes subscribed to the channel /foo without supplying the necessary credentials.

The vulnerability is caused by the way the Faye server recognises meta channels. It will treat a message to any channel that's a prefix-match for one of the special channels /meta/handshake, /meta/connect, /meta/subscribe, /meta/unsubscribe or /meta/disconnect, as though it were an exact match for that channel. So, a message to /meta/subscribe/x is still processed as a subscription request, for example.

An authentication bypass for subscription requests is the most serious effect of this but all other meta channels are susceptible to similar manipulation.

This parsing bug in the server is fixed in versions 1.0.4, 1.1.3 and 1.2.5. These should be drop-in replacements for prior versions and you should upgrade immediately if you are running any prior version.

If you are unable to install one of these versions, you can make your extensions catch all messages the server would process by checking the channel begins with the expected channel name, for example:

server.addExtension({
  incoming: function(message, callback) {
    if (message.channel.startsWith('/meta/subscribe')) {
      // authentication logic
    }
    callback(message);
  }
});

Faye uses em-http-request and faye-websocket in the Ruby version of its client. Those libraries both use 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 https: or wss: connection made using these libraries is vulnerable to a man-in-the-middle attack, since it does not confirm the identity of the server it is connected to.

The first request a Faye client makes is always sent via normal HTTP, but later messages may be sent via WebSocket. Therefore it is vulnerable to the same problem that these underlying libraries are, and we needed both libraries to support TLS verification before Faye could claim to do the same. Your client would still be insecure if its initial HTTPS request was verified, but later WebSocket connections were not.

This has been a requested feature in EventMachine for many years now; see for example #275, #378, and #814. In June 2020, em-http-request published an advisory related to this problem and fixed it by implementing TLS verification 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. Based on this implementation, we have incorporated similar functionality into faye-websocket.

After implementing verification in v1.1.6, em-http-request has elected to leave the :verify_peer option switched off by default. We have decided to enable this option by default in Faye, but are publishing a minor release with added functionality for configuring it. We are mindful of the fact that this may break existing programs, but we consider it much more important that all clients have TLS verification turned on by default. A client that is not carrying out verification is either:

• talking to the expected server, and will not break under this change
• being attacked, and would benefit from being alerted to this fact
• deliberately talking to a server that would be rejected by verification

The latter case includes situations like talking to a non-public server using a self-signed certificate. We consider this use case to be "working by accident", rather than functionality that was actively supported, and it should be properly and explicitly supported instead.

We are releasing Faye v1.4.0, which enables verification by default and provides a way to opt out of it:

client = Faye::Client.new('https://example.com/', tls: { verify_peer: false })

Unfortunately we can't offer an equivalent of the :root_cert_file option that has been added to faye-websocket, because em-http-request does not support it. If you need to talk to servers whose certificates are not recognised by your default root certificates, then you need to add its certificate (or another one that can verify it) to your system's root set.

The same functionality is now supported in the Node.js version, with a tls option whose values will be passed to the https and tls modules as appropriate when making connections. For example, you can provide your own CA certificate:

var client = new faye.Client('https://example.com/', {
  tls: {
    ca: fs.readFileSync('path/to/certificate.pem')
  }
});

For further background information on this issue, please see faye#524 and faye-websocket#129. We would like to thank Tero Marttila and Daniel Morsing for providing invaluable assistance and feedback on this issue.

On 20 April 2020 it was reported to me that the potential for authentication bypass exists in Faye's extension system. This vulnerability has existed in the Node.js and Ruby versions of the server since version 0.5.0, when extensions were first introduced, in July 2010. It is patched in versions 1.0.4, 1.1.3 and 1.2.5, which we are releasing today.

The vulnerability allows any client to bypass checks put in place by server-side extensions, by appending extra segments to the message channel. For example, the Faye extension docs suggest that users implement access control for subscriptions by checking incoming messages for the /meta/subscribe channel, for example:

server.addExtension({
  incoming: function(message, callback) {
    if (message.channel === '/meta/subscribe') {
      if (message.ext.authToken !== 'my super secret password') {
        message.error = 'Invalid auth token';
      }
    }
    callback(message);
  }
});

A bug in the server's code for recognising the special /meta/* channels, which trigger connection and subscription events, means that a client can bypass this check by sending a message to /meta/subscribe/x rather than /meta/subscribe:

{
  "channel": "/meta/subscribe/x",
  "clientId": "3jrc6602npj4gyp6bn5ap2wqzjtb2q3",
  "subscription": "/foo"
}

This message will not be checked by the above extension, as it checks the message's channel is exactly equal to /meta/subscribe. But it will still be processed as a subscription request by the server, so the client becomes subscribed to the channel /foo without supplying the necessary credentials.

The vulnerability is caused by the way the Faye server recognises meta channels. It will treat a message to any channel that's a prefix-match for one of the special channels /meta/handshake, /meta/connect, /meta/subscribe, /meta/unsubscribe or /meta/disconnect, as though it were an exact match for that channel. So, a message to /meta/subscribe/x is still processed as a subscription request, for example.

An authentication bypass for subscription requests is the most serious effect of this but all other meta channels are susceptible to similar manipulation.

This parsing bug in the server is fixed in versions 1.0.4, 1.1.3 and 1.2.5. These should be drop-in replacements for prior versions and you should upgrade immediately if you are running any prior version.

If you are unable to install one of these versions, you can make your extensions catch all messages the server would process by checking the channel begins with the expected channel name, for example:

server.addExtension({
  incoming: function(message, callback) {
    if (message.channel.startsWith('/meta/subscribe')) {
      // authentication logic
    }
    callback(message);
  }
});

Faye uses em-http-request and faye-websocket in the Ruby version of its client. Those libraries both use 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 https: or wss: connection made using these libraries is vulnerable to a man-in-the-middle attack, since it does not confirm the identity of the server it is connected to.

The first request a Faye client makes is always sent via normal HTTP, but later messages may be sent via WebSocket. Therefore it is vulnerable to the same problem that these underlying libraries are, and we needed both libraries to support TLS verification before Faye could claim to do the same. Your client would still be insecure if its initial HTTPS request was verified, but later WebSocket connections were not.

This has been a requested feature in EventMachine for many years now; see for example #275, #378, and #814. In June 2020, em-http-request published an advisory related to this problem and fixed it by implementing TLS verification 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. Based on this implementation, we have incorporated similar functionality into faye-websocket.

After implementing verification in v1.1.6, em-http-request has elected to leave the :verify_peer option switched off by default. We have decided to enable this option by default in Faye, but are publishing a minor release with added functionality for configuring it. We are mindful of the fact that this may break existing programs, but we consider it much more important that all clients have TLS verification turned on by default. A client that is not carrying out verification is either:

• talking to the expected server, and will not break under this change
• being attacked, and would benefit from being alerted to this fact
• deliberately talking to a server that would be rejected by verification

The latter case includes situations like talking to a non-public server using a self-signed certificate. We consider this use case to be "working by accident", rather than functionality that was actively supported, and it should be properly and explicitly supported instead.

We are releasing Faye v1.4.0, which enables verification by default and provides a way to opt out of it:

client = Faye::Client.new('https://example.com/', tls: { verify_peer: false })

Unfortunately we can't offer an equivalent of the :root_cert_file option that has been added to faye-websocket, because em-http-request does not support it. If you need to talk to servers whose certificates are not recognised by your default root certificates, then you need to add its certificate (or another one that can verify it) to your system's root set.

The same functionality is now supported in the Node.js version, with a tls option whose values will be passed to the https and tls modules as appropriate when making connections. For example, you can provide your own CA certificate:

var client = new faye.Client('https://example.com/', {
  tls: {
    ca: fs.readFileSync('path/to/certificate.pem')
  }
});

For further background information on this issue, please see faye#524 and faye-websocket#129. We would like to thank Tero Marttila and Daniel Morsing for providing invaluable assistance and feedback on this issue.

On 20 April 2020 it was reported to me that the potential for authentication bypass exists in Faye's extension system. This vulnerability has existed in the Node.js and Ruby versions of the server since version 0.5.0, when extensions were first introduced, in July 2010. It is patched in versions 1.0.4, 1.1.3 and 1.2.5, which we are releasing today.

The vulnerability allows any client to bypass checks put in place by server-side extensions, by appending extra segments to the message channel. For example, the Faye extension docs suggest that users implement access control for subscriptions by checking incoming messages for the /meta/subscribe channel, for example:

server.addExtension({
  incoming: function(message, callback) {
    if (message.channel === '/meta/subscribe') {
      if (message.ext.authToken !== 'my super secret password') {
        message.error = 'Invalid auth token';
      }
    }
    callback(message);
  }
});

A bug in the server's code for recognising the special /meta/* channels, which trigger connection and subscription events, means that a client can bypass this check by sending a message to /meta/subscribe/x rather than /meta/subscribe:

{
  "channel": "/meta/subscribe/x",
  "clientId": "3jrc6602npj4gyp6bn5ap2wqzjtb2q3",
  "subscription": "/foo"
}

This message will not be checked by the above extension, as it checks the message's channel is exactly equal to /meta/subscribe. But it will still be processed as a subscription request by the server, so the client becomes subscribed to the channel /foo without supplying the necessary credentials.

The vulnerability is caused by the way the Faye server recognises meta channels. It will treat a message to any channel that's a prefix-match for one of the special channels /meta/handshake, /meta/connect, /meta/subscribe, /meta/unsubscribe or /meta/disconnect, as though it were an exact match for that channel. So, a message to /meta/subscribe/x is still processed as a subscription request, for example.

An authentication bypass for subscription requests is the most serious effect of this but all other meta channels are susceptible to similar manipulation.

This parsing bug in the server is fixed in versions 1.0.4, 1.1.3 and 1.2.5. These should be drop-in replacements for prior versions and you should upgrade immediately if you are running any prior version.

If you are unable to install one of these versions, you can make your extensions catch all messages the server would process by checking the channel begins with the expected channel name, for example:

server.addExtension({
  incoming: function(message, callback) {
    if (message.channel.startsWith('/meta/subscribe')) {
      // authentication logic
    }
    callback(message);
  }
});

Faye uses em-http-request and faye-websocket in the Ruby version of its client. Those libraries both use 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 https: or wss: connection made using these libraries is vulnerable to a man-in-the-middle attack, since it does not confirm the identity of the server it is connected to.

The first request a Faye client makes is always sent via normal HTTP, but later messages may be sent via WebSocket. Therefore it is vulnerable to the same problem that these underlying libraries are, and we needed both libraries to support TLS verification before Faye could claim to do the same. Your client would still be insecure if its initial HTTPS request was verified, but later WebSocket connections were not.

This has been a requested feature in EventMachine for many years now; see for example #275, #378, and #814. In June 2020, em-http-request published an advisory related to this problem and fixed it by implementing TLS verification 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. Based on this implementation, we have incorporated similar functionality into faye-websocket.

After implementing verification in v1.1.6, em-http-request has elected to leave the :verify_peer option switched off by default. We have decided to enable this option by default in Faye, but are publishing a minor release with added functionality for configuring it. We are mindful of the fact that this may break existing programs, but we consider it much more important that all clients have TLS verification turned on by default. A client that is not carrying out verification is either:

• talking to the expected server, and will not break under this change
• being attacked, and would benefit from being alerted to this fact
• deliberately talking to a server that would be rejected by verification

The latter case includes situations like talking to a non-public server using a self-signed certificate. We consider this use case to be "working by accident", rather than functionality that was actively supported, and it should be properly and explicitly supported instead.

We are releasing Faye v1.4.0, which enables verification by default and provides a way to opt out of it:

client = Faye::Client.new('https://example.com/', tls: { verify_peer: false })

Unfortunately we can't offer an equivalent of the :root_cert_file option that has been added to faye-websocket, because em-http-request does not support it. If you need to talk to servers whose certificates are not recognised by your default root certificates, then you need to add its certificate (or another one that can verify it) to your system's root set.

The same functionality is now supported in the Node.js version, with a tls option whose values will be passed to the https and tls modules as appropriate when making connections. For example, you can provide your own CA certificate:

var client = new faye.Client('https://example.com/', {
  tls: {
    ca: fs.readFileSync('path/to/certificate.pem')
  }
});

For further background information on this issue, please see faye#524 and faye-websocket#129. We would like to thank Tero Marttila and Daniel Morsing for providing invaluable assistance and feedback on this issue.

On 20 April 2020 it was reported to me that the potential for authentication bypass exists in Faye's extension system. This vulnerability has existed in the Node.js and Ruby versions of the server since version 0.5.0, when extensions were first introduced, in July 2010. It is patched in versions 1.0.4, 1.1.3 and 1.2.5, which we are releasing today.

The vulnerability allows any client to bypass checks put in place by server-side extensions, by appending extra segments to the message channel. For example, the Faye extension docs suggest that users implement access control for subscriptions by checking incoming messages for the /meta/subscribe channel, for example:

server.addExtension({
  incoming: function(message, callback) {
    if (message.channel === '/meta/subscribe') {
      if (message.ext.authToken !== 'my super secret password') {
        message.error = 'Invalid auth token';
      }
    }
    callback(message);
  }
});

A bug in the server's code for recognising the special /meta/* channels, which trigger connection and subscription events, means that a client can bypass this check by sending a message to /meta/subscribe/x rather than /meta/subscribe:

{
  "channel": "/meta/subscribe/x",
  "clientId": "3jrc6602npj4gyp6bn5ap2wqzjtb2q3",
  "subscription": "/foo"
}

This message will not be checked by the above extension, as it checks the message's channel is exactly equal to /meta/subscribe. But it will still be processed as a subscription request by the server, so the client becomes subscribed to the channel /foo without supplying the necessary credentials.

The vulnerability is caused by the way the Faye server recognises meta channels. It will treat a message to any channel that's a prefix-match for one of the special channels /meta/handshake, /meta/connect, /meta/subscribe, /meta/unsubscribe or /meta/disconnect, as though it were an exact match for that channel. So, a message to /meta/subscribe/x is still processed as a subscription request, for example.

An authentication bypass for subscription requests is the most serious effect of this but all other meta channels are susceptible to similar manipulation.

This parsing bug in the server is fixed in versions 1.0.4, 1.1.3 and 1.2.5. These should be drop-in replacements for prior versions and you should upgrade immediately if you are running any prior version.

If you are unable to install one of these versions, you can make your extensions catch all messages the server would process by checking the channel begins with the expected channel name, for example:

server.addExtension({
  incoming: function(message, callback) {
    if (message.channel.startsWith('/meta/subscribe')) {
      // authentication logic
    }
    callback(message);
  }
});

Faye uses em-http-request and faye-websocket in the Ruby version of its client. Those libraries both use 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 https: or wss: connection made using these libraries is vulnerable to a man-in-the-middle attack, since it does not confirm the identity of the server it is connected to.

The first request a Faye client makes is always sent via normal HTTP, but later messages may be sent via WebSocket. Therefore it is vulnerable to the same problem that these underlying libraries are, and we needed both libraries to support TLS verification before Faye could claim to do the same. Your client would still be insecure if its initial HTTPS request was verified, but later WebSocket connections were not.

This has been a requested feature in EventMachine for many years now; see for example #275, #378, and #814. In June 2020, em-http-request published an advisory related to this problem and fixed it by implementing TLS verification 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. Based on this implementation, we have incorporated similar functionality into faye-websocket.

After implementing verification in v1.1.6, em-http-request has elected to leave the :verify_peer option switched off by default. We have decided to enable this option by default in Faye, but are publishing a minor release with added functionality for configuring it. We are mindful of the fact that this may break existing programs, but we consider it much more important that all clients have TLS verification turned on by default. A client that is not carrying out verification is either:

• talking to the expected server, and will not break under this change
• being attacked, and would benefit from being alerted to this fact
• deliberately talking to a server that would be rejected by verification

The latter case includes situations like talking to a non-public server using a self-signed certificate. We consider this use case to be "working by accident", rather than functionality that was actively supported, and it should be properly and explicitly supported instead.

We are releasing Faye v1.4.0, which enables verification by default and provides a way to opt out of it:

client = Faye::Client.new('https://example.com/', tls: { verify_peer: false })

Unfortunately we can't offer an equivalent of the :root_cert_file option that has been added to faye-websocket, because em-http-request does not support it. If you need to talk to servers whose certificates are not recognised by your default root certificates, then you need to add its certificate (or another one that can verify it) to your system's root set.

The same functionality is now supported in the Node.js version, with a tls option whose values will be passed to the https and tls modules as appropriate when making connections. For example, you can provide your own CA certificate:

var client = new faye.Client('https://example.com/', {
  tls: {
    ca: fs.readFileSync('path/to/certificate.pem')
  }
});

For further background information on this issue, please see faye#524 and faye-websocket#129. We would like to thank Tero Marttila and Daniel Morsing for providing invaluable assistance and feedback on this issue.

On 20 April 2020 it was reported to me that the potential for authentication bypass exists in Faye's extension system. This vulnerability has existed in the Node.js and Ruby versions of the server since version 0.5.0, when extensions were first introduced, in July 2010. It is patched in versions 1.0.4, 1.1.3 and 1.2.5, which we are releasing today.

The vulnerability allows any client to bypass checks put in place by server-side extensions, by appending extra segments to the message channel. For example, the Faye extension docs suggest that users implement access control for subscriptions by checking incoming messages for the /meta/subscribe channel, for example:

server.addExtension({
  incoming: function(message, callback) {
    if (message.channel === '/meta/subscribe') {
      if (message.ext.authToken !== 'my super secret password') {
        message.error = 'Invalid auth token';
      }
    }
    callback(message);
  }
});

A bug in the server's code for recognising the special /meta/* channels, which trigger connection and subscription events, means that a client can bypass this check by sending a message to /meta/subscribe/x rather than /meta/subscribe:

{
  "channel": "/meta/subscribe/x",
  "clientId": "3jrc6602npj4gyp6bn5ap2wqzjtb2q3",
  "subscription": "/foo"
}

This message will not be checked by the above extension, as it checks the message's channel is exactly equal to /meta/subscribe. But it will still be processed as a subscription request by the server, so the client becomes subscribed to the channel /foo without supplying the necessary credentials.

The vulnerability is caused by the way the Faye server recognises meta channels. It will treat a message to any channel that's a prefix-match for one of the special channels /meta/handshake, /meta/connect, /meta/subscribe, /meta/unsubscribe or /meta/disconnect, as though it were an exact match for that channel. So, a message to /meta/subscribe/x is still processed as a subscription request, for example.

An authentication bypass for subscription requests is the most serious effect of this but all other meta channels are susceptible to similar manipulation.

This parsing bug in the server is fixed in versions 1.0.4, 1.1.3 and 1.2.5. These should be drop-in replacements for prior versions and you should upgrade immediately if you are running any prior version.

If you are unable to install one of these versions, you can make your extensions catch all messages the server would process by checking the channel begins with the expected channel name, for example:

server.addExtension({
  incoming: function(message, callback) {
    if (message.channel.startsWith('/meta/subscribe')) {
      // authentication logic
    }
    callback(message);
  }
});

Faye uses em-http-request and faye-websocket in the Ruby version of its client. Those libraries both use 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 https: or wss: connection made using these libraries is vulnerable to a man-in-the-middle attack, since it does not confirm the identity of the server it is connected to.

The first request a Faye client makes is always sent via normal HTTP, but later messages may be sent via WebSocket. Therefore it is vulnerable to the same problem that these underlying libraries are, and we needed both libraries to support TLS verification before Faye could claim to do the same. Your client would still be insecure if its initial HTTPS request was verified, but later WebSocket connections were not.

This has been a requested feature in EventMachine for many years now; see for example #275, #378, and #814. In June 2020, em-http-request published an advisory related to this problem and fixed it by implementing TLS verification 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. Based on this implementation, we have incorporated similar functionality into faye-websocket.

After implementing verification in v1.1.6, em-http-request has elected to leave the :verify_peer option switched off by default. We have decided to enable this option by default in Faye, but are publishing a minor release with added functionality for configuring it. We are mindful of the fact that this may break existing programs, but we consider it much more important that all clients have TLS verification turned on by default. A client that is not carrying out verification is either:

• talking to the expected server, and will not break under this change
• being attacked, and would benefit from being alerted to this fact
• deliberately talking to a server that would be rejected by verification

The latter case includes situations like talking to a non-public server using a self-signed certificate. We consider this use case to be "working by accident", rather than functionality that was actively supported, and it should be properly and explicitly supported instead.

We are releasing Faye v1.4.0, which enables verification by default and provides a way to opt out of it:

client = Faye::Client.new('https://example.com/', tls: { verify_peer: false })

Unfortunately we can't offer an equivalent of the :root_cert_file option that has been added to faye-websocket, because em-http-request does not support it. If you need to talk to servers whose certificates are not recognised by your default root certificates, then you need to add its certificate (or another one that can verify it) to your system's root set.

The same functionality is now supported in the Node.js version, with a tls option whose values will be passed to the https and tls modules as appropriate when making connections. For example, you can provide your own CA certificate:

var client = new faye.Client('https://example.com/', {
  tls: {
    ca: fs.readFileSync('path/to/certificate.pem')
  }
});

For further background information on this issue, please see faye#524 and faye-websocket#129. We would like to thank Tero Marttila and Daniel Morsing for providing invaluable assistance and feedback on this issue.

On 20 April 2020 it was reported to me that the potential for authentication bypass exists in Faye's extension system. This vulnerability has existed in the Node.js and Ruby versions of the server since version 0.5.0, when extensions were first introduced, in July 2010. It is patched in versions 1.0.4, 1.1.3 and 1.2.5, which we are releasing today.

The vulnerability allows any client to bypass checks put in place by server-side extensions, by appending extra segments to the message channel. For example, the Faye extension docs suggest that users implement access control for subscriptions by checking incoming messages for the /meta/subscribe channel, for example:

server.addExtension({
  incoming: function(message, callback) {
    if (message.channel === '/meta/subscribe') {
      if (message.ext.authToken !== 'my super secret password') {
        message.error = 'Invalid auth token';
      }
    }
    callback(message);
  }
});

A bug in the server's code for recognising the special /meta/* channels, which trigger connection and subscription events, means that a client can bypass this check by sending a message to /meta/subscribe/x rather than /meta/subscribe:

{
  "channel": "/meta/subscribe/x",
  "clientId": "3jrc6602npj4gyp6bn5ap2wqzjtb2q3",
  "subscription": "/foo"
}

This message will not be checked by the above extension, as it checks the message's channel is exactly equal to /meta/subscribe. But it will still be processed as a subscription request by the server, so the client becomes subscribed to the channel /foo without supplying the necessary credentials.

The vulnerability is caused by the way the Faye server recognises meta channels. It will treat a message to any channel that's a prefix-match for one of the special channels /meta/handshake, /meta/connect, /meta/subscribe, /meta/unsubscribe or /meta/disconnect, as though it were an exact match for that channel. So, a message to /meta/subscribe/x is still processed as a subscription request, for example.

An authentication bypass for subscription requests is the most serious effect of this but all other meta channels are susceptible to similar manipulation.

This parsing bug in the server is fixed in versions 1.0.4, 1.1.3 and 1.2.5. These should be drop-in replacements for prior versions and you should upgrade immediately if you are running any prior version.

If you are unable to install one of these versions, you can make your extensions catch all messages the server would process by checking the channel begins with the expected channel name, for example:

server.addExtension({
  incoming: function(message, callback) {
    if (message.channel.startsWith('/meta/subscribe')) {
      // authentication logic
    }
    callback(message);
  }
});

Faye uses em-http-request and faye-websocket in the Ruby version of its client. Those libraries both use 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 https: or wss: connection made using these libraries is vulnerable to a man-in-the-middle attack, since it does not confirm the identity of the server it is connected to.

The first request a Faye client makes is always sent via normal HTTP, but later messages may be sent via WebSocket. Therefore it is vulnerable to the same problem that these underlying libraries are, and we needed both libraries to support TLS verification before Faye could claim to do the same. Your client would still be insecure if its initial HTTPS request was verified, but later WebSocket connections were not.

This has been a requested feature in EventMachine for many years now; see for example #275, #378, and #814. In June 2020, em-http-request published an advisory related to this problem and fixed it by implementing TLS verification 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. Based on this implementation, we have incorporated similar functionality into faye-websocket.

After implementing verification in v1.1.6, em-http-request has elected to leave the :verify_peer option switched off by default. We have decided to enable this option by default in Faye, but are publishing a minor release with added functionality for configuring it. We are mindful of the fact that this may break existing programs, but we consider it much more important that all clients have TLS verification turned on by default. A client that is not carrying out verification is either:

• talking to the expected server, and will not break under this change
• being attacked, and would benefit from being alerted to this fact
• deliberately talking to a server that would be rejected by verification

The latter case includes situations like talking to a non-public server using a self-signed certificate. We consider this use case to be "working by accident", rather than functionality that was actively supported, and it should be properly and explicitly supported instead.

We are releasing Faye v1.4.0, which enables verification by default and provides a way to opt out of it:

client = Faye::Client.new('https://example.com/', tls: { verify_peer: false })

Unfortunately we can't offer an equivalent of the :root_cert_file option that has been added to faye-websocket, because em-http-request does not support it. If you need to talk to servers whose certificates are not recognised by your default root certificates, then you need to add its certificate (or another one that can verify it) to your system's root set.

The same functionality is now supported in the Node.js version, with a tls option whose values will be passed to the https and tls modules as appropriate when making connections. For example, you can provide your own CA certificate:

var client = new faye.Client('https://example.com/', {
  tls: {
    ca: fs.readFileSync('path/to/certificate.pem')
  }
});

For further background information on this issue, please see faye#524 and faye-websocket#129. We would like to thank Tero Marttila and Daniel Morsing for providing invaluable assistance and feedback on this issue.

On 20 April 2020 it was reported to me that the potential for authentication bypass exists in Faye's extension system. This vulnerability has existed in the Node.js and Ruby versions of the server since version 0.5.0, when extensions were first introduced, in July 2010. It is patched in versions 1.0.4, 1.1.3 and 1.2.5, which we are releasing today.

The vulnerability allows any client to bypass checks put in place by server-side extensions, by appending extra segments to the message channel. For example, the Faye extension docs suggest that users implement access control for subscriptions by checking incoming messages for the /meta/subscribe channel, for example:

server.addExtension({
  incoming: function(message, callback) {
    if (message.channel === '/meta/subscribe') {
      if (message.ext.authToken !== 'my super secret password') {
        message.error = 'Invalid auth token';
      }
    }
    callback(message);
  }
});

A bug in the server's code for recognising the special /meta/* channels, which trigger connection and subscription events, means that a client can bypass this check by sending a message to /meta/subscribe/x rather than /meta/subscribe:

{
  "channel": "/meta/subscribe/x",
  "clientId": "3jrc6602npj4gyp6bn5ap2wqzjtb2q3",
  "subscription": "/foo"
}

This message will not be checked by the above extension, as it checks the message's channel is exactly equal to /meta/subscribe. But it will still be processed as a subscription request by the server, so the client becomes subscribed to the channel /foo without supplying the necessary credentials.

The vulnerability is caused by the way the Faye server recognises meta channels. It will treat a message to any channel that's a prefix-match for one of the special channels /meta/handshake, /meta/connect, /meta/subscribe, /meta/unsubscribe or /meta/disconnect, as though it were an exact match for that channel. So, a message to /meta/subscribe/x is still processed as a subscription request, for example.

An authentication bypass for subscription requests is the most serious effect of this but all other meta channels are susceptible to similar manipulation.

This parsing bug in the server is fixed in versions 1.0.4, 1.1.3 and 1.2.5. These should be drop-in replacements for prior versions and you should upgrade immediately if you are running any prior version.

If you are unable to install one of these versions, you can make your extensions catch all messages the server would process by checking the channel begins with the expected channel name, for example:

server.addExtension({
  incoming: function(message, callback) {
    if (message.channel.startsWith('/meta/subscribe')) {
      // authentication logic
    }
    callback(message);
  }
});

Faye uses em-http-request and faye-websocket in the Ruby version of its client. Those libraries both use 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 https: or wss: connection made using these libraries is vulnerable to a man-in-the-middle attack, since it does not confirm the identity of the server it is connected to.

The first request a Faye client makes is always sent via normal HTTP, but later messages may be sent via WebSocket. Therefore it is vulnerable to the same problem that these underlying libraries are, and we needed both libraries to support TLS verification before Faye could claim to do the same. Your client would still be insecure if its initial HTTPS request was verified, but later WebSocket connections were not.

This has been a requested feature in EventMachine for many years now; see for example #275, #378, and #814. In June 2020, em-http-request published an advisory related to this problem and fixed it by implementing TLS verification 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. Based on this implementation, we have incorporated similar functionality into faye-websocket.

After implementing verification in v1.1.6, em-http-request has elected to leave the :verify_peer option switched off by default. We have decided to enable this option by default in Faye, but are publishing a minor release with added functionality for configuring it. We are mindful of the fact that this may break existing programs, but we consider it much more important that all clients have TLS verification turned on by default. A client that is not carrying out verification is either:

• talking to the expected server, and will not break under this change
• being attacked, and would benefit from being alerted to this fact
• deliberately talking to a server that would be rejected by verification

The latter case includes situations like talking to a non-public server using a self-signed certificate. We consider this use case to be "working by accident", rather than functionality that was actively supported, and it should be properly and explicitly supported instead.

We are releasing Faye v1.4.0, which enables verification by default and provides a way to opt out of it:

client = Faye::Client.new('https://example.com/', tls: { verify_peer: false })

Unfortunately we can't offer an equivalent of the :root_cert_file option that has been added to faye-websocket, because em-http-request does not support it. If you need to talk to servers whose certificates are not recognised by your default root certificates, then you need to add its certificate (or another one that can verify it) to your system's root set.

The same functionality is now supported in the Node.js version, with a tls option whose values will be passed to the https and tls modules as appropriate when making connections. For example, you can provide your own CA certificate:

var client = new faye.Client('https://example.com/', {
  tls: {
    ca: fs.readFileSync('path/to/certificate.pem')
  }
});

For further background information on this issue, please see faye#524 and faye-websocket#129. We would like to thank Tero Marttila and Daniel Morsing for providing invaluable assistance and feedback on this issue.

On 20 April 2020 it was reported to me that the potential for authentication bypass exists in Faye's extension system. This vulnerability has existed in the Node.js and Ruby versions of the server since version 0.5.0, when extensions were first introduced, in July 2010. It is patched in versions 1.0.4, 1.1.3 and 1.2.5, which we are releasing today.

The vulnerability allows any client to bypass checks put in place by server-side extensions, by appending extra segments to the message channel. For example, the Faye extension docs suggest that users implement access control for subscriptions by checking incoming messages for the /meta/subscribe channel, for example:

server.addExtension({
  incoming: function(message, callback) {
    if (message.channel === '/meta/subscribe') {
      if (message.ext.authToken !== 'my super secret password') {
        message.error = 'Invalid auth token';
      }
    }
    callback(message);
  }
});

A bug in the server's code for recognising the special /meta/* channels, which trigger connection and subscription events, means that a client can bypass this check by sending a message to /meta/subscribe/x rather than /meta/subscribe:

{
  "channel": "/meta/subscribe/x",
  "clientId": "3jrc6602npj4gyp6bn5ap2wqzjtb2q3",
  "subscription": "/foo"
}

This message will not be checked by the above extension, as it checks the message's channel is exactly equal to /meta/subscribe. But it will still be processed as a subscription request by the server, so the client becomes subscribed to the channel /foo without supplying the necessary credentials.

The vulnerability is caused by the way the Faye server recognises meta channels. It will treat a message to any channel that's a prefix-match for one of the special channels /meta/handshake, /meta/connect, /meta/subscribe, /meta/unsubscribe or /meta/disconnect, as though it were an exact match for that channel. So, a message to /meta/subscribe/x is still processed as a subscription request, for example.

An authentication bypass for subscription requests is the most serious effect of this but all other meta channels are susceptible to similar manipulation.

This parsing bug in the server is fixed in versions 1.0.4, 1.1.3 and 1.2.5. These should be drop-in replacements for prior versions and you should upgrade immediately if you are running any prior version.

If you are unable to install one of these versions, you can make your extensions catch all messages the server would process by checking the channel begins with the expected channel name, for example:

server.addExtension({
  incoming: function(message, callback) {
    if (message.channel.startsWith('/meta/subscribe')) {
      // authentication logic
    }
    callback(message);
  }
});

Faye uses em-http-request and faye-websocket in the Ruby version of its client. Those libraries both use 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 https: or wss: connection made using these libraries is vulnerable to a man-in-the-middle attack, since it does not confirm the identity of the server it is connected to.

The first request a Faye client makes is always sent via normal HTTP, but later messages may be sent via WebSocket. Therefore it is vulnerable to the same problem that these underlying libraries are, and we needed both libraries to support TLS verification before Faye could claim to do the same. Your client would still be insecure if its initial HTTPS request was verified, but later WebSocket connections were not.

This has been a requested feature in EventMachine for many years now; see for example #275, #378, and #814. In June 2020, em-http-request published an advisory related to this problem and fixed it by implementing TLS verification 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. Based on this implementation, we have incorporated similar functionality into faye-websocket.

After implementing verification in v1.1.6, em-http-request has elected to leave the :verify_peer option switched off by default. We have decided to enable this option by default in Faye, but are publishing a minor release with added functionality for configuring it. We are mindful of the fact that this may break existing programs, but we consider it much more important that all clients have TLS verification turned on by default. A client that is not carrying out verification is either:

• talking to the expected server, and will not break under this change
• being attacked, and would benefit from being alerted to this fact
• deliberately talking to a server that would be rejected by verification

The latter case includes situations like talking to a non-public server using a self-signed certificate. We consider this use case to be "working by accident", rather than functionality that was actively supported, and it should be properly and explicitly supported instead.

We are releasing Faye v1.4.0, which enables verification by default and provides a way to opt out of it:

client = Faye::Client.new('https://example.com/', tls: { verify_peer: false })

Unfortunately we can't offer an equivalent of the :root_cert_file option that has been added to faye-websocket, because em-http-request does not support it. If you need to talk to servers whose certificates are not recognised by your default root certificates, then you need to add its certificate (or another one that can verify it) to your system's root set.

The same functionality is now supported in the Node.js version, with a tls option whose values will be passed to the https and tls modules as appropriate when making connections. For example, you can provide your own CA certificate:

var client = new faye.Client('https://example.com/', {
  tls: {
    ca: fs.readFileSync('path/to/certificate.pem')
  }
});

For further background information on this issue, please see faye#524 and faye-websocket#129. We would like to thank Tero Marttila and Daniel Morsing for providing invaluable assistance and feedback on this issue.

On 20 April 2020 it was reported to me that the potential for authentication bypass exists in Faye's extension system. This vulnerability has existed in the Node.js and Ruby versions of the server since version 0.5.0, when extensions were first introduced, in July 2010. It is patched in versions 1.0.4, 1.1.3 and 1.2.5, which we are releasing today.

The vulnerability allows any client to bypass checks put in place by server-side extensions, by appending extra segments to the message channel. For example, the Faye extension docs suggest that users implement access control for subscriptions by checking incoming messages for the /meta/subscribe channel, for example:

server.addExtension({
  incoming: function(message, callback) {
    if (message.channel === '/meta/subscribe') {
      if (message.ext.authToken !== 'my super secret password') {
        message.error = 'Invalid auth token';
      }
    }
    callback(message);
  }
});

A bug in the server's code for recognising the special /meta/* channels, which trigger connection and subscription events, means that a client can bypass this check by sending a message to /meta/subscribe/x rather than /meta/subscribe:

{
  "channel": "/meta/subscribe/x",
  "clientId": "3jrc6602npj4gyp6bn5ap2wqzjtb2q3",
  "subscription": "/foo"
}

This message will not be checked by the above extension, as it checks the message's channel is exactly equal to /meta/subscribe. But it will still be processed as a subscription request by the server, so the client becomes subscribed to the channel /foo without supplying the necessary credentials.

The vulnerability is caused by the way the Faye server recognises meta channels. It will treat a message to any channel that's a prefix-match for one of the special channels /meta/handshake, /meta/connect, /meta/subscribe, /meta/unsubscribe or /meta/disconnect, as though it were an exact match for that channel. So, a message to /meta/subscribe/x is still processed as a subscription request, for example.

An authentication bypass for subscription requests is the most serious effect of this but all other meta channels are susceptible to similar manipulation.

This parsing bug in the server is fixed in versions 1.0.4, 1.1.3 and 1.2.5. These should be drop-in replacements for prior versions and you should upgrade immediately if you are running any prior version.

If you are unable to install one of these versions, you can make your extensions catch all messages the server would process by checking the channel begins with the expected channel name, for example:

server.addExtension({
  incoming: function(message, callback) {
    if (message.channel.startsWith('/meta/subscribe')) {
      // authentication logic
    }
    callback(message);
  }
});