Websocket server accessed over port 5240

[Raphaël Badin]

My main MAAS testing machine only allows communication via port 80… when upgrading to the new MAAS version which uses Websocket, the UI was not working properly (see bug 1436277 for details).

We could maybe investigate the use of a module to have apache proxy the websockets connection: even if the plan is to drop apache in the future, people upgrading might still want to keep apache.

[Scott Moser (smoser)]

Note, this is problematic when port forwarding through ssh.
Previously this worked:

$ ssh -L 8001:192.168.64.2:80 <email address hidden>

Then hitting http://localhost:8001

Now, you have to do:
ssh -L 5240:192.168.64.2:5240 -L 8001:192.168.64.2:80 ubuntu@10.245.71.134
  and hit http://localhost:8001

or
ssh -L 5240:192.168.64.2:5240 ubuntu@10.245.71.134
  and hit http://localhost:5240

Note, that
 5240:<ip>:5240 is significantly less useful than ANYPORT:<ip>:80

[Christian Reis (kiko)]

This will affect any site that is accessing MAAS through a firewall with moderate restrictions; port 5240 isn't something web clients expect to need to use.

[Gavin Panella (allenap)]

We could mark maas-region-controller-min as conflicting with Apache (and anything else that services port 80 by default) and then run on port 80 directly. Twisted has support for binding low ports and then dropping privs, but we could also do it with authbind.

A point of perception: why are firewalls perceived as nigh-on impossible to change? In a reasonable world we could say "please open port 5240" but that possibility seems always to be dismissed without consideration.

Instead we're figuring out how to squash everything onto port 80, making our user's systems worse by pushing out Apache or Nginx or whatever was previously on port 80, or by adding an extra layer of indirection using, say, an Apache module to proxy long-lived websocket connections.

I understand that we can't change everyone's perception overnight, but I feel like I'm going mad when I read things like this: can no one else see the elephant?

[James Troup (elmo)]

Gavin Panella <email address hidden> writes:

> A point of perception: why are firewalls perceived as nigh-on impossible
> to change? In a reasonable world we could say "please open port 5240"
> but that possibility seems always to be dismissed without consideration.

Because in most companies firewalls are managed by a different team
(such as IS) and you have to submit a request and oh my god when did
that ever work for anyone...

--
James

[Blake Rouse (blake-rouse)]

This can be setup to proxy through apache with the websocket module, but it was the goal to remove apache and I know we don't want MAAS running on port 80 directly. I know many applications that you install and it runs on its own port. I don't see how this is an critical issue.

[Mike Pontillo (mpontillo)]

When a user points the browser to the MAAS UI, I think the expected behavior is that it *only hits the port you specify in the URL bar*. So the fact that we need a *second* port is the issue here. If we run on port 5240, that's fine, but if we also set up a convenience Apache proxy from port 80, we had better proxy *everything*, including the websockets.

As an aside, someone figured out the proper Apache configuration to work around this; see bug #1453764. (a minor change is needed to the MAAS code as well, so that we don't place data-websocket-port="5240" in the HTML)

[Mike Pontillo (mpontillo)]

I forgot: my other worry about this issue is, if someone sets up a reverse proxy (could be Apache, nginx, etc) for MAAS (for example, because they require the use of SSL/TLS), won't the websocket traffic that goes directly to port 5240 be cleartext rather than encrypted? If nothing else, *that* makes this issue critical.

[Blake Rouse (blake-rouse)]

You can use port 5240 directly instead of port 80 if you want on an installed MAAS. The only reason apache is still around is because of upgrades. I think the next LTS apache will be completely removed, and with MAAS being installed in a snap package its should be on its own port as well.

You are correct about the SSL, but I still don't fill this is critical. The login credentials are not sent over the websocket, only communication data.

[Mike Pontillo (mpontillo)]

This really has nothing to do with Apache, though. The fact is that reverse-proxying MAAS using *any* other port will have this problem. We need to remove the "special" data-websocket-port in the HTML and ensure everything flows over a single port, and fix anything that breaks resulting from that.

Respectfully disagree about the severity; I think mixing HTTP and non-HTTPS is a security nightmare waiting to happen. Don't we send BMC credentials over the websocket already? What about other sensitive data like cookies and/or authentication tokens? With 1.9+ I expect the severity will increase as more data flows over websockets.

[Raphaël Badin (rvb)]

> I know many applications that you install and it runs on its own port. I don't see how this is an critical issue.

I agree that it's generally fine for applications to run a dedicated port. What makes it a problem for MAAS is that previous versions of MAAS where using the port 80 for everything. If you upgrade, the UI is suddenly partly broken. This makes it a critical issue in my view. Additionally, MAAS is really a "backend" service and, as Scott points out, it's very common to access it through tunnels.

[Raphaël Badin (rvb)]

> You are correct about the SSL, but I still don't fill this is critical. The login credentials are not sent over the
> websocket, only communication data.

Mike is right: the websocket stream contains BMC credentials. This alone makes the issue critical.