Every design decision in Wormhole begins with the safety and privacy of your data in mind. We can't read your files, and no one else can either. Privacy isn’t an optional mode — it’s just the way that Wormhole works.
Your Wormhole files are end-to-end encrypted, and only you hold the keys to decrypt them. We can’t see your Wormhole files, so we can’t use them, share them, or sell them.
There are no ads and no creepy tracking in Wormhole. So focus on sharing the files that matter with the people who matter to you.
Your Wormhole files are end-to-end encrypted to keep them safe at rest and in transit. Our security starts with AES 128-bit encryption, and we use multiple techniques to make sure only you have access to your information. We're continuously working to make sure our code is rock solid.
Wormhole uses state-of-the-art security and end-to-end encryption to protect your files. Your files are always end-to-end encrypted, so they can never be shared or viewed by anyone but you and the intended recipients.
Wormhole encrypts all files with 128-bit AES-GCM encryption before they leave the browser.
The secret key used for end-to-end encryption is never shared with our servers. It is sent directly to your intended recipient when you send them the "share link". The secret key is added to the URI fragment which is never sent to the server.
When an agent (such as a web browser) requests a web resource from a web server, the agent sends the URI to the server, but does not send the fragment.
The link format looks like this:
Here's an example link:
For streaming encryption and decryption, we use Encrypted Content-Encoding for HTTP.
This standard provides authenticated encryption to ensure that your files can't be seen or modified by an attacker once they leave your browser.
We use the browser's built in cryptography primitives via the Web Crypto API to encrypt files in the browser before they are sent to the recipient.
End-to-end encrypted files may be:
A fully peer-to-peer transfer is preferred, since it improves speed and privacy. The server copy helps to ensure files continue to be available even after the sender closes their browser. All files are end-to-end encrypted before they are uploaded or sent peer-to-peer.
In addition to Wormhole's end-to-end encryption, your files are protected by an additional layer of encryption on our servers.
TLS (formerly known as SSL) is the industry-standard encryption protocol used to encrypt communications between your browser and our servers. It ensures that the Wormhole webpage code is not modified by attackers, and provides an additional layer of protection on top of the client-side end-to-end encryption to ensure data uploads and downloads are private.
We support TLS 1.3 for modern devices and TLS 1.2 for all remaining devices. Deprecated versions of TLS and SSL are not used.
Qualys SSL Labs rates our TLS implementation an A+. See report.
We monitor the Certificate Transparency logs for certificate misissuance.
A Certification Authority Authorization (CAA) policy allows a DNS domain name holder to specify the Certification Authorities (CAs) authorized to issue certificates for that domain.
By publishing a CAA record, we reduce the risk of unintended or malicious certificate misissuance.
DNSSEC is a set of extensions to DNS which provide to DNS clients (resolvers) cryptographic authentication of DNS data, authenticated denial of existence, and data integrity.
We deploy DNSSEC to protect DNS records for
DTLS is the standard encrypton protocol used to encrypt WebRTC peer-to-peer communications between browsers. It provides an additional layer of protection on top of our own encryption to keep peer-to-peer transfers on Wormhole private.
Wormhole is configured with state-of-the-art security options to lock down the site as much as possible.
Mozilla Observatory rates our site configuration an A+.
Here are a few of the security features we deploy.
Wormhole uses this header to ensure that your browser always communicates with our servers using the TLS protocol.
We additionally include
wormhole.app in all major browser's HTTP Strict Transport Security (HSTS) preload lists. In the case of
.app domains, the entire TLD is automatically included in the HSTS preload list.
Wormhole uses this header to prevent other origins from accessing data on
wormhole.app. This is a mitigation for side-channel hardware vulnerabilities such as Meltdown and Spectre.
Wormhole uses this header to enable cross-origin isolation. Cross-origin isolation ensures that supported browsers always load Wormhole in a separate renderer process, which protects against side-channel hardware vulnerabilities such as Meltdown and Spectre.
Wormhole uses this header to disable some web browser features that we don't need, like camera and microphone access.
Wormhole uses Content Security Policy to prevent the site from being tricked into accessing resources (such as scripts, webpages, etc.) that could be used in Cross Site Sripting attacks.
eval() function, browser plug-ins, active and passive HTTP content, clickjacking attacks,
<base> tag attacks,
<form> submissions to exfiltrate data, and more.
We plan to publish a more thorough explanation of the protocol in the coming weeks. For now, here's a high-level overview.
wormhole-crypto- Streaming encryption implementation, based on Encrypted Content-Encoding for HTTP (RFC 8188)
If you've found a security vulnerability in Wormhole, please report it using our Responsible Disclosure Process.