Do you have a very specific network issue, specifically downstream packet loss as I encountered recently. Well then, here’s your guide to making browsing speedy again by setting up a Tinyproxy server that uses BBR to handle TCP congestion control.

1. Get a Server

You need a server, somewhere not on your network. It should run Linux (this guide assumes Ubuntu 24.04 but any distro should work. A small cloud VPS is perfect. You could probably do something like this on Windows or BSD but this guide is for Linux.

2. Set The Server To Use BBR

Easy, just load the kernel module and enable it.

modprobe tcp_bbr
sysctl -w net.ipv4.tcp_congestion_control=bbr

Note that this setting will reset if you reboot. Consider running this automatically with a SystemD service or something.

3. Install Tinyproxy

There’s a lot of HTTP proxy software, but this one is the easiest to setup.

apt install tinyproxy

Make sure it’s port (8888 be default) is open on whatever firewall you have.

4. Configure Tinyproxy

The config file is in /etc/tinyproxy/tinyproxy.conf. There’s a bunch of options, but you mainly need a single line:

Allow [Put your IP here, CIRD ranges are supported]

This allows incoming connections to your proxy. You can setup password authentication, but this breaks a lot of clients. Make sure to only use this proxy on networks you trust as anyone sniffing packets can easily find and use it.

5. Restart The Proxy

Load that beautiful new configuration

systemctl restart tinyproxy

(you could probably just reload it but I like to restart unless its actively being used)

6. Use It

Set whatever stuff you have to use the proxy. It should be on port 8888 at whatever IP your server uses. You can do fancy stuff with PAC files if you want to automate this.

7. Stop Using It

Proxies are kind of basic and can slow down browsing slightly, as they don’t support some of the nicer HTTP protocol stuff (like HTTP3). You’ll also get loads of CAPTCHAs from sites that detect proxies. Once your (hopefully transient) network issues are resolved go back to using the web normally.

Introduction

Encryption has become a vital tool for protecting data online. For protecting data in transit we have the now-ubiquitous HTTPS. For protecting data at rest we have a number of schemes for data encryption. However, for protecting web assets at rest there are very few options.

If one wants to serve data to a large number of clients, they generally have to use third-party services such as a CDN or a DDoS protection service. Cloud services are able to see the data that is being stored and served.

This poses a problem for anyone handling sensitive or confidential information. That is why we have developed a solution.

ObscuroWeb — Functional Overview

The person setting up the website encrypts the HTML files, as well as any other assets, and publishes them somewhere accessible on the web. Then, they create another page which contains a loader and decryption key. The loader will download, decrypt, and display the page. While the page and assets may be on a number of CDNs or cloud servers, the actual key is only accessible in a particular place. The key might also be fetched from an API or from the user’s own browser storage.

Potential Use Cases

An organization may host an internal newsletter with sensitive information on a server that resides on premises. With ObscuroWeb, they could move the newsletter to a cloud-based CDN and host only the loader and decryption key on the server. This would reduce server load and possibly speed up the page loads.

Someone dealing with sensitive records could store them in an S3 bucket, but restrict access using the loader and a system to lock the key behind some form of authentication.

Drawbacks and Limitations

• Decryption can be slow.
• Decryption might use more battery.
• There is no effort made to verify assets that are downloaded, except that they were encrypted with the key used.
• A lot of memory is used as multiple copies of the data must exist in full simultaneously.
• If the key is publicly available, the privacy benefits are negligible.
• Keys cannot be easily changed, as all assets have to be re-encrypted and re-uploaded. The loader must also be re-configured with the new key. This will almost inevitably cause a disruption in service.
• Any attempts to apply compression to the files as they are being transferred (i.e. Brotli, GZip) will be either of no benefit or actively counterproductive.
• Webpage loading is somewhat ugly, as there is a delay for content to load.
• Websites using JavaScript will need to be redesigned somewhat, as updating an entire page at once will not run the scrips present on the new page.

Demo

A demonstration is available on JimmyNet: https://jimmyhoke.net/obscurowebdemo

Conclusion

ObscuroWeb shows how you can, with just a few lines of JavaScript and libsodium, dynamically load and decrypt web resources.