Can now bind to ports other than 80/443, using the -http-port and
-https-port arguments.
Assuming you already have the certs you need, HTTPS even works.
Unfortunately you can't get the certs automatically because
LetsEncrypt doesn't support ports other than 80/443 as far as I
know.
TakingNames.io now provides bootstrap domains, which simply
creates an A record based off the ip address of the requesting
server, without requiring any authorization. This allows
boringproxy to always use HTTPS, even when getting the admin
domain.
The requests themselves now must be retrieve from the boringproxy
server by TakingNames.io, over HTTPS. This provides several
security benefits:
* You can tell the user the request is coming from a specific
domain.
* Requests are tied to an ephemeral request-id, to prevent
prebuilt phishing links.
There is currently a single hard-coded exception for setting a
single A record for an IP address. This is needed for
bootstrapping a service that doesn't have any certs yet (ie the
boringproxy admin domain), and will need to display a big scary
message to users.
When using TakingNames.io for getting a domain for a new tunnel,
previously it redirected to the public IP of the server over HTTP.
Now uses the admin domain over HTTPS.
The UI was originally written using fancy HTML checkbox toggle
hacks in order to make the UI very fast. It's cool but complicated
and difficult to change. In order to make updates to the UI more
quickly, I'm changing it to use traditional HTML with full page
reloads for navigation. It's not as fast but much simpler.
Now checks to make sure a domain isn't already used by a previous
tunnel. This prevents accidental silent modifications to tunnels
and also fixes a bug where multiple entries were being made in
the authorized_keys file.
Was writing both the old content of authorized_keys and the new
tunnel every time a tunnel was created. This essentially made the
file double in size for every new tunnel added.
This is useful for when you want to use boringproxy more like a
normal reverse proxy, ie if boringproxy and your service are on
the same machine, you can just use the port of the service as the
tunnel port and boringproxy will forward directly to it without
using SSH.
This would normally be used with no client set.
Choosing client "Any" is confusing, as it suggests any client
can connect to the tunnel. In reality this options means no client
can connect to the tunnel. Changed it to "No client" in the UI and
"none" in the database.
