quak.

Secure Boot works by verifying the digital signature of the code it is about to run. This code must be signed by a key from the db database in order to pass. If not (or the executable hash / certificate was found in the dbx database, which contains malicious binaries / revoked certificates), the process will be aborted.

Both can be updated by the operating system through the UEFI, if such an update is signed by one of the KEK keys, which include at least the Microsoft KEK CA and OEM keys. Their updates are protected by the top level PK key owned by the manufacturer (OEM), which also protects updates to itself.

Why am I telling you all this? On June 24. and 27., "Microsoft Corporation KEK CA 2011" and "Microsoft Corporation UEFI CA 2011" expired, making updates to db / dbx (using KEK) and signing of bootloaders / EFI applications with them not possible any more. It didn't affect running systems though, as certificate expiry is not checked as part of the boot process to prevent old systems from turning into bricks.

But it isn't over yet, as "Microsoft Windows Production PCA 2011" is about to expire on my birthday October 19th, making updates to the Windows bootloader look invalid to older systems. This is because their db does not contain the newest "Windows UEFI CA 2023", which will be used to sign all future updates.

Should you care? Unless you are a high-ranking politician or a journalist, you probably won't be a priority target for a brand new zero-day bootkit. And your system will be good until Microsoft starts adding their 2011 keys to dbx, which will you'll definitely notice if you have an old firmware with the newest OS. Good news: there is a new batch of certificates from 2023, which replaces old ones and is being actively distributed.

To check the presence of the UEFI CA 2023, you can execute the following command in PowerShell with admin rights:
Get-ItemProperty -Path HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing\
If you see UEFICA2023Status as Updated, WindowsUEFICA2023Capable as 0x20 and no errors - congratulation, your system is future-proof. Otherwise, you should probably head to the "Windows Update" section and hope for the update to contain the new keys. This is only possible if the OEM has not yet dropped support for your device :)

Linux bootloaders are currently signed with both certificates, making updates possible for legacy and new systems. You can check db contents using the mokutil, followed by firmware update in case you only have the older version:
mokutil --db
fwupdmgr refresh && fwupdmgr update

#software #hardware #uefi

Today I learned: apart from common CamelCase and snake_case naming conventions we also have the kebab-case. Best name IMO

One more reason to perform RPKI & ASPA ROV. The attack surface is real, don't wait until you get impacted.

This summer you have a unique opportunity to find a critical RCE in curl/libcurl using your fancy multi-stage AI pipeline and sell it to threat actors for many money, so that they can do bad things to half of the internet, until the vulnerability eventually gets patched somewhen after August 3rd 😉

In the previous post I briefly mentioned the DNS protocol. If you somehow managed to find my channel, I'm sure you have at least a basic understanding of it. In short, it is (primarily) responsible for keeping the web resource addressing human-friendly by providing memorable aliases for IP addresses, commonly referred to as "domain names". At the core of this system are ~2000 root name servers distributed around the globe, which are heavily anycasted to be reachable via only 13 IPv4/6 addresses and perform load balancing. Those are hard-coded into all recursive resolvers to be used by your devices for getting information on all available TLDs (top-level domains like .com, .net, .de).

By now this protocol has grown way beyond its initial purpose, offering dozens of additional record types used by mail servers, certificate authorities and hundreds of thousands of generic applications. The TXT record alone offers an infinite amount of exotic use-cases, including (but not limited to) using it as a file storage, to play DOOM, running a TCP proxy and much more.

As with many early protocols, DNS (in its original form) suffers a lack of security. To be exact, it doesn't offer any of confidentiality (encryption), integrity (modification protection) or authenticity (of the source) of the data. This flaw is actively used by many countries to restrict access to certain domains (as seen in one of previous posts), but also by threat actors to redirect (un)encrypted traffic from legitimate resources to their own machines.

Side note: Starting from 2021, the Russian government operates "НСДИ" (NSDI, "National System for Domain Names"), which provides recursive resolvers and alternative root name servers, which are required to be used by ISPs (and, preferably, their clients too). I wasn't able to find any reports indicating a difference of the national root zone to the global one, but there are certain blocked domains when using their recursive resolver.

To migrate these issues, two protection mechanisms were introduces: DoX ("DNS-over-X", insert T for "TLS", H for "HTTPS", Q for "QUIC" instead of X) and DNSSEC. The first measure implements a secure underlay channel for the transmission, but does not guarantee the "honesty" of the used recursive resolver. DNSSEC solves this problem by providing signed responses with the possibility to verify their chain of trust up to the root name servers. An "authoritative" extension to "DoX" is currently being deployed to additionally secure the communication between your recursive resolver and its targets.

Both methods come with limitations, as "DNS-over-X" is prone to protocol- / domain-based blocking (with DoT / DoQ without enforced certificate validation being vulnerable to targeted MITM attacks), while DNSSEC is still missing for some TLDs and may cause some (un/)funny effects upon unsuccessful signing key rotation (1, 2).

#dns #quic #networking #dpi #firewall

A note on QUIC protocol

QUIC is a relatively new transport protocol standardized in RFC 9000 (2021), which aims to provide secure, reliable and fast data transfer over UDP. Combined with HTTP/3 protocol it reduces the overhead of the handshake (compared to HTTP/2 with TLS and TCP), solves the head-of-line blocking problem and makes SNI-based censorship more difficult for an on-line observer (e.g. ISP). However, it does come at a cost.

As with any attempt to improve the internet on a global scale, the adoption of the new technology takes an eternity and meets resistance from individual states if they see a risk in it; so does QUIC. Despite being implemented in the majority of browsers and server-side engines, the use of HTTP/3 is only at ~30% of the three HTTP protocols, as per Cloudflare Radar. All this despite HTTP/3 with QUIC being available (and enabled) for all plans.

Trying to blindly connect to port 443 via UDP would be a waste of time due to a large number of websites ignoring the existence of QUIC. Thus, two independent helpers may inform the client about its availability. An Alt-Svc response header may be used to specify the port QUIC is listening on, but requires an initial TCP / TLS connection to the website. A measurement documented by Geoff Hutson from APNIC (as of June 2025) shows a clear sign of the Chrome browser relying on this method, performing a QUIC connection only on the second attempt (after the header was observed). Safari, on the other hand, queries for HTTPS DNS record of the target domain to check for "h3" ALPN support. This record comes with lots of useful information (IPv4 and IPv6 hints, ECH and supported ALPNs) and improves the "time-to-QUIC", as it does not require a preceding TCP connection to the website.

As mentioned, QUIC also makes DPI-based per-domain access lists more difficult, as the protocol does not carry SNI in plaintext, contrary to TLS (without ECH extension). However, this does not stop certain country-scale firewalls from using packet decryption, as all necessary encryption parameters are present in the handshake, unfortunately. This process comes at the expense of compute resources, as such the protocol may be completely blocked in some cases.

In my opinion, the protocol has lots of potential for improving the overall user experience in the "World Wide Web". Apart from the examples with HTTP/3 it has also found its use with DNS, both as an underlay (DoQ) and overlay (spoiler alert), which additionally improve the privacy and availability of the resources.

#http #quic #networking #dpi #firewall

On the importance of MTU value for peer-to-peer tunnels

An incorrect, too large MTU (Maximum Transmission Unit) value may cause unexpected behavior of a link between two machines. It is particurlarly difficult to determine the root cause of working pings, but certain transmissions failing, especially if you've never had this problem before. I've had two cases where the connection success rate to different websites through a tunnel (GRE / WireGuard) was seemingly random, until you open Wireshark and notice a bunch of fragmented packets on your physical interface.

The maximum allowed MTU between two machines (=PMTU, "Path MTU") is determined by the lowest MTU of any intermediate node. The most straight-forward way to determine this value involves using ping with variable data size and DF ("Don't Fragment") flag set, until you get error-free bidirectional transmissions:
# 1500 MTU = 20 IPv4 header + 8 ICMP header + 1472 bytes ICMP data
# Lower this value to get error-free transmissions
ping -c 3 -M do -s 1472
However, wire-seek does essentially the same (but automated and more efficient) and has additional support for WireGuard tunnel MTU discovery.

It is important to note that due to (possible) asymmetric routing through the internet between two machines, this value may be different on either side. Additionally, weird per-packet or per-protocol processing rules on intermediate nodes may lower this value for your tunnel. A direct MTU (via the IPv4 underlay network) of 1492 to a peer does not necessarily mean an MTU of 1432 (60 bytes IPv4 WireGuard overhead) within a tunnel. The solution to my fragmentation problems was to run MTU discovery inside the tunnel and apply it to its interface:
ip link set mtu dev
Or add the following to WireGuard configuration for persistance:
[Interface]
MTU =