Neither Visslan nor AWS can see any reports of Visslan’s customers, thanks to Visslan’s data encryption schema.
The Visslan software aims to adhere to industry-standard best practices, with its security being the result of applied research.
This document details every aspect implemented by the application in relation to security design.
The software comprises two main components: a Backend and a Client:
Users' anonymity is protected by means of Tor technology.
The application is designed to avoid logging sensitive metadata that could lead to the identification of whistleblowers.
This section highlights various threats that require specific consideration.
Visslan uses crafted HTTP headers and other techniques to minimize leaking information into a user’s browser history or cache. While this privacy feature enhances safety, it cannot guarantee protection against forensic analysis of browser cache and history but serves as an additional safety measure.
Files may contain metadata related to the author or whistleblower. Cleaning metadata from submitted files helps protect an “unaware” whistleblower from inadvertently including information that may compromise their anonymity. Visslan does not automatically clean metadata by default, as metadata is considered a fundamental part of the original evidence that should be preserved. Metadata cleanup is an optional step that may be suggested to Whistleblowers or performed by Recipients when sharing documents with others. When sharing files with external parties, Recipients are advised to print the document and provide a hard copy to ensure that only visible information is shared, avoiding the risk of sharing sensitive metadata. For more on metadata and redacting digital files, see the article Everything you wanted to know about media metadata, but were afraid to ask by Harlo Holmes. A useful tool for these procedures is the Metadata Anonymization Toolkit.
Visslan cannot prevent an attacker from using the platform maliciously to target recipients with malware or trojans. To mitigate risks of data exfiltration through trojans, Recipients should implement proper operational security by using dedicated laptops for report viewing and opening file attachments on offline computers. Wherever possible, they should use specialized secure operating systems like QubesOS or Tails and ensure up-to-date antivirus software is running.
Visslan is designed for use with direct Tor or TLS connections from the user’s browser to the application backend. The use of Network and Reverse Proxies in front of the application is discouraged as they can interfere with the application and compromise confidentiality and anonymity measures implemented in Visslan.
Visslan does not provide security for data stored outside the Visslan system. It is the responsibility of Recipients to protect data downloaded from the platform or shared via external USB drives. The operating system used or the USB drive should offer encryption to ensure that, in case of device loss or theft, the data remains inaccessible.
Visslan does not protect against environmental factors related to users’ physical locations or social relationships. For example, if a user has a surveillance device in their home, Visslan cannot provide protection. Similarly, if a whistleblower, who is supposed to be anonymous, shares their story with friends or coworkers, Visslan cannot offer protection.
Visslan implements a strict default data retention policy of 90 days to allow users to manage reports within a limited time frame necessary for investigations. If the platform is configured to retain reports for an extended period and Recipients do not manually delete unnecessary reports, the value of the data increases, along with the risk of exposure.
While Visslan provides Administrators with the ability to fine-tune security configurations and continuously informs users about their security context, it cannot protect against major security threats resulting from human negligence. For instance, if a Whistleblower submits data that can identify them as the unique owner or recent viewer, Visslan cannot protect their identity.
An attacker monitoring HTTPS traffic, without the ability to decrypt it, can still identify user roles based on different network traffic patterns generated by Whistleblowers, Recipients, and Administrators. Visslan does not offer protection against this type of threat. We recommend using Tor pluggable transports or other methods that provide additional protection against such attacks.
The confidentiality of authentication is protected either by Tor Onion Services v3 or TLS version 1.2+.
This section describes the authentication methods implemented by the system.
By accessing the login web interface, Administrators and Recipients need to enter their respective Username and Password. If the submitted password is valid, the system grants access to the functionality available to that user.
Whistleblowers access their Reports using an anonymous Receipt, which is a randomly generated 16-digit sequence created by the Backend when the Report is first submitted. This format resembles a standard phone number, making it easier for whistleblowers to conceal their receipts.
The system implements the following password security measures:
Passwords are never stored on the server either in plaintext or in form on hash; instead, the system maintains only the hash of of a key derived from the user password.
Passwords are hashed using Argon2 with a configuration of 16 iterations and 128MB of RAM, a per-user salt for each user and a per-system salt for whistleblowers.
The hashing algorithm used to compute the key hash is SHA256.
The system enforces complex passwords by implementing a custom algorithm necessary to ensure reasonable entropy for each authentication secret.
Passwords are scored at three levels: Strong, Acceptable, and Insecure.
We encourage each end user to use KeePassXC to generate and retain strong, unique passphrases.
The system implements Two-Factor Authentication (2FA) based on TOTP using the RFC 6238 algorithm and 160-bit secrets.
Users can enroll in 2FA via their own preferences, and administrators can optionally enforce this requirement.
We recommend using FreeOTP, available for Android and for iOS.
The system identifies multiple failed login attempts and implements a slowdown procedure, requiring an authenticating client to wait up to 42 seconds to complete an authentication.
This feature is intended to slow down potential attacks, requiring more resources in terms of time, computation, and memory.
Visslan enforces users to change their password at their first login.
Visslan can also enforce a password change for users at their next login.
By default, the system enforces users to change their password at least every year.
This period is configurable by administrators.
In case of a lost password, users can request a password reset via the web login interface by clicking on a Forgot password? button present on the login page.
When this button is clicked, users are invited to enter their username or email. If the provided username or email corresponds to an existing user, the system will send a reset link to the configured email.
By clicking the link received by email, the user is then invited to set a new password different from the previous one.
If encryption is enabled on the system, a user clicking on the reset link must first enter their Account Recovery Key. Only after correct entry will the user be able to set a new password.
This section describes the Web Application Security implemented by the software in adherence to the OWASP Security Guidelines.
The session implementation follows the OWASP Session Management Cheat Sheet security guidelines.
The system assigns a session to each authenticated user. The Session ID is a 256-bit long secret generated randomly by the backend. Each session expires according to a timeout of 30 minutes. Session IDs are exchanged between the client and the backend via a header (X-Session) and expire as soon as users close their browser or the tab running Visslan. Users can explicitly log out via a logout button or implicitly by closing the browser.
To minimize the exposure of users' encryption keys, the keys are stored in an encrypted format and decrypted only upon each client request.
The implementation uses Libsodium’s SecretBox, where the client’s session key is used as the secret. Only the client maintains a copy of the session key, while the server retains only a SHA-256 hash.
Cookies are not used intentionally to minimize XSRF attacks and any possible attacks based on them. Instead of using cookies, authentication is based on a custom HTTP Session Header sent by the client on authenticated requests.
The system implements a large set of HTTP headers specifically configured to improve software security and achieves a score A+ by Security Headers and a score A+ by Mozilla Observatory.
The system implements strict transport security by default:
Strict-Transport-Security: max-age=31536000; includeSubDomains; preloadThe default configuration of the application sees this feature disabled.
The backend implements a strict Content Security Policy (CSP) preventing any interaction with third-party resources and restricting execution of code by means of Trusted Types:
Content-Security-Policy: base-uri 'none'; connect-src 'self'; default-src 'none'; font-src 'self'; form-action 'none'; frame-ancestors 'none'; frame-src 'self'; img-src 'self'; media-src 'self'; script-src 'self' 'report-sample'; style-src 'self'; trusted-types angular angular#bundler default dompurify; require-trusted-types-for 'script'; report-uri /api/report;Specific policies are implemented in adherence to the principle of least privilege.
For example:
The application implements a dedicated API handler /api/report to receive and log samples of attempts of violations of the content security policy.
The backend implements the following Cross-Origin-Embedder-Policy (COEP):
Cross-Origin-Embedder-Policy: require-corpThe backend implements the following Cross-Origin-Opener-Policy (COOP):
Cross-Origin-Opener-Policy: same-originThe backend implements the following Cross-Origin-Resource-Policy (CORP):
Cross-Origin-Resource-Policy: same-originThe backend implements the following Permissions-Policy header configuration to limit the possible de-anonymization of the user by disabling dangerous browser features: :
Permissions-Policy: accelerometer=(),ambient-light-sensor=(),bluetooth=(),camera=(),clipboard-read=(),clipboard-write=(),document-domain=(),display-capture=(),fullscreen=(),geolocation=(),gyroscope=(),idle-detection=(),keyboard-map=(),local-fonts=(),magnetometer=(),microphone=(" + (b"self" if microphone else b"") + b"),midi=(),notifications=(),payment=(),payment-request=(),persistent-storage=(),push=(),screen-wake-lock=(),serial=(),speaker-selection=(),usb=(),web-share=(),xr-spatial-tracking=()In addition to implementing Content Security Policy level 3 to prevent the application from being included in an iframe, the backend also implements the outdated X-Frame-Options header to ensure that iframes are always prevented in any circumstance, including on outdated browsers:
X-Frame-Options: denyWeb browsers usually attach referrers in their HTTP headers as they browse links. The platform enforces a referrer policy to avoid this behavior:
Referrer-Policy: no-referrerTo avoid automatic MIME type detection by the browser when setting the Content-Type for specific output, the following header is used: :
X-Content-Type-Options: nosniffTo prevent or limit forensic traces left on devices used by
whistleblowers and in devices involved in communication with the
platform, as specified in section
3. Storing Responses in Caches of RFC 7234, the platform
uses the Cache-Control HTTP header with the configuration
no-store to instruct clients and possible network proxies
to disable any form of data caching:
Cache-Control: no-storeFor security reasons, the backend instructs crawlers to avoid caching
and indexing of the application and uses the robots.txt
file to allow crawling only of the home page. Indexing the home page is
considered best practice to promote the platform's existence and
facilitate access for potential whistleblowers.
The implemented configuration is as follows: :
User-agent: *
Allow: /$
Disallow: *The platform also instructs crawlers to avoid caching by injecting the following HTTP header: :
X-Robots-Tag: noarchiveFor highly sensitive projects where the platform is intended to
remain hidden and communicated to potential whistleblowers
directly, it can be configured to disable indexing completely.
In such cases, the following HTTP header is used: :
X-Robots-Tag: noindexThe client opens external URLs in a new tab, independent of the
application context, by setting target='_blank'` on remote
or untrusted anchor tag:
<a href="url" target="_blank">link title</a>The application implements strict input validation both on the backend and on the client.
Each client request is strictly validated by the backend against a set of regular expressions, and only requests matching the expressions are processed.
Additionally, a set of rules is applied to each request type to limit potential attacks. For example, any request is limited to a payload of 1MB.
Each server output is strictly validated by the client at rendering time using the Angular component ngSanitize.$sanitize.
Few configurations accepts Markdown input and every input is strictly validated stripping every HTML tag with DOMPurify
Forms implemented by the platform use the HTML5 form attribute to instruct the browser not to cache user data for form prediction and autocomplete on subsequent submissions.
This is achieved by setting autocomplete="off" on the relevant forms or attributes.
User anonymity is provided through the implementation of Tor technology. The application
implements an Onion Service v3 and advises users to use the
Tor Browser when accessing it. This is not Visslan’s default
however.
User connections are always encrypted, either through the Tor Protocol when using the Tor Browser or via TLS when accessed through a common browser.
Using Tor is recommended over HTTPS due to its advanced
resistance to selective interception and censorship, making it difficult
for a third party to capture or block access to the site for specific
whistleblowers or departments.
The software also facilitates easy setup of HTTPS,
offering both automatic setup via Let's Encrypt and manual
configuration.
TLS certificates are generated using NIST Curve P-384.
The configuration enables only TLS1.2+ and is fine-tuned
and hardened to achieve SSLLabs
grade A+.
In particular, only the following ciphers are enabled: :
TLS13-AES-256-GCM-SHA384
TLS13-CHACHA20-POLY1305-SHA256
TLS13-AES-128-GCM-SHA256
ECDHE-ECDSA-AES256-GCM-SHA384
ECDHE-RSA-AES256-GCM-SHA384
ECDHE-ECDSA-CHACHA20-POLY1305
ECDHE-RSA-CHACHA20-POLY1305
ECDHE-ECDSA-AES128-GCM-SHA256
ECDHE-RSA-AES128-GCM-SHA256The Visslan backend integrates iptables by default and implements strict firewall rules that restrict incoming network connections to HTTP and HTTPS on ports 80 and 443.
Additionally, the application allows anonymizing outgoing connections, which can be configured to route through Tor.
Submission data, file attachments, messages, and metadata exchanged
between whistleblowers and recipients are encrypted using the Visslan
EncryptionProtocol(see below).
Visslan also incorporates various other encryption components. The main libraries and their uses are:
`PGP`The Visslan backend integrates AppArmor by default and implements a strict sandboxing profile, allowing the application to access only the strictly required files. Additionally, the application runs under a dedicated user and group "Visslan" with reduced privileges.
The Visslan backend uses a hardened local SQLite database accessed via SQLAlchemy ORM.
This design choice ensures the application can fully control its configuration while implementing extensive security measures in adherence to the security recommendations by SQLite.
The Visslan backend enables SQLite’s secure deletion capability, which automatically overwrites the database data upon each delete query:
PRAGMA secure_delete = ONThe platform enables SQLite’s auto vacuum capability for automatic cleanup of deleted entries and recall of unused pages: :
PRAGMA auto_vacuum = FULLThe Visslan backend uses the SQLite trusted_schema pragma to limit trust in the database, mitigating risks of malicious corruption:
PRAGMA trusted_schema = OFFThe Visslan backend restricts SQLite functionalities to only those necessary for running the application, reducing the potential for exploitation in case of SQL injection attacks.
This is implemented using the `conn.set_authorizer` API
and a strict authorizer callback that authorizes only a limited set of
SQL instructions: :
SQLITE_FUNCTION: count, lower, min, max
SQLITE_INSERT
SQLITE_READ
SQLITE_SELECT
SQLITE_TRANSACTION
SQLITE_UPDATETo mitigate denial of service attacks, Visslan applies the following measures:
The system implements an automatic Proof of Work based on the hashcash algorithm for every user session, requiring clients to request a token and continuously solve a computational problem to acquire and renew thesession.
Specifically the algorithm used to perform the hash is Argon2id with requirement of 1 iteration and 1MB of RAM.
The system implements rate limiting on user sessions, preventing more than 5 requests per second and applying increasing delays on requests that exceed this threshold.
The system applies rate limiting on whistleblower reports and attachments, preventing new submissions and file uploads if thresholds are exceeded.
Implemented thresholds are:
| Threshold Variable | Goal | Default Threshold Setting |
|---|---|---|
| threshold_reports_per_hour | Limit the number of reports that can be filed per hour | 20 |
| threshold_reports_per_hour_per_ip | Limit the number of reports that can be filed per hour by the same IP address | 5 |
| threshold_attachments_per_hour_per_ip | Limit the number of attachments that can be uploaded per hour by the same IP address | 120 |
| threshold_attachments_per_hour_per_report | Limit the number of attachments that can be uploaded per hour on a report | 30 |
The entire application is designed to minimize or reduce the forensic traces left by whistleblowers on their devices while filing reports.
When accessed via the Tor Browser, the browser ensures that no persistent traces are left on the user’s device.
To prevent or limit forensic traces in the browser history of users accessing the platform via a common browser, the application avoids changing the URI during whistleblower navigation. This prevents the browser from logging user activities and offers high plausible deniability, making the whistleblower appear as a simple visitor to the homepage and avoiding evidence of any submission.
Any attachment uploaded by anonymous whistleblowers might contain malware, either intentionally or not. It is highly recommended, if possible, to download files and access them on an air-gapped machine disconnected from the network and other sensitive devices. To facilitate safe file downloads and transfers using a USB stick, the application provides the option to export reports, enabling the download of a ZIP archive containing all report content. This reduces the risk of executing files during the transfer process.
The application offers an integrated file viewer. This viewer, leveraging modern browser sandboxing capabilities, allows the safe opening of a limited set of file types considered more secure than accessing files directly through the operating system. This feature is enabled by default.
The supported file formats are:
The system offers an optional PGP encryption feature.
When enabled, users can activate a personal PGP key that will be used by the system to encrypt email notifications and files on-the-fly.
This feature is recommended for high-risk threat models, especially when used in conjunction with air-gapped systems for report visualization.
The default configuration has this feature disabled, but it can be enabled by Visslan upon request.
Files uploaded and temporarily stored on disk during the upload process are encrypted with a ChaCha20 and temporary 256bit keys to prevent any unencrypted data from being written to disks. Key files are stored in memory and are unique for each file being uploaded.
Every file deleted by the application is overwritten before the file space is released on disk.
The overwrite routine is executed by a periodic scheduler and follows these steps:
To quickly diagnose potential software issues when client exceptions occur, they are automatically reported to the backend. The backend temporarily caches these exceptions and sends them to the backend administrator via email.
To prevent inadvertent information leaks, logs are processed through filters that redact email addresses and UUIDs.
The primary source of entropy for the platform is /dev/urandom.
System resources like submissions and files are identified by UUIDv4 to make them unguessable by external users and limit potential attacks.
All notifications are sent through an SMTP channel encrypted with TLS, using either SMTP/TLS or SMTPS, depending on the configuration.
Visslan implements an encryption protocol specifically designed for anonymous whistleblowing applications.
The protocol has been developed and validated in collaboration with the Open Technology Fund and represents a trade-off between security and usability. It is designed to be user-friendly for whistleblowers while providing reasonable protection against attackers attempting to breach the backend and perform brute-force decryption.
Encryption is applied to each submission, protecting answers to questionnaires, comments, attachments, and associated metadata. The encryption keys are assigned per user and per report, ensuring that only whistleblowers and their intended recipients can access the reports. This means that if users forget their passwords, they will lose access to the data in their accounts.
To enable users to recover their accounts in case they forget their passwords, the system includes a Key Recovery mechanism and provides each user with an Account Recovery Key. This measure ensures that users with their own Account Recovery Key can always restore access to their account and the data it contains.
To prevent data loss in case users lose both their password and their account recovery key, the system is configured to use a Key Escrow mechanism. This enables administrators to support users in recovering access to their accounts. This capability enhances the project's resilience against data loss due to users' death or conflicts of interest within the recipient team.
| Type | Implementation |
|---|---|
| Asymmetric encryption | Libsodium SealedBoxes, which combines Curve25519, XSalsa20, and Poly1305 algorithms. |
| Symmetric encryption | Libsodium SecretBoxes, which combines XSalsa20 and Poly1305. |
The system uses two types of credentials depending on the user role:
| Credentials type | User role |
|---|---|
| Passwords | Used for authenticating users identified by a username |
| Receipts | 16-digit random secrets used for authenticating anonymous whistleblowers |
Assumptions:
| Type | Generation | Storage |
|---|---|---|
| ECC Curve25519 keypair | Generated by the backend during first user login for authenticated users and upon submission for whistleblowers. | Keys are stored on the backend encrypted using symmetric encryption. The symmetric key used for encrypting users’ keys is derived from the users’ credentials using the KDF function Argon2ID. The parameters for Argon2ID used for KDF are stronger than those used for user authentication, with the hash stored. The parameters are selected to require 128MB of memory per login and 1 second of computation. |
| Type | Generation | Storage |
|---|---|---|
| 256-bit keys | Generated by the backend for each report | Keys are stored on the backend filesystem encrypted using asymmetric encryption with Users’ and Whistleblower’s keys, respectively. |
Users' encryption keys are automatically generated during the first login and secured using the user passphrase. This straightforward but effective key generation policy requires users to complete their first login before being able to receive reports.
The system implements a key recovery mechanism using a recovery key and symmetric encryption.
When a user key is generated, the private key is symmetrically encrypted with a randomly generated recovery key.
For usability reasons, this recovery key is also securely encrypted and stored on the backend, allowing logged-in users who possess their password to retrieve and print their own account recovery key.
The system implements a key escrow mechanism to mitigate data loss in the event of users losing their passwords.
This enables protection of whistleblowers' submissions in cases where recipients lose their passwords.
The system generates and assigns an escrow key to the administrator (Visslan). This key is then used to encrypt every system key, with a copy preserved that the administrator can unlock with the escrow key.
Visslan can assist internal users with password recovery and issue password resets.