cryptostorm blog

Fully post-quantum OpenVPN (without OpenSSH tunneling)

Fri, 26 Jun 2026 18:30:16 -0500

Introduction/TLDR
Post-quantum key exchanges in OpenVPN
Windows client v4

Introduction/TLDR

In our post-quantum OpenVPN post, we said:

For true post-quantum security, the key exchange would also need a PQC algorithm (like ML-KEM). We will have to wait for OpenVPN to officially add support for those before we can use them.

OpenVPN added PQC support in version 2.7.0, so if you have that (or newer) and OpenSSL 3.5.0 (or newer) then a hybrid post-quantum TLS key exchange will be used when you connect to cryptostorm. That means the gap mentioned in the older post is closed for clients using a recent enough OpenVPN/OpenSSL.

You can see it in the OpenVPN log at:

Control Channel: TLSv1.3, cipher TLSv1.3 TLS_CHACHA20_POLY1305_SHA256, peer certificate: 521 bits ECsecp521r1, signature: ecdsa-with-SHA512, peer signing digest/type: ecdsa_secp521r1_sha512 ECDSA, key agreement: X25519MLKEM768

That X25519MLKEM768 part means the TLS key exchange is using a hybrid of the classical X25519 ECDH algorithm and the post-quantum ML-KEM-768 algorithm.

The short version is: our ML-DSA-87 OpenVPN instances now have post-quantum authentication and a post-quantum hybrid key exchange. The secp521r1, Ed25519, Ed448, and RSA instances can also use the same hybrid key exchange when the client's OpenVPN/OpenSSL is new enough, though their certificate/authentication side is still whatever that instance uses.

Post-quantum key exchanges in OpenVPN

The previous post-quantum OpenVPN post was mostly about ML-DSA-87 certificates. That was useful because it meant the server authentication side could use a post-quantum signature algorithm, but the TLS key exchange was still classical.

OpenSSL 3.5 added support for PQC algorithms like ML-KEM, ML-DSA, and SLH-DSA, and its default TLS keyshares include X25519MLKEM768. OpenVPN 2.7.x can make use of that when it is built against a new enough OpenSSL.

That matters because the key exchange is the part that agrees on the temporary symmetric keys used for the VPN session. With X25519MLKEM768, an attacker would have to break both sides of the hybrid agreement to recover the key exchange: the classical X25519 side and the ML-KEM-768 side.

The data channel is still encrypted with normal symmetric ciphers like AES-256-GCM or ChaCha20-Poly1305, depending on the instance/client settings. That is fine; post-quantum VPN work is mostly about replacing the asymmetric parts first, because those are the parts Shor's algorithm threatens. AES-256 still has a large security margin even in the usual Grover's algorithm discussion.

Windows client v4

We also rewrote our Windows client.

The old "widget" did its job for a long time, but it started as a single Perl script and slowly accumulated years of fixes, feature additions, Windows compatibility workarounds, and UI tweaks. The new one is still Perl/Tkx, but the code has been split into smaller modules and most of the client-side logic was rewritten.

The visible changes are the ones most users will care about:

newer server selection UI;
newer OpenVPN/OpenSSL builds, so the client can use the hybrid post-quantum key exchange described above;
Xray/REALITY support, so OpenVPN UDP or TCP can be wrapped in something that looks much closer to normal HTTPS traffic;
the stunnel HTTPS and SSH tunneling are still there for networks where those work better;
better TAP adapter handling, and updated TAP drivers for Windows 7 and newer Windows systems;
a more careful killswitch and IPv6 leak-blocking path;
no more bundled DNSCrypt since the client doesn't use DNS anymore;
DNS leak protection, ad-blocking DNS, and TunnelCrack protection options;
more translations (English, Japanese, Swedish, Italian, Russian, Chinese, Persian, Arabic, German, French, Dutch, Finnish, and Spanish) and a new language selection UI on the main window;
post-connect checks for client updates and server-list updates.

Xray is probably the biggest transport change. Our older HTTPS obfuscation used stunnel, which works for TCP OpenVPN but doesn't help with UDP OpenVPN or WireGuard. Xray/REALITY can carry UDP or TCP payloads through a TLS-looking outer connection, which makes it a better fit for the current network setup described in the Xray post.

This client currently uses the latest OpenVPN TAP drivers. DCO support, and possibly WireGuard support, will come later. For now the goal was to get the new OpenVPN/OpenSSL/Xray stack working across the widest set of Windows systems we still care about, including Windows 7 32-bit.

The Windows client download is at https://cryptostorm.is/windows#widget.

The source code is at https://github.com/cryptostorm/cstorm_widget.

DNS over HTTPS

Wed, 29 Apr 2026 00:43:27 -0500

Introduction
Instructions
Age verification laws and other bad ideas
Other news

Introduction

We've added public DNS-over-HTTPS endpoints to the network.

DNS-over-HTTPS, usually shortened to DoH, is exactly what it sounds like: DNS queries sent through HTTPS instead of the usual plaintext DNS protocol. In plain terms, that means the part of your browser that asks "what IP does this domain point to?" can be sent inside the same kind of encrypted HTTPS connection your browser already uses for websites.

This does not make a browser private by itself. It does not fix canvas fingerprinting, WebGL fingerprinting, timezone leaks, language/header uniqueness, geolocation APIs, bad extensions, hostile JavaScript, or all the other browser-shaped garbage that gets used for tracking. It only changes how DNS lookups are done.

But DNS still matters. Plain DNS is easy for ISPs, captive portals, schools, workplaces, public WiFi networks, and national firewalls to log, redirect, poison, block, or otherwise tamper with. DoH wraps those lookups in HTTPS, so on the wire it looks like ordinary HTTPS traffic to the DoH hostname. That's useful on networks where DNS is being manipulated, and it's also useful in browsers because it can prevent browser-side DNS leaks where the browser or one of its APIs would otherwise resolve names outside the VPN/DNS path you expected.

The endpoints are:

Ad/tracker-blocking:
https://public.deepdns.net/dns-query-ts
https://cryptostorm.is/dns-query-ts
https://cryptostorm.nu/dns-query-ts
https://SERVER.cstorm.is/dns-query-ts

Unfiltered:
https://public.deepdns.net/dns-query
https://cryptostorm.is/dns-query
https://cryptostorm.nu/dns-query
https://SERVER.cstorm.is/dns-query

Replace SERVER with any of the hostnames listed at the bottom of https://cryptostorm.is/wireguard or in https://cryptostorm.nu/nodes.txt, such as paris.cstorm.is, austria.cstorm.is, belgium.cstorm.is, etc.

There are also additional DoH-capable hostnames in the OpenVPN configs generated at https://cryptostorm.is/configs/ and in the configs on GitHub at https://github.com/cryptostorm/conf/. We're not listing them directly here because in some places DNS censorship (probably) is done by crawling public pages like this one, then feeding the discovered domains into blocklists. If the obvious endpoints get blocked somewhere, the less-obvious hostnames in the configs may still work.

The /dns-query endpoint is the normal unfiltered resolver. The /dns-query-ts endpoint goes to a different resolver that blocks ad/tracker hosts using the Pro++ list from HaGeZi's DNS blocklists.

If something breaks, use the unfiltered endpoints. DNS-based blocking is useful, but DNS blocklists are blunt instruments. Some sites load login pages, payment processors, videos, comments, or images from domains that also appear on tracking lists. That's the tradeoff. Using both DNS-based blocking and browser-based blocking is usually better than relying on only one layer, but the unfiltered endpoint is there for the cases where the blocklist gets in the way.

These endpoints have actually existed for a while. We didn't announce them before because DNSCrypt already existed on our side, and DNSCrypt solves some problems better than DoH. DoH still depends on the WebPKI/CA system. If a domain expires or a CA makes a bad decision, someone else can theoretically get a valid certificate for a name and run a service there. DNSCrypt doesn't work that way; the resolver identity is tied to the DNSCrypt server public key, so taking over the domain name alone isn't enough.

So DNSCrypt is still preferable if you're already using DNSCrypt, especially with Anonymized DNSCrypt relays. Our implementation is described at https://cryptostorm.is/blog/anondns

But DoH has one large advantage: it is easy. No extra DNSCrypt client is needed. Most people can paste a URL into their browser's secure DNS settings and be done with it. That's enough of a benefit to make these public.

Opening them publicly also adds more ordinary resolver traffic to the same PowerDNS recursor backends used by VPN clients and our public DNSCrypt servers. More mixed DNS traffic means more background noise around the resolver side of the network, which helps VPN users and public resolver users blend into a larger crowd. DNSCrypt users using anonymized relays already get stronger separation, but more noise on the recursors still doesn't hurt.

Instructions

Pick one endpoint first. For most people, start with:

https://public.deepdns.net/dns-query-ts

If a site breaks, switch to:

https://public.deepdns.net/dns-query

If you're using the VPN service and you often connect to the same server, you would get faster DNS lookups if you use that server's DoH endpoint.

Chrome / Chromium

Open Chrome's menu, then go to Settings.
Go to Privacy and security.
Open Security.
Scroll to Use secure DNS.
Enable it.
Choose the custom/provider option.
Paste the DoH URL, for example:
https://public.deepdns.net/dns-query-ts

If you're using Chrome because you need a Chromium-based browser, consider using Cromite instead. It's a Chromium fork with built-in ad blocking and privacy-focused patches. DoH only changes DNS. It does not fix the rest of the browser fingerprinting/tracking surface.

Firefox

Open Firefox's menu, then go to Settings.
Go to Privacy & Security.
Scroll down to DNS over HTTPS.
Choose increased/max protection if you want Firefox to use DoH instead of silently falling back to local DNS.
Choose Custom.
Paste the DoH URL, for example:
https://public.deepdns.net/dns-query-ts

If you're using Firefox mainly because you want a more privacy-friendly browser, also look at LibreWolf. It's an independent Firefox fork focused on reducing telemetry, tracking, and fingerprinting. DoH only changes DNS; LibreWolf covers a different part of the browser privacy problem, and some protections can be adjusted per-site when needed.

Microsoft Edge

Open Edge's menu, then go to Settings.
Go to Privacy, search, and services.
Scroll down to Security.
Enable Use secure DNS.
Choose a service provider / custom provider.
Paste the DoH URL, for example:
https://public.deepdns.net/dns-query-ts

Also: don't use Edge. There isn't really a privacy-friendly Edge fork in the same way there are privacy-focused Chromium or Firefox forks, because Edge is closed source and Microsoft's browser, so nobody can audit, rebuild, or modify the parts that matter into a sane privacy-friendly browser.

Safari / Apple platforms

Safari does not expose a simple "paste custom DoH URL here" setting like Firefox/Chrome/Edge. On Apple platforms, encrypted DNS is usually configured at the OS level using a configuration profile. That means the browser instructions are not as clean, and the exact UI differs between macOS/iOS versions.

If you're on macOS/iOS and want to use these DoH endpoints system-wide, create or install a DNS settings profile that points to one of the DoH URLs above. Be careful with random profile generators; configuration profiles can do much more than change DNS, so inspect what you're installing.

And no, there isn't a privacy-friendly open-source Safari fork either. It's Apple.

Testing

After enabling DoH, restart the browser and test it at https://cryptostorm.is/leaktest. That page checks IP, DNS, and WebRTC leaks using JavaScript. If you have JavaScript disabled, use https://cryptostorm.is/dnsleaktest/ instead.

If the test shows your ISP resolver, your browser is probably not using the DoH endpoint you configured, or the browser's DoH mode is set to a fallback/default protection level that still allows local DNS in some cases. Use the stricter/max protection mode if your browser provides one and you want it to use DoH only.

Age verification laws and other bad ideas

Since this post is already about DNS privacy, censorship resistance, and who gets to see what you're doing online, we should probably mention the current wave of age/ID verification laws.

California's AB 1043, Illinois' SB 3977, Brazil's Lei 15.211/2025, and similar laws being pushed elsewhere are all variations on the same theme: make operating systems, app stores, apps, platforms, or developers collect, infer, transmit, or act on age signals so that access can be allowed, denied, filtered, logged, or delegated to some other layer of the stack.

We're not implementing that, and we're not going to knowingly build on software that does. cryptostorm is a VPN/privacy provider. We encrypt and relay traffic, run resolvers, publish configs, write ugly shell scripts, and try to keep the network from becoming more stupid than necessary. We are not an ID-verification company, a parental-control vendor, or a checkpoint for whether someone is allowed to use their own computer.

Our servers currently run Arch Linux. There's been discussion in the Arch community about these laws, but as of this writing there doesn't appear to be a final project-wide stance. That's understandable; volunteer Linux distributions are not built like Apple, Google, Microsoft, or Meta. They usually don't have centralized user accounts, compliance departments, ID pipelines, state-specific activation flows, or a pile of lawyers waiting around to interpret every new legislative attempt to shove identity into the operating system.

Artix is on our short list if this becomes a real problem for Arch. Artix is Arch-based, rolling-release, and systemd-free. That last part is a bonus. systemd has had a long history of security problems and overreach, and plenty of people have had unkind things to say about it, including Linus Torvalds. PID 1 should be boring. A lot of modern Linux decided it should be an everything daemon instead.

There are also several long Reddit threads collecting bill text, model-bill language, lobbying disclosures, and state-by-state comparisons. The short version is that a lot of these proposals look less like "protect the children" and more like "move liability away from the platforms with the largest child-safety exposure, push the burden onto app stores, developers, and OS vendors, then let whoever controls the age-verification infrastructure become unavoidable."

See:

The implementation problem is obvious to anyone who has actually used Linux for more than ten minutes. Who is the "OS provider" for an Arch ISO mirrored by volunteers? What about derivatives? What about a tarball? What about a VPS image? What about containers? What about source builds? What about an offline installer? What about a router image? What about a single-user rescue ISO? What about a server that has no human-facing app store and no concept of a child account?

The answer is that the people writing these laws either don't know, don't care, or know exactly what they're doing and are fine with breaking smaller/free/open systems because the compliance model was designed around large centralized platforms.

So our policy is simple: no age verification, no ID verification, no age-signal APIs, no "upload your documents to prove you're allowed to use the internet", and no software stack changes that would turn our servers into part of that system. If a distribution we depend on goes in that direction, we'll move.

Other news

Lifetime tokens

As of this blog post, there are 21 unsold lifetime tokens left. The live counter on https://cryptostorm.is/#section5 has the current number. Once those are sold, the option to buy new lifetime tokens will be removed from the site.

This does not affect existing lifetime tokens. Existing lifetime tokens are still lifetime tokens. On the backend they have to be represented as a number because computers don't understand "lifetime", so they're set to 73 years, which was the global average life expectancy when that value was chosen.

The only change is that once the remaining lifetime tokens are gone, new ones won't be available for purchase. The reason is simple: server invoices continue forever, and lifetime tokens are a one-time payment. Over long enough timelines, the shorter-duration tokens are what keep the network paid for.

We've done this before years ago, and they may come back again someday, but they will not be part of the annual Black Friday through Cyber Monday half-off sale, or any other possible sale before that. $250 is too cheap for lifetime access. Every other token duration will still be in the sale like usual.

Windows client

We're still working on the next Windows client release at https://cryptostorm.is/windows#widget

The client is essentially our custom OpenVPN GUI, and the next build switches away from the now-unsupported Wintun adapter toward DCO/TAP, adds Xray support, and includes better/more translations. It also has a lot of UI cleanup already done, including a new server dropdown list with country flags and mouseover effects, and instant language switching without restarting the program.

It's closer to a rewrite than a normal update, so it's taking longer than usual. Most of the UI work and a lot of the new code is already done, but we still need to finish the DCO/TAP update, Xray support, and the remaining rewrite work. WireGuard support is being considered too, but that will probably wait until the next major release since it needs a lot more testing, and the official WireGuard client already works fine.

Server-side multihop

Mon, 09 Mar 2026 20:39:39 -0500

Introduction
Instructions
Technical details

Introduction

We added a new server-side multihop feature that's much easier to use and faster than the client-side multihop described on https://cryptostorm.is/multihop (OpenVPN) and https://cryptostorm.is/blog/multihopping-wireguard (WireGuard).

Client-side multihop is useful because it works with any provider, so you don't have to entirely trust a single one, but it's also slow because you're creating two VPN tunnels on your end, increasing your routing table exponentially with every hop (unless you're using namespaces or virtual machines). It's also very difficult to set up on non-PC devices.

Server-side multihop means the VPN server creates the second tunnel for you and forwards your traffic through it, so from your end (client-side), only a single VPN tunnel is needed. The servers are also in data centers that generally have much faster speeds than most residential ISPs, so it's faster than client-side multihopping. It also works on any device that has a web browser (and supports WireGuard or OpenVPN).

Instructions

Simply connect to the VPN as you normally would, then go to http://10.31.33.7/multihop in your web browser.

Select the new server for the second hop then click the "Enable multihop" button. The internet should instantly see your new IPv4 and IPv6 address in the region of whichever server you selected.

To turn it off or switch servers, click the "Disable multihop" button:

And it will revert back to your original exit IP(s). As the yellow text says, please don't use high-traffic applications since this doubles the servers' bandwidth for your VPN session(s).

Also, port forwarding will only apply to the first hop, not the second. And like with port forwarding, server-side multihop entries are removed when you disconnect from the VPN (immediately for OpenVPN, after 20 minutes for WireGuard).

Also, /changemyip must be set to the default exit IP before you can use this multihop, and vice-versa, multihop must be disabled to use /changemyip. That's because using both simultaneously can lead to weird combinations like IPv6 is multihopped, but IPv4 is through Tor, and it's difficult to revert that correctly.

Technical details

Once server-side multihop is enabled, the entry server creates a per-destination WireGuard path to the chosen second-hop server, rewrites the client’s source addresses onto an internal overlay, and policy-routes only that rewritten traffic into the second hop. The second server then NATs that overlay traffic out through one of its normal exit IPs. Coordination between the two servers happens over a private inter-server control plane carried inside a separate WireGuard mesh, so the backend calls can use plain HTTP since the transport is already encrypted and authenticated by WireGuard, and VPN clients (and the internet) can't reach that control-plane network.

One small note: every IP involved in this process is an internal address. These include the client’s internal VPN address, randomized internal session addresses used between servers, and the internal addresses used for the server control plane. The user’s real IP address is never part of this process and never appears in the multihop routing path.

The first step is creating the encrypted transport path between the entry server and the selected second-hop server. The function below is the actual logic that ensures the interface exists and configures the peer. Each possible destination gets its own WireGuard interface. The interface name and listening port are derived from a numeric identifier assigned to each server, which keeps everything deterministic across the entire network and avoids port collisions.

ensure_remote_if(){
  local remote_slug="$1" remote_pub="$2" remote_ip="$3" remote_oct="$4"
  local ifn port pk

  ifn="wg0mh-r${remote_oct}"
  port="$(( PER_REMOTE_PORT_BASE + remote_oct ))"
  pk="$(read_private_key)"

  if ! ip link show "$ifn" >/dev/null 2>&1; then
    ip link add dev "$ifn" type wireguard
    ip link set dev "$ifn" up
  fi

  wg set "$ifn" \
    listen-port "$port" \
    private-key <(echo "$pk") \
    peer "$remote_pub" \
    endpoint "${remote_ip}:${BASE_PORT}" \
    persistent-keepalive 25 \
    allowed-ips "0.0.0.0/0,::/0"
}

Once that encrypted path exists, the entry server assigns the session a temporary internal address. These addresses exist only between the two servers and are never visible (or reachable) to the user. They allow traffic from one specific client to be redirected without affecting anyone else connected to the same server.

alloc_session_v4(){
  local oct="$1"
  local host ip

  for attempt in $(seq 1 400); do
    host="$(shuf -i 2-254 -n1)"
    ip="10.1.${oct}.${host}"

    if ! grep -Rqs "^SESSION_V4=${ip}$" "$STATE_DIR"; then
      echo "$ip"
      return
    fi
  done
}

The client’s traffic is then rewritten so that packets appear to originate from this temporary session address. Only the selected client’s packets are rewritten. Other users connected to the same entry server continue using the normal routing path.

add_snat_v4(){
  local ns="$1" src="$2" to="$3"

  if [[ "$ns" == "ovpn" ]]; then
    iptables -t nat -I POSTROUTING 1 \
      -s "${src}/32" \
      -m comment --comment "mhop:${src}" \
      -j SNAT --to-source "${to}"
  else
    ip netns exec "$ns" iptables -t nat -I POSTROUTING 1 \
      -s "${src}/32" \
      -m comment --comment "mhop:${src}" \
      -j SNAT --to-source "${to}"
  fi
}

With the client now rewritten onto the internal overlay, policy routing ensures that only that client’s traffic is sent through the second-hop tunnel. A dedicated routing table is created and rules are added that match only the temporary session address.

policy_add(){
  # table, session_v4, session_v6, remote_endpoint_v4, mh_if
  local table="$1" s4="$2" s6="$3" remote_ep="$4" ifn="$5"
  local dev via
  read -r dev via < <(route_get_v4 "$remote_ep")

  # Prevent recursion: force traffic to the WG endpoint itself via main route.
  if [[ -n "${via:-}" ]]; then
    ip route replace table "$table" "${remote_ep}/32" via "$via" dev "$dev" >/dev/null 2>&1 || true
  else
    ip route replace table "$table" "${remote_ep}/32" dev "$dev" >/dev/null 2>&1 || true
  fi

  ip rule add pref "$MH_PRIO_V4" from "${s4}/32" table "$table" 2>/dev/null || true
  ip route replace table "$table" default dev "$ifn" >/dev/null 2>&1 || true

  if [[ -n "$s6" ]]; then
    ip -6 rule add pref "$MH_PRIO_V6" from "${s6}/128" table "$table" 2>/dev/null || true
    ip -6 route replace table "$table" default dev "$ifn" >/dev/null 2>&1 || true
  fi
}

After the entry server finishes preparing its side, it tells the destination server to activate the second half of the path. This request is sent to a backend endpoint over the internal server mesh. The request itself is plain HTTP, but the transport is inside WireGuard so it is already encrypted and authenticated. Since VPN clients cannot route to this internal network, the backend is unreachable from the outside world.

control_url_for_octet(){
  local oct="$1"
  echo "http://${CONTROL_NET_PREFIX}.${oct}/mh-backend"
}

resp="$(curl -fsS --max-time 8 \
  --data-urlencode "op=start" \
  --data-urlencode "a_slug=${this_slug}" \
  --data-urlencode "session_ip=${session_v4}" \
  --data-urlencode "session_ip6=${session_v6}" \
  "$url")"

When the second server receives the request, it installs NAT rules that translate the internal session address into one of its normal exit IPs. From that point onward the traffic path is: client → entry server → encrypted inter-server tunnel → exit server → internet.

backend_add_snat_v4(){
  local session_ip="$1"
  local exit exit_ip pr
  exit="$(pick_exit_v4)"
  exit_ip="${exit%:*}"
  pr="${exit#*:}"

  # UDP
  iptables -w -t nat -I POSTROUTING 1 -s "${session_ip}/32" -p udp -m udp --dport 1:65535 \
    -m comment --comment "mhop:${session_ip}" \
    -j SNAT --to-source "${exit_ip}:${pr}"

  # TCP
  iptables -w -t nat -I POSTROUTING 1 -s "${session_ip}/32" -p tcp -m tcp --dport 1:65535 \
    -m comment --comment "mhop:${session_ip}" \
    -j SNAT --to-source "${exit_ip}:${pr}"

  # ICMP
  iptables -w -t nat -I POSTROUTING 1 -s "${session_ip}/32" -p icmp \
    -m comment --comment "mhop:${session_ip}" \
    -j SNAT --to-source "${exit_ip}"

  echo "$exit_ip:$pr"
}

Source port range restrictions apply here too (the 'pr' variable in the above code), so the Port Shadowing protections described on https://cryptostorm.is/blog/port-striping-v3#I-I won't be affected by this server-side multihop.

Earlier versions of this system used HTTPS over the public internet for the backend coordination between servers. That design was still secure — the HTTPS used post-quantum ciphers and the backend endpoint name was intentionally difficult to guess — but it still meant exposing an endpoint to the public internet. Even though the backend only accepted POST requests and validated all inputs, a determined attacker could still attempt to discover the endpoint and flood it with requests.

Rather than maintain IP-based ACLs or additional authentication layers between dozens of servers running identical scripts, the system now uses a dedicated WireGuard control-plane mesh. Each server has a lightweight interface that connects to every other server. Even with forty peers this consumes negligible resources, while completely removing the need to expose backend endpoints to the public internet.

Some other parts of the infrastructure still use internal HTTPS endpoints with custom certificate authorities and strict IP-based ACLs. Those endpoints are already limited to specific internal systems and use post-quantum TLS, which is sufficiently secure for their purposes. They could also be migrated onto this mesh though.

WireGuard itself is not post-quantum secure yet, but that is acceptable here because the control-plane traffic does not contain any sensitive information. The requests only coordinate session state between servers and never include user identities or real client IP addresses. Even in a hypothetical future where WireGuard’s cryptography could be broken, the traffic crossing this mesh wouldn't reveal anything useful about users.

Xray (w/VLESS+REALITY) support added

Fri, 21 Nov 2025 17:12:42 -0600

Introduction/TLDR
Instructions
- Android
- Windows/Linux/Mac
Technical details
- The CSXRAY app
- The server-side Xray

Introduction/TLDR

We added Xray support to the network. In contrast to the stunnel-based HTTPS obfuscation we’ve been using for years, Xray’s REALITY mode is capable of mimicking what a normal browser handshake looks like — right down to the JA3 fingerprint and the general traffic profile that accompanies it, which is useful if you’re behind one of those networks that actively tries to identify and interfere with VPN usage.

Xray also works with WireGuard (and UDP OpenVPN), while stunnel only works with TCP OpenVPN.

The Xray config generator is at https://cryptostorm.is/xray/

We also made an Android Xray app, available at:
https://cryptostorm.is/xray/app-latest.apk [sig]
(source code at https://github.com/cryptostorm/CSXRAY)

Port 8443 will give you better speeds, so you should use that if your network allows it and it doesn't make your traffic too unusual. If you must use another port, anything from 1-65535 should work (excluding 5061, 5062 and 5063), though it won't be as fast since it has to go through the haproxy/SNI routing described on https://cryptostorm.is/blog/port-striping-v3. Port 443 is the default since that's the standard HTTPS port.

Instructions

Android

First, setup WireGuard following the instructions on https://cryptostorm.is/android#wg
(don't connect yet). You should have the cs-* configs imported into WireGuard.

Next, download and install https://cryptostorm.is/xray/app-latest.apk [sig] [source]

Most Android web browsers will ask for permission to install applications the first time you download an .apk. It’s safe to allow it for the install, but after installation it’s generally a good idea to turn that permission back off so the browser can't install anything else in the future.

After the app is installed, open it and:

Choose the server you want to use.
Change the port, if needed.
Tap Start Xray.
The status indicator near the middle will show a blue icon and:
"Xray is running (waiting for traffic)"

Next, open the WireGuard app:

Edit the cs-… config for the same server you selected in the Xray app.
(cs-austria, cs-dallas, etc.)
In the WireGuard config editor, tap All Applications.
In that app exclusion list, exclude the CSXRAY app.
(This is required to prevent a recursive routing loop)
Back in the config editor, set the Endpoint to:
127.0.0.1:31338
Save, then connect WireGuard normally.

If you switch back to the CSXRAY app, you should now see a green status icon with "Xray is forwarding WireGuard traffic" next to that, as well as RX (received bytes) and TX (sent bytes) counters in the top right.

✔️Your WireGuard traffic should now appear as ordinary browser-looking HTTPS traffic.✔️

You can now close this app the same way you would the WireGuard app. Both will run in the background until you re-open the app and tap stop/disconnect.

Note: Don't enable the "Block connections without VPN" option in your Android settings. That would prevent this app from working because then only the WireGuard app would be allowed, but WireGuard is forwarding to Xray, so Xray needs to be allowed too. There's no Android option to "Block connections without VPN except for this one app", so it has to be disabled.

Also, the app has built-in translations for: English, Russian (Русский), Chinese (中文), Japanese (日本語), Swedish (Svenska), Persian (فارسی), and Arabic (العربية). Tap the U.S. flag in the upper right to bring up the language selection menu.

And of course, the most important feature: Dark/light mode

Windows/Linux/Mac

First, setup WireGuard following the instructions for your platform on https://cryptostorm.is/#section6
(just don't connect to anything yet).

Next, download v2rayN from the releases page: https://github.com/2dust/v2rayN/releases
(Choose the version appropriate for your system.
On Windows, the "desktop" zip builds are the simplest: unzip then run v2rayN.exe)

Once v2rayN is running:

Go to the Xray config generator page: https://cryptostorm.is/xray/
Select the server you want to use.
(For faster speeds, use port 8443 if it's allowed on your network).
Click SHOW CONFIG, then click Copy to place the config in the clipboard.
Switch back to v2rayN and click the main window once then press:
Ctrl + V
and v2rayN will automatically import the config.
A new entry will appear in the list.
Double-click that entry then click Confirm to actually start Xray.
Once running, v2rayN should show a "listening UDP on 127.0.0.1:31337" somewhere in the output.
That means Xray is ready.
Now switch back to WireGuard and edit the config
(for the same server you selected when generating the Xray config).
Find the line that begins with:
Endpoint = something.cstorm.is:443
and change it to:
Endpoint = 127.0.0.1:31337
Save the WireGuard config then activate it as usual.

Your traffic flow is now:
WireGuard → local Xray → REALITY/VLESS → server → WireGuard → normal routing.

Instead of WireGuard traffic, anyone monitoring will see only ordinary HTTPS (TLSv1.3) browser-looking traffic.

Windows 11 users

An exclusion needs to be added to the Windows Firewall in order for Xray to reach the internet:

Go to the start menu and open: Firewall & Network Protection

On that screen, click "Allow an app through firewall", then in the next window click "Change settings", then "Allow another app".

Browse and select your xray.exe file, which is in \v2rayN-windows-64\bin\xray\ (wherever you unzipped v2rayN).

Technical details

The CSXRAY app

On Android, the CSXRAY app is just a GUI wrapper for Xray-core. It doesn't use Android’s vpnService API as most Xray apps do because this app is meant to run alongside another VPN client. All it does is start Xray with a dokodemo-door inbound listening on 127.0.0.1:31338, and displays status changes coming from a few small patches we added to Xray-core (which simply notify the UI when Xray is idle, receiving traffic, or shutting down).

In the main CSXRAY app window, the gear icon in the top left will display the current Xray config. It's read-only unless you choose 'Custom IP' in the server selection list. That's mostly for people who want to use this app with their own (non-cryptostorm) VPN/Xray servers. There's a basic config editor in there that only does simple JSON syntax validation, but otherwise just feeds whatever JSON config you give directly into Xray-core, so all the default inbounds/outbounds are supported (As of v25.10.15, inbounds: dokodemo-door, HTTP, Shadowsocks, SOCKS, Trojan, VLESS, VMess, WireGuard, Outbounds: Blackhole, DNS, Freedom [alias: direct], HTTP, Loopback, Shadowsocks, Socks, Trojan, VLESS, VMess, WireGuard).

The app ships with a built-in list of server IPs so that DNS can be avoided. Those IPs are updated automatically over HTTPS endpoints that are on all of the servers, and it downloads the updates through the same REALITY connection the user's WireGuard traffic will use. This means the app does not leak out of the tunnel to check for updates, and it does not introduce any additional traffic patterns. Update checks are rate-limited (never more than once per hour) and jittered with randomized 60–80 minute intervals, specifically to avoid periodic beacons.

When running, the traffic flow looks like this:

WireGuard app → 127.0.0.1 (dokodemo-door inbound on the client) → REALITY/VLESS → server-side Xray → forwards to the entry IP as raw WireGuard packets → routed normally.

The server-side Xray

The server-side Xray instance runs inside its own network namespace. This prevents it from interfering with the main routing tables and firewall rules, and ensures that obfuscated traffic terminates in a controlled environment. After de-obfuscation, packets are forwarded into the entry/default namespace where the port striping rules identifies WireGuard handshakes and assigns each session to one of several exit namespaces.

To anyone observing on-path (either locally or upstream), the only visible traffic is a normal TLSv1.3 connection on whichever port you chose, with handshake characteristics that resemble a browser rather than a VPN.

Fully post-quantum OpenVPN w/OpenSSH tunneling

Mon, 11 Aug 2025 00:27:50 -0500

Fully post-quantum OpenVPN w/OpenSSH tunneling
DNS ad/tracker blocking vulnerability fixed
What's next?

Fully post-quantum OpenVPN w/OpenSSH tunneling

We tweeted this a few weeks ago, but most people probably don't know what this means:

We added support for post-quantum key exchanges to our SSH tunneling/obfuscation.
OpenVPN can't do PQ KEX yet, but with this you can add a PQ layer on top of your OpenVPN (TCP) traffic.
This requires a recent OpenSSH/OpenSSL version.

So we thought we'd do a quick blog post explaining it.

In https://cryptostorm.is/blog/pq-openvpn we explain how OpenSSL 3.5.0 allows us to use post-quantum algorithms with OpenVPN, but like it says on that page:

In these new ML-DSA-87 OpenVPN instances, only authentication is post-quantum. The key exchange and encryption still rely on classical algorithms

That means the new ML-DSA-87 instances only protect against quantum impersonation attacks (spoofing/MitM). To be fully post-quantum, OpenVPN needs to officially add support for post-quantum key exchanges. The key exchange is where the server (and client) agree on which symmetric keys to use to actually encrypt your traffic (AES-256-GCM in our newer ML-DSA-87 instances). Those keys are rotated every 20 minutes for perfect forward secrecy, but they use classical algorithms, so they're still susceptible to quantum attacks.

OpenVPN might not support post-quantum key exchanges yet, but OpenSSH already does (since 2024).
In our SSH tunneling server-side config we have this line which tells OpenSSH which key exchange algorithms the server allows:

KexAlgorithms mlkem768x25519-sha256,sntrup761x25519-sha512,curve25519-sha256@libssh.org,ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256,diffie-hellman-group-exchange-sha256

Those two at the beginning are the new post-quantum algorithms. You can find more information about sntrup761 or ML-KEM-768 on any search engine.

What all this means is that if you use our SSH tunneling feature described on https://cryptostorm.is/blog/ssh-tunnels then you can have post-quantum key exchanges in that outer SSH layer that encapsulates/obfuscates your OpenVPN traffic, as long as your OpenSSH or PuTTY version is recent. Even with OpenVPN still partially susceptible to post-quantum attacks, that won't matter because all your traffic will appear to be SSH (because it is), and that encrypted traffic is using post-quantum algorithms for both key exchange and authentication.

Support for post-quantum key exchanges was added to OpenSSH in 9.9, which https://www.openssh.com/txt/release-9.9 says was released on 2024-09-19. That means if your OpenSSH version is 9.9 or newer, then you can make use of these post-quantum features in our SSH tunneling. Most Windows users are probably going to use PuTTY instead of OpenSSH to start an SSH tunnel (because it's easier), and according to https://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/ml-kem.html, they added post-quantum key exchange support in version 0.83, so if you have that or newer, then you can do a fully post-quantum tunnel.

And just a reminder: SSH tunneling on our network only works with the OpenVPN TCP configs. It doesn't work with OpenVPN UDP or WireGuard (yet). Also, with OpenSSH, you can verify that the SSH session is using these new post-quantum algorithms by running the command(s):

[df@b ~]$ ssh -v -D 127.0.0.1:1080 sshtunnel@paris.cstorm.is 2>&1 | grep "kex: algorithm"
debug1: kex: algorithm: mlkem768x25519-sha256
sshtunnel@paris.cstorm.is's password:

If you see mlkem768x25519-sha256 or sntrup761x25519-sha512 in that debug1: kex: algorithm: line, then you know it's using a post-quantum algorithm for the key exchange.

DNS ad/tracker blocking vulnerability fixed

I ran into this a few weeks ago when I was using an Android phone with the VPN turned on and the ad/tracker blocking DNS service enabled (see https://cryptostorm.is/ts). I was using an app that had some of those embedded Google ads, which normally gets blocked by our ad/tracker blocking DNS, but for some reason, a few ads were still getting through occasionally.

The problem ended up being a small window (~5 seconds) where ad/tracker hosts weren't being blocked correctly because the PowerDNS Recursor the ad/tracker blocking uses was in the process of restarting, because it has to restart whenever it updates to the latest ad/tracker host lists from https://github.com/hagezi/dns-blocklists/?tab=readme-ov-file#proplus

To close that small window, I changed our current DNS setup of 2 PowerDNS Recursors (one ad/tracker blocking, one unfiltered) so that for the ad/tracker blocking one dnsdist is used instead to balance between two separate ad/tracker blocking PowerDNS Recursor instances. The purpose of dnsdist here is that it has the ability to drain all connections from one of those recursors so that they go to the 2nd one, then with no clients using the 1st one, it can safely be restarted. Once it's done, dnsdist does the opposite, it drains all connections to the 2nd one and sends everyone to the 1st one so that the 2nd one can be gracefully restarted. This completely closes that ~5 second window.

What's next?

We started working on adding Xray support to the network a few months ago. That will allow our clients to obfuscate their VPN traffic so that it looks like HTTPS traffic, but unlike stunnel in our current HTTPS obfuscation setup, Xray better mimics the HTTPS that a real browser would generate (same JA3 hashes and all), and it works with WireGuard (and OpenVPN UDP, and technically OpenVPN TCP too but that would be slow).

It's actually implemented on the servers now and tests with v2rayN on Windows/Linux/Mac have succeeded, but we haven't announced it yet because we're still testing on mobile devices and something might change later in the server-side setup.

We couldn't find an existing Android Xray app that exposes the specific features of https://github.com/XTLS/Xray-core that we needed (dokodemo-door inbound, reality outbound), so we started working on our own Android app. All the existing apps did a local SOCKS proxy or a full VpnService style VPN, which won't work in our Xray setup. The idea is that the user would have WireGuard already installed and loaded with cryptostorm configs like normal, then they start our app, which starts an xray instance listening on 127.0.0.1:31337 and connects to whichever server they want to connect to. Then once Xray is running, they switch back to the WireGuard app and edit the config for the server they want to connect to (has to be the same as the one they selected in our app), then they change the Endpoint to 127.0.0.1:31337, and they use WireGuard's built-in app exclusion feature to exclude our app from WireGuard's VPN. That app exclusion is required, otherwise a recursive routing loop would occur when WireGuard tries to send our Xray traffic through the VPN.

At the moment, it looks something like this (in Android Studio):

The core code is pretty much done now, we've got it routing everything correctly, Wireshark/tcpdump show the device is sending out TLSv1.3 "HTTPS" traffic. Now we just need to tweak the UI a bit and clean up some other things that aren't related to Xray (like something that auto-updates the server list, but only after you connect to the VPN). It uses hard-coded IPs since our entry IPs don't change often, and that avoids having to do DNS resolution. There's also a "Custom IP" option in the server list dropdown menu that might be useful to people who want to do their own WireGuard+Xray setup using their own servers.

We're probably still a month or two away from releasing this though. Of course, we plan on releasing the source code once it's finished.

cryptostorm blog

Fully post-quantum OpenVPN (without OpenSSH tunneling)

Table of contents

Introduction/TLDR

Post-quantum key exchanges in OpenVPN

Windows client v4

DNS over HTTPS

Table of contents

Introduction

Instructions

Chrome / Chromium

Firefox

Microsoft Edge

Safari / Apple platforms

Testing

Age verification laws and other bad ideas

Other news

Lifetime tokens

Windows client

Server-side multihop

Table of contents

Introduction

Instructions

Technical details

Xray (w/VLESS+REALITY) support added

Table of contents

Introduction/TLDR

Instructions

Android

Windows/Linux/Mac

Windows 11 users

Technical details

The CSXRAY app

The server-side Xray

Fully post-quantum OpenVPN w/OpenSSH tunneling

Table of contents

Fully post-quantum OpenVPN w/OpenSSH tunneling

DNS ad/tracker blocking vulnerability fixed

What's next?