the fast, reliable localhost tunneling solution

Sharing Files and Folders Securely

By Bjarni RĂșnar Einarsson 2012-11-21, 17:40

The program comes with a built in HTTP server which can be used to test static websites, or simply share files and folders over the web.

This how-to will briefly discuss how to use the built in server to share files and how to balance security vs. usability to suit different situations.


The main advantages to using PageKite for distributing sensitive data, is that the recipients do not need any particular tools aside from a modern web browser. Since the files are never stored "in the cloud", the privacy and confidentiality of the transmission can be tuned to suit even the strictest security policies.

By streaming files on-demand to the intended recipients, the risk of leaks or accidental or malicious disclosure is lowered significantly: the potential window of attack is limited to only the time when PageKite is actually running and connected. By further using PageKite's built in URL obfuscation, passwords and encryption features security can be boosted even further.

Basic file sharing

Sharing a single file can be done from the command line, like so: /path/to/filename

This will make the file available for download on the path: (it will also be available on the equivalent unencrypted http:// path).

You can also share multiple files at once, by naming them one-by one or by using the shell's wildcard expansion:

# Share multiple files file1.txt file2.txt file3.txt

# Share all HTML files from a folder /some/folder/*.html

Finally, you can share the contents of an entire directory (folder), including sub-directories, just by naming it. If you add the +indexes flag, people will be able to easily browse the contents:

# No browsing, but shares all contents /path/to/folder

# Browsing enabled (directory indexes) /path/to/folder +indexes

Access controls

Access to the shared files can be restricted in various ways.

The most basic, is to simply give the files hard-to-guess URLs. PageKite can do this for you, if you use the +hide flag:

# Generate randomized URLs /path/to/stuff +hide

This will generate a random 9-character prefix for each shared directory.

You can also require a username and password for access, or only accept connections from specific IP-addresses or /24 netblocks:

# Require username and password /path/to/stuff +user/NAME=PASS

# Restrict by IP address or network block /path/to/stuff +ip/ /path/to/stuff +ip/4.5.6

All of the above can of course be combined, and you can specify multiple usernames or multiple IP addresses to grant access to by adding more flags.

Note: Be advised that the IP-based restrictions are based on information provided by the front-end relay server, which could potentially be forged. If you do not trust the person running your front-end relay or suspect they may have been compromised, you should not rely on IP-based access controls alone.

Automatic * encryption

If you are using the PageKite service and sharing files using a kite name ending in, you will automatically be able to use secure HTTPS URLs for your shared files. This method is compatible with all browsers and should protect you from casual eavesdropping on shared public WiFi or by most Internet providers.

This encryption has a couple of limitations:

End-to-end encryption

If you are using an untrusted front-end relay, or simply want to guarantee you are communicating in the most secure manner possible, it is possible to use end-to-end HTTPS encryption with PageKite. This will guarantee that no intermediaries, including the operators of the front-end relay servers, will be able to listen in on your communications.

In order to make use of end-to-end HTTPS encryption, you will need an SSL certificate for your kite's domain. In this how-to we will only discuss self-signed certificates, as they can be obtained for free and are, when used properly, the most secure type of certificate.

As of version 0.5.4, can generate a self-signed certificate for you (assuming the openssl tool is installed on your computer), making this a relatively straightforward process:

# Share files with a self-signed certificate --selfsign /path/to/files

Compared to the above examples, there are two differences: one is the --selfsign argument, which must be first, and the second is the https: prefix on the kite name. The first time you run this command, the output will look something like this:

Self Signing Screenshot

On subsequent runs, the program will re-use the generated certificate (until you delete the .pagekite.pem file).

For maximum security, combine this with the access controls discussed above and turn the program off when you are finished exchanging files.



  1. Tyeth Gundry said on 2017-02-17, 15:23
    LetsEncrypt offer free ssl certificates (verisign backed).

    Keep up the good work

Leave a comment

( (Please leave these blank: )

We use Gravatar for commenter's photos. Get your own, it's free!