Home

Podfeet Podcasts

Security Bits logo - a green padlock with the words Security Bits to the right and in tiny letters below ithat it says 10101010 indicating a digital lock

Security Bits — 1 August 2025

  • by Bart Busschots

    • Feedback & Followups

    Deep Dive 1 — CloudFlare WARP

    Context from Allison:

    Jeff Gamet did a presentation at Macstock about security and privacy. He explained some things that Bart has taught us before, explaining what DNS is, what HTTPS is, and how they fold together to give us DNS over HTTPS, or DoH. He recommended using Cloudflare’s DNS, but went on to explain that on the Mac with Safari, we don’t actually get DoH unless we do a little work, and he suggested using something called WARP from Cloudflare. Allison did a little bit of reading on it and decided to ask Bart to explain it.

    Before I describe WARP, let me clarify a few things:

    1. iCloud Private Relay gives paying iCloud customers DoH system-wide with no faffing about, but only if you turn it on.

    2. On the Mac, browsers are free to bring their own browser engines, and those engines are free to do their own thing in terms of DNS. Their developers can choose to use the system-level DNS APIs, or they can just make their own DNS queries. This is why some third-party browsers beat OS vendors to the punch with DoH support. As of today, this is what I see:

      1. Chrome — defaults to checking if your OS-configured DNS server supports DoH, and uses it if it does
      2. Firefox — DoH on by default in a few regions (including the US), but off by default in most of the world
      3. Edge — same as Chrome
    3. You can configure a free DoH provider in any of the 3rd-party browsers (like Cloudflare), but that setting only affects that browser, not anything else you do on the device!

    4. OS-level DoH support is patchy:

      1. Windows 11 has good built-in support
      2. macOS doesn’t have any DoH support other than using iCloud Private Relay
      3. Linux support entirely depends on your distro!
    5. If you really want to, you can add DoH support to your Mac by running your own DNS stub resolver that listens on the regular DNS protocol on some local port and forwards all queries to a real provider over DoH, and then configuring your Mac to use 127.0.0.1 on your chosen port as your OS-level DNS server. In effect, you are proxying insecure DNS queries from the OS securely. This works, but it’s a lot of faffing about!

      So, what makes CloudFlare WARP so appealing is that it provides us a simple way to get secure OS-level DNS on any OS, which is why it piqued Allison’s interest, and why it might be something a NosillaCastaway might want to use.

    TL;DR — WARP is a highly constrained WireGuard VPN combined with a secure DNS service. It routes all your DNS queries to CloudFlare’s 1.1.1.1 DNS server via an encrypted tunnel connected to your nearest CloudFlare data centre, and can optionally also route all your internet traffic through that same tunnel.

    As we discussed in great detail recently on CCATP 815, VPN protocols can be used in myriad ways to solve myriad problems, with different clients giving you different levels of control, and hence different trade-offs between flexibility and ease-of-use. WARP is at the extreme end of the ease-of-use side of that spectrum, offering almost no configuration options, and hence, making it really easy to use.

    First and foremost, it plugs the potentially massive privacy gap created by DNS’s inherent openness. Just about every app that connects to the internet in any way needs to translate human-friendly domain names like podfeet.com into IP addresses like 172.67.199.198. These name resolutions are performed using the DNS protocol, and traditional DNS is ancient (in internet years, anyway) and is completely unencrypted. So, even when you browse to secure websites, or use apps that use only encrypted protocols, those unencrypted DNS queries can still leak a lot of sensitive metadata.

    For example, if you go to https://www.cancer.ie and submit their help form, people sharing your network can’t see what you wrote, since HTTPS is encrypted. However, they do know you just browsed to the Irish Cancer Society, so they have a pretty good idea that you or someone you care about probably has cancer. That can be added to your ad tracking profile. Even more dangerously, if you browse securely to `https://www.bankofamerica.com,` attackers can’t see what you did there, but they can infer you’re likely a customer, and target you with appropriately branded phishing.

    You get the idea — traditional DNS is a privacy train wreck!

    Technologically, we have a fix — there are new encrypted DNS protocols, including DNS-over-HTTPS, or DoH, but using them involves more faffing about than most people are realistically going to do. The biggest reason it’s a faff is that almost no one manually configures their DNS; instead, we all rely on the same DHCP protocol that handles assigning our devices’ IP address to configure our DNS. That means that whoever runs the network you’re using gets to decide on the DNS server you should use, and, hence, control the protocol details.

    This is where WARP’s primary purpose comes in — it uses the fact that all our OSes offer control over DNS settings as part of their VPN API because VPNs are networks, so they need the same kinds of configuration capabilities DHCP offers on physical networks. In it’s most basic setting, WARP uses the VPN APIs to configure your device to use CloudFlare’s 1.1.1.1 DNS servers over an encrypted tunnel, protecting your DNS queries from all prying eyes.

    WARP doesn’t do this using DoH though, it uses a different approach. It sets up a WireGuard VPN tunnel from your device to your nearest CloudFlare data centre, then it sends all DNS queries through that tunnel.

    This is where WARP’s optional extra feature comes in. Since you have a VPN tunnel to CloudFlare anyway, why not route all the device’s internet (not LAN) traffic through that tunnel?

    At this point you have a VPN that provides very limited and specific functionality:

    1. It takes care of the first mile problem by tunnelling all your internet traffic through an encrypted tunnel as far as CloudFlare, so it hides your browsing, email, instant messaging, etc. from your ISP, or from whoever operates the public wifi you happen to be using while you’re out and about.
    2. It provides anonymity, effectively replacing your true IP address with a CloudFlare IP address.
    3. It picks the data centre to connect the tunnel to, you don’t get to choose, and it’s intentionally as close to your actual location as possible so you appear to be coming from your actual geographic region — so no using WARP to watch British Netflix from the US 😉

    So, WARP is purely a privacy tool!

    It has some nice advantages too:

    1. You get all the basic functionality mentioned here for free. (There is an advanced version aimed at the enterprise that does more, but at a cost!)
    2. There are apps for all the major platforms (Android, iOS, Windows, Mac & Linux)
    3. It’s really simple to set up, since it basically has no settings 🙂
    4. Since so much of the internet is delivered through CloudFlare’s content delivery network (CDN), it may actually speed up your browsing a little to route all your traffic straight to the nearest CloudFlare data centre.

    If you’re already using a full-featured VPN for privacy, then WARP doesn’t offer you anything more than you have now. The only reason you might consider switching would be to simplify things because you don’t actually need the flexibility a full-featured VPN app offers.

    Deep Dive 2 — Were PassKeys Bypassed in a Phishing Attack?

    TL;DR — nope!

    Security researchers made a bit of a splash by describing a real-world attack they thought they had observed in the wild, which, if it had been true, would have demonstrated how users could be phished, even when using a PassKey as a second factor.

    What the researchers reported was seeing authentication logs from a popular cloud-based identity provider trusted by many enterprises to provide single-sign-on for their employees, which showed an account with a Passkey as a second factor being successfully phished. They literally misunderstood the logs, so the whole thing was a very embarrassing misunderstanding, but while the original story made a really big splash, the retraction went mostly unnoticed. One notable exception is Steve Gibson, who did an excellent job correcting his own initial misreporting on Security Now Episode 1036.

    Fundamentally, Passkeys are just public-private key pairs with the private key protected by strong encryption. In theory, we’ve had that kind of cryptographic functionality available for decades, but it never took off because manually managing private keys is a pain in the proverbials. What Passkeys did was unite well-established crypto with human-friendly key management.

    One of the biggest hurdles with private keys is that they’re impractical to move around securely and impossible to remember, so logging in from devices other than your own had been effectively impossible. The Passkey specification solved this with a QR-code-based secure delegation. The device you’re trying to log on from that does not have your private key displays a QR code, and you scan it from your portable device to effectively hand off the authentication task to the device that has your private key. You do the Passkey thing on your own device, but you get logged in on the device displaying the QR code.

    This flow could be open to abuse if the FIDO Alliance had not designed a strong countermeasure right into the spec. Imagine for a moment that there were no countermeasures — attackers could use a modern Adversary-in-The-Middle (AiTM) attack to real-time proxy the QR code. The process would work like this:

    1. The attacker tricks the victim into loading a fake login page where they start the authentication process.
    2. In real time they take the username, and perhaps also the password, and start a login at the real page, on that real page they request the use of a Passkey and choose the QR-code method, they then mirror that QR code to the victim on the fake login page along with some social engineering text to trick the user into scanning the code even though they might well be on their own computer, and completing the delegated Passkey authentication.
    3. The attacker would then be logged in, since they are the ones on the real login page.

    OK, so how does the Passkey specification prevent this obvious attack? Simple, the QR-code workflow requires a Bluetooth proximity check before accepting the authentication request — when you scan a Passkey QR Code, the first thing your device does is issue a cryptographic challenge over Bluetooth that only the device displaying the original QR code can pass. If the QR code you see is proxied, the challenge will fail because Bluetooth’s range is limited to a few meters! Unless your attackers are within a few feet of you, they cannot phish you!

    This is exactly what the security researchers claim to have seen, for real, in the wild. That smelled fishy to me, but I saw lots of reputable sites report the story as fact, so I assumed the Bluetooth proximity check must be in the spec as should rather than must, and that only authenticators choosing not to require Bluetooth would be vulnerable. Even then, I knew all Apple & Windows devices were safe since I knew they enforced the Bluetooth check, but I assumed there must be some other Passkey implementations in use somewhere that didn’t.

    Turns out the spec absolutely does require the check, and that the researchers were simply wrong! They sheepishly admitted as much in a follow-on blog post.

    How could that happen? Ultimately, it comes down to logs being analysed by someone or something without the needed expertise. A few years ago, I’d have assumed it was a human that was to blame, but today there’s a real possibility it was an over-reliance on AI assistance that caused the embarrassing woopsie.

    I know from personal experience that with modern authentication, you need to be really careful when interpreting authentication logs, because authentication is now a multi-step process, and just because a few of the steps succeed does not mean the overall login did!

    When you use a password as the first factor and anything else as the second factor, there will be at least two log entries for the authentication attempt — the initial username+password submission, which will succeed or fail. If it fails, there is no second step, but if it succeeds, then the server responds with a challenge of some kind for the second factor, and that challenge may have multiple steps, but it will ultimately succeed or fail, and only if that second factor also succeeds will the user get logged in.

    To properly interpret the logs, you need to know which events are part of the same authentication event. That’s why a so-called correlation ID is associated with each authentication log entry. That ID ties the pieces together, so when you’re searching the logs, you must group by correlation ID or you’ll see single factors passing as successful logins. That’s what these folks did.

    They saw a log entry for the user with a status code of success and assumed that meant the attackers got in. But they were only looking at one of two factors, and the second factor had failed every time because the Bluetooth checks were doing their job. They mistook a partial success for a complete success because they or their tools failed to group the log entries by their correlation IDs 🙁

    So, contrary to what you might have heard, no, Passkeys were not bypassed with a simple phishing page; they were carefully designed to be immune from exactly this kind of attack!

    Note that both SMS-based one-time codes and even TOTP (time-based one-time passwords from an authenticator app) are vulnerable to real-time proxying MiTM attacks, which is one of the big reasons Passkeys are objectively more secure!

    ❗ Action Alerts

    Worthy Warnings

    Notable News

    Excellent Explainers

    Palate Cleansers

    Claude Lies and then Asks Me!

    Legend

    When the textual description of a link is part of the link, it is the title of the page being linked to, when the text describing a link is not part of the link, it is a description written by Bart.

    Emoji Meaning
    🎧 A link to audio content, probably a podcast.
    ❗ A call to action.
    flag The story is particularly relevant to people living in a specific country, or, the organisation the story is about is affiliated with the government of a specific country.
    📊 A link to graphical content, probably a chart, graph, or diagram.
    🧯 A story that has been over-hyped in the media, or, “no need to light your hair on fire” 🙂
    💵 A link to an article behind a paywall.
    📌 A pinned story, i.e. one to keep an eye on that’s likely to develop into something significant in the future.
    🎩 A tip of the hat to thank a member of the community for bringing the story to our attention.
    🎦 A link to video content.

    Leave a Reply

    Your email address will not be published. Required fields are marked *

    Scroll to top