OpenBSD 8.0: Post-Quantum TLS On by Default, 64-vCPU VMs

OpenBSD 8.0, released October 20, 2026, became the first major operating system to enable post-quantum TLS by default, with LibreSSL 4.4 shipping X25519MLKEM768 as the preferred TLS 1.3 group in libtls so libtls-based daemons such as httpd, smtpd and relayd negotiate hybrid post-quantum key exchange without configuration changes. The release also bundles OpenSSH 10.6, which adds experimental ML-DSA44/Ed25519 composite post-quantum signature support that OpenBSD says is not yet ready for production SSH migration, and raises OpenBSD VMM's per-guest limit from 16 to 64 virtual CPUs with x2APIC and MSI/MSI-X virtio support. The default matters because most TLS stacks, including OpenSSL 3.5, support the hybrid algorithm but require operator configuration, leaving servers exposed to harvest-now-decrypt-later attacks that researchers expect to matter within 10 to 20 years.

OpenBSD 8.0 landed today — October 20, 2026 — and it crossed a milestone most operating systems are still deliberating: post-quantum TLS is now on by default . LibreSSL 4.4 https://www.openbsd.org/80.html ships X25519MLKEM768 as the preferred TLS 1.3 group in libtls, meaning any server software built on OpenBSD’s TLS library negotiates hybrid post-quantum key exchange automatically, without a single config change. It is the first major operating system to flip the server-side default. Post-Quantum TLS: The Default Nobody Else Has Set X25519MLKEM768 is a hybrid key exchange: the session secret derives from both X25519 classical elliptic-curve Diffie-Hellman and ML-KEM-768 Module-Lattice Key Encapsulation, the post-quantum component . Hybrid design means both algorithms protect the session simultaneously — breaking one leaves the other intact. RFC 10024 https://www.amongbytes.com/posts/rfc-10024-negotiating-pq-tls-handshakes/ , standardized by the IETF in August 2026, formalizes this approach. However, adoption has lagged on the server side. Chrome and Firefox already send X25519MLKEM768 by default on the client side. Meanwhile, most TLS stacks — including OpenSSL 3.5 — support the hybrid algorithm but do not set it as preferred without operator configuration. OpenBSD 8.0 closes that gap: any libtls-based daemon httpd, smtpd, relayd, and third-party software built against libtls advertises X25519MLKEM768 as preferred immediately on upgrade. No cipher suite edits required. Furthermore, this matters for a concrete reason: harvest-now-decrypt-later attacks. Adversaries record encrypted traffic today and decrypt it once quantum computers become capable — a timeline most researchers place in the 10–20 year range. Consequently, servers handling long-lived sensitive data benefit from post-quantum key exchange starting now, and OpenBSD makes that decision for you. Worth noting: the change applies to libtls specifically. Applications using the OpenSSL compatibility layer directly still need explicit configuration. Related: Gitea 28.2: Nine CVEs Patched, SSH Bypass — Upgrade Now https://byteiota.com/gitea-28-2-nine-cves-patched-ssh-bypass-upgrade-now/ OpenSSH 10.6 Post-Quantum Signatures: Experimental, Honestly OpenSSH 10.6, bundled with the release, adds experimental composite post-quantum signature support via the ML-DSA44/Ed25519 key type. ML-DSA FIPS 204 https://nvlpubs.nist.gov/nistpubs/fips/nist.fips.204.pdf is NIST’s standardized post-quantum signature algorithm, finalized in August 2024. The composite design pairs it with Ed25519 — a signature is only valid if both the lattice and elliptic-curve components verify, preserving classical security while adding quantum resistance. “Experimental” is the operative word, and OpenBSD uses it correctly. Key sizes are significantly larger than standard Ed25519 keys, so production SSH infrastructure should not migrate yet. However, testing now is actively encouraged. Moreover, the OpenBSD team’s track record is to promote features from experimental to default once the ecosystem has validated them — expect ML-DSA44/Ed25519 to graduate in OpenSSH 10.7 or 11.x. SSH authentication keys are long-lived, and consequently, a quantum adversary capturing auth traffic today could become a problem in 2040. OpenBSD VMM: 64 vCPUs and a Security Argument Worth Making OpenBSD’s built-in hypervisor now supports up to 64 virtual CPUs per guest VM, up from 16. Additionally, x2APIC support and MSI/MSI-X interrupts for virtio devices improve guest hardware compatibility significantly. The amd64 kernel’s virtual address space jumped from 4 GB to 512 GB, enabling the system to map over 4 GB of VRAM — relevant for GPU-intensive Linux guest workloads. In contrast to KVM on Linux — which has a broader ecosystem and better tooling — OpenBSD VMM’s security architecture remains its differentiator. Each VM runs inside a pledged, unveil-constrained process, the same sandboxing mechanism used throughout OpenBSD. As a result, VM escapes are meaningfully harder by design. For operators running security-sensitive infrastructure where a hypervisor compromise is catastrophic, the 64-vCPU update means OpenBSD VMM can now handle compute-intensive workloads without hitting previous limits. See the Linuxiac breakdown https://linuxiac.com/openbsd-8-0-released-with-64-vcpu-vm-support-intel-arc-graphics/ for full hardware details. Key Takeaways - OpenBSD 8.0 makes X25519MLKEM768 the preferred TLS 1.3 group in libtls — the first major OS to set post-quantum hybrid TLS as the server-side default without operator configuration - The post-quantum TLS change applies to libtls-based applications only; apps using libssl directly still require explicit configuration - OpenSSH 10.6 ships experimental ML-DSA44/Ed25519 composite post-quantum signatures — worth testing now, not yet deploying in production infrastructure - VMM supports 64 vCPUs per guest, up from 16, with pledge/unveil sandboxing that no mainstream hypervisor matches for security isolation - OpenBSD 8.0 is available now at openbsd.org; the standard sysupgrade path handles upgrades from 7.9