Encryption in transit
Last updated: May 22, 2026
All our applications and services have industry-standard encryption in transit.
- The Fluid Attacks domain enforces TLSv1.3 end-to-end. Cloudflare proxies every zone in Strict mode: the edge verifies the origin certificate on every backend hop, so no leg of the connection falls back to plaintext or to an unverified upstream.
SSL configuration (retrieved from [SSL Labs](https://www.ssllabs.com))
- Origins authenticate Cloudflare cryptographically via Authenticated Origin Pulls (mTLS) using a private CA. TLS handshakes that don't present a leaf certificate signed by this CA are rejected at the TLS layer, before reaching the application.
- Every TLS handshake on the public data path negotiates the X25519MLKEM768 hybrid post-quantum key exchange (X25519 combined with NIST-standardized ML-KEM-768). The hybrid design closes the "harvest-now, decrypt-later" attack: a network observer who records today's handshake would have to break both the classical and the lattice-based component to recover the session key, even with a future quantum computer.
- All three primary zones (
fluidattacks.com,fluidattacks.tech,fluidattacks.org) are submitted to the browser-baked HSTS preload list, so modern browsers refuse plaintext HTTP to these zones on the first request, before any data leaves the device. Live status is exposed by the hstspreload.org public API: - Digital certificates for Fluid Attacks are renewed every 30 days in order to minimize leaks.
- We demand all connections to support at least TLSv1.2.
- Our platform's database uses TLSv1.2 for the protection of data in transit.
- We possess fully dedicated network channels with some of our biggest clients, allowing us to isolate all unwanted traffic. This is particularly useful for running secure dynamic application hacking.
- For the rest of our clients, we use fully encrypted VPNs.
- We maintain an SSL A+ score from SSL Labs. An updated report can be found in Fluid Attacks' profile.
SSL report (retrieved from [SSL Labs](https://www.ssllabs.com))
Data-path enforcement
Every hop of the public data path is gated by transport encryption and an explicit identity check on the receiving side:
| Hop | TLS | Key exchange | Origin authentication |
|---|---|---|---|
| Browser → Cloudflare | TLS 1.3 | X25519MLKEM768 | HSTS preload (first-contact) |
Cloudflare → ALB (app.*) | TLS 1.3 | X25519MLKEM768 | mTLS (AOP, private CA) |
Cloudflare → CloudFront (*.com) | TLS 1.3 | X25519MLKEM768 | mTLS (AOP, private CA) |
| ALB → backend pod | TLS 1.3 | X25519MLKEM768 | (VPC-internal) |
| CloudFront → S3 origin | TLS, SigV4 | (AWS-managed) | CloudFront OAC |
| CloudFront → Lambda Function URL | TLS, SigV4 | (AWS-managed) | CloudFront OAC |
Framework mapping
- PCI-DSS 4.0 Req 4.2.1 — strong cryptography for sensitive data in transit over open networks. Satisfied by the TLS 1.3 floor, Strict mode end-to-end, AOP mTLS at origins, and HSTS preload covering first-contact requests.
- SOC2 Trust Services Criterion CC6.7 — restriction of information transmission to authorized users and processes. Satisfied by the same controls, plus origin authentication that rejects non-Cloudflare traffic at the TLS layer before it reaches the application.
Requirements
- 092. Use externally signed certificates
- 147. Use pre-existent mechanisms
- 181. Transmit data using secure protocols
- 336. Disable insecure TLS versions
Other confidentiality measures
Encryption at rest
Fluid Attacks protects sensitive data using AES-256 GCM encryption, KMS-managed secrets, and full-disk encryption (BitLocker, LUKS, FileVault) in all devices.
No personal gain
Fluid Attacks prohibits the exploitation of discovered vulnerabilities for personal gain. It ensures confidentiality and integrity in all engagements.