This is just a quick heads' up to let everyone know we are still alive and kicking!
We are currently in the process of deploying new TLS certificates and a configuration update to the PageKite relays. This will involve restarts and will disconnect kites temporarily, but as usual we roll updates to servers during night-time hours in their respective time zones to minimize disruption.
Once this update is live, PageKite relays will listen on four new public ports: 465, 993, 995 and 1965. This brings the total set of public ports to 79, 80, 443, 465, 843, 993, 995, 1965, 2222, 3000, 4545, 5222, 5223, 5269, 5670, 6667, 8000, 8080, 8081, 8082, 8083, 9292, 25565.
The new ports are the defaults for TLS-secured e-mail protocols (SMTP submssion, IMAP and POP3), and the gemini project. Although technically you can run any end-to-end TLS-secured protocol over any port, we hope supporting the defaults will make it a little easier to use PageKite with these apps.
In all cases, clients must support the SNI TLS extension for things to work.
Note that PageKite does not natively support these protocols, but if you use end-to-end TLS tunnels, native support isn't necessary for things to work: PageKite sees a stream of TLS encrypted bytes and just relays them verbatim. End-to-end TLS is the most secure configuration anyway, so go forth and tunnel!
Also, note that when configuring your pagekite.py
, libpagekite
or upagekite
connector for end-to-end TLS tunneling, you must request the "https" kite protocol, even if you aren't actually running a web server. This is admittedly confusing, and we may attempt to address this oddity in future releases of our software.
These changes should all be live sometime after the weekend.
Welcome to the PageKite blog!
Here we write about anything and everything to do with running the service, building a company, open-source, privacy online... you name it.
But mostly it's about PageKite.
Comments