Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

move rendezvous server to port 80 or 443? #243

warner opened this issue Aug 4, 2017 · 8 comments

move rendezvous server to port 80 or 443? #243

warner opened this issue Aug 4, 2017 · 8 comments


Copy link

warner commented Aug 4, 2017

In #207 is kinda sounds like one user was unable to reach the rendezvous server because of a super-restrictive site-wide firewall. I probably made a mistake having the rendezvous server listen on port 4000 instead of 80 or 443 (my motivation was 1: the host I'm using for that server already has an unrelated web server on it, and 2: I'm unwilling to accept that the internet is so broken that the TCP port number space has been reduced from 65536 to 2).

But maybe I should accept that the internet is just broken, and ports 80 and 443 are the only usable ports anymore.

If so, then the tasks are:

  • move the rendezvous server to its own host (which requires a DNS flag-day swap)
  • run it as root, or with some trick that allows it to bind to low-numbered ports
  • have it listen on port 80 (in addition to the current port 4000)
  • update to set RENDEZVOUS_RELAY to use port 80
  • when we finish use TLS for the rendezvous connection #144, have it listen on port 443 too

To allow super-restrictive-firewalled clients to reach the transit relay too, the easiest approach is probably to put that relay on a separate server, and let it use port 443. The protocol it uses is not HTTP or TLS by a long shot, but maybe firewalls will let 443 through without trying to proxy it.

In the future, I want to add websocket access for the transit relay, to enable web-based clients and #9. I might be able to find a way to multiplex the current protocol with plain HTTP, but if not this will need a different port too. So the sequential migration from port 4001 to 443 to something else, leaving 80 or 443 available for a new protocol on the same host, may require some careful planning.

This should all probably wait until after we split out the servers to a separate repo (#240), which will let us run the rendezvous server on a different host than the transit relay (not necessary for performance or load or anything, but it'd make it easier to have them both use 80 or 443 without interfering with each other).

We could also run them on the same host, but use a multihomed host, and use one IP address (port 80) for the rendezvous server, and the other IP address (also port 80) for the transit relay.

To avoid a flag day for the DNS switchover, we could enhance the rendezvous server to be able to cooperate with other rendezvous servers (sharing their databases, or internally knowing which specific server owns which nameplate/mailbox and forwarding requests). Then we could bring up the new server on the new IP address, update DNS, use both servers while migration is happening, then tear down the old one once everyone has stopped using it.

Copy link

yae2 commented Aug 6, 2017

Maybe a protocol multiplexer might be useful in the short term? For example, if you wanted to host HTTPS and wormhole traffic on 443. Here's one multiplexer

Copy link

meejah commented Aug 6, 2017

You could probably steal some ideas from Crossbar's "universal" listener (which multiplexes between websockets, HTTP and Crossbar's 'raw socket' on one port). This is aided by the first byte sent in the 'raw socket' protocol isn't legal in HTTP/WebSocket at all so detection is easy:

Copy link

therealraven commented Jun 4, 2018

Perhaps using UDT would make it easier to use other ports (maybe only TCP is broken, not the whole internet).

Copy link

taigrr commented Nov 20, 2018

can you just use a virtual host and proxy through nginx? I feel like that's not hacky, or at least it's less hacky than other things mentioned here.

Copy link

con-f-use commented Mar 25, 2021

Is there any progress on this issue or a recommended workaround? I'm having exactly this problem, where a restrictive site firewall is blocking the relay server port. And none of the alternatives wormhole-william, croc, webwormhole, ... use ports 80 or 443.

Related issues for reference: #294 #288 #388

webwormhole, does use one of those ports and also works in the browser.

Copy link

Yeah, curious if the nginx/proxy work could be doable in a relatively short amount of time

Copy link

I came accross this issue because I was also having some firewall issues.
If you simply want to use 443 with TLS it's definitely working.
I made a rendezvous server and transit relay on my own with reverse proxy through traefik and it works super great.
The only issue I got now is that the wormhole cli does not seems to handle HTTPS_PROXY so even with 443 it's not passing.

Copy link

meejah commented Mar 24, 2023

The servers deployed by LeastAuthority for and Destiny (phone app) are running on HTTPS, so a workaround could be to use those servers. See the bottom of the FAQ, or use wss:// and tcp:// (and, bonus, there's a WebSocket transit too on wss://

Note that all participants must be using the same mailbox server to successfully communicate.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
None yet

No branches or pull requests

8 participants