Portal protection for ENISA
no L7 termination for sensitive data

01Goal and principle

What we build and why. ENISA needs to protect its CRA portal and its data-submission site. We deliver a top-tier solution built on security-by-design.

02Traffic planes and three zones

We split traffic so that as little as possible — and as controlled as possible — reaches the sensitive part.

03Control layers — anycast POP and dedicated box

Every point has several layers (different HAProxy instances and other tools). On the box, one sticky table shares state across the whole box; Redis distributes it to other boxes and up to the edge.

04What happens to a request

Depending on the content type and the visitor state (unknown / OK / KO) the request goes elsewhere. Switch the scenario and follow the path and what happens.

05Login and bot detection

We send the request to the login portal together with a bot check — in the background, invisibly. The selection is selective by IP type.

06Multi-layer limits and rules

On every layer (anycast and dedicated) we can limit or block connection and access counts (including at L7) and other metrics, and apply rules accordingly.

07Block page (from CDN cache)

Example of the page a blocked visitor sees. Themed like our "origin down" pages: explanation, contact, a copyable request summary. Available in all official EU languages. WEDOS and ENISA logos.

https://portal.enisa.europa.eu/  ·  HTTP 429

Access temporarily restricted

Request blocked by WEDOS Global Protection

This request was temporarily blocked by attack protection. If you are an authorized user, please try again shortly, or sign in. If the problem persists, contact support and include the request summary below.

Request summary (copy for support)Copy

Ref:    a1b2c3d4-ee55-46f7-9a01-d3f2c7b18e90
Time:   2026-06-28 09:41:07 UTC
Reason: rate-limit / reputation
Node:   edge-anycast (LU)

Contact: soc@enisa.europa.eu  ·  wedos.com

BGESCSDADEETELENFRGAHRITLVLTHUMTNLPLPTROSKSLFISV

Available in all 24 official EU languages. The page is fully cached in the CDN — attacking it requires no origin resources.

Fig. 5 — Example block page served from CDN cache (WEDOS + ENISA logos, explanation, contact, copyable request summary, language selection).

08Profile and signals

The profile has two levels. The rich profile decides on the box (where we terminate). The thin key propagates downward — only from it can AL4/edge evaluate OK/KO.

09Propagation, latency and failure

State is written only by the terminating layer (ALB, after the auth result). AL4 and edge only read. The hot path always reads locally; the times below are for replication only — Redis is never in the synchronous path.

10Topology and failover — we recommend 3+ locations

We balance traffic across all dedicated locations (active/active). A failure of one = reduced capacity, not a service outage. With 3+ we can service one while another may simultaneously fail, and still keep running.

11Termination vs passthrough

The point where the lock opens is the TLS termination point = where WGP sees into the content. For the sensitive zone it opens only at the origin.

12Alternative: termination + E2EE payload (HPKE)

Proposed as an alternative / option to passthrough zone 3 (not a replacement). When ENISA wants full L7 protection on the sensitive flow together with a guarantee that we cannot read the content: we terminate TLS, but the request/response bodies are end-to-end encrypted with a key we never hold. In exchange for integrating client-side crypto into ENISA's application.

The client (JavaScript in the browser or a machine-to-machine client) wraps only the body in an HPKE envelope (RFC 9180) to the ENISA server's public key. Only the payload is encrypted, not the whole HTTP — structure, headers, sizes and JA4 stay readable to us for L7 protection. We terminate the outer TLS, see only ciphertext, and over the envelope we apply rate-limiting, bot detection, challenges and structural WAF (valid envelope format, max size) before the origin. The origin decrypts the envelope; its private key is in an HSM. Note: do not use nested TLS (TLS-in-TLS) — that would turn the body into opaque bytes and we would lose L7 protection. Only the payload is encrypted.

HPKE for humans and machines — one envelope, separate key acquisition

Yes, HPKE can be used for humans too. The data plane is one envelope for everyone; only how the client obtains the key and proves it is authorized differs. Confidentiality to the server is available to everyone — HPKE Base mode to the server's public key works even without a client key. Sender authentication (“authorized only”) is provided by Auth mode for anyone holding a client key; for password users it is replaced by an OPAQUE session.

Weakness: integrity of crypto-code delivery

In the browser, E2EE is only as strong as the integrity of the code that encrypts. Anyone who serves the page or can modify it could substitute crypto that sends the key or plaintext out. Because we terminate the outer TLS, we are structurally in a position to do this — so the guarantee against us is only as strong as the protection of code delivery. This is the well-known criticism of in-browser crypto (and of services like Mega). We address it in layers:

When passthrough and when E2EE

13Solution components

Components already in place and components that will be part of the solution.

14CRA alignment (EU 2024/2847)

The model is a direct security-by-design argument: in the sensitive zone WGP does not terminate → does not process content = data minimization and attack-surface reduction (Annex I).

15Our rules (specification)

Binding rules by which we build the solution. One point remains open for agreement (below).

16What we can protect (capability overview)

ENISA asked about captcha — yes, and it is just one tool among many. Below is an overview of the layers, signals and actions we can decide on. Everything is configurable per domain (Anygma profile) and freely combinable; not everything is enabled by default — the exact set is tuned per deployment.

Layers — where we decide

Signals and parameters (hundreds of combinations)

Limits — per dimension and in combination

We can limit and block per IP / ASN / country / continent / category / path and their combinations with JA4 / JA4T and other parameters. Metrics: connection count, concurrency, request count (L7), rate. That yields on the order of hundreds of possible rules per domain.

Actions — what we do with it

17Version history