After using several post-quantum secure VPN tunnels (here and there), I was interested in how this key exchange with ML-KEM looks on the wire. Especially in direct comparison to a classical VPN setup with just ECDH (group 21). Spoiler: since it does not fit in a single packet, it has to use a new form of fragmentation. 😳 Here we go:
Continue reading Packet Capture of a Post-Quantum Site-to-Site VPN
Since we have learned the basics of post-quantum secure VPN tunnels, let’s configure a site-to-site VPN between a Palo Alto Networks firewall and a FortiGate with PQC ciphers to verify vendor interoperability. Spoiler: it works like a charm. ;)
Continue reading PQC VPN-Tunnel between Palo Alto <-> FortiGate
As the advent of practical quantum computing draws closer, security vendors are increasingly introducing post-quantum cryptographic (PQC) algorithms to protect existing security architectures against future threats. One important use case is site-to-site VPN connectivity, where organisations must address the “harvest now, decrypt later” risk – the possibility that encrypted traffic captured today could be decrypted by quantum computers in the future.
To mitigate this threat, Palo Alto Networks has implemented several approaches for quantum-resistant VPN tunnels, including Post-Quantum Preshared Keys (PPK), Key Encapsulation Mechanisms (KEM), and Quantum Key Distribution (QKD). Each method offers a different balance of security, complexity, and operational requirements.
In this blog post, we will examine these approaches in detail, with a particular focus on KEM-based solutions, which are generally considered the preferred path forward. We will also demonstrate how to configure a site-to-site VPN tunnel that combines traditional Diffie-Hellman (DH) key exchange with post-quantum algorithms such as Kyber (standardised by NIST as ML-KEM), providing both classical and quantum-resistant security.
I had a use case where I wanted to use the SSL Inbound Inspection on a Palo, but with a different X.509 certificate than the one on the server itself. That is: the backend server has its self-signed (or internal PKI-signed) certificate along with its hostname, while the decryption policy on the Palo uses a publicly trusted signed certificate for the same hostname. Just like a reverse proxy / load balancer / WAF.
Continue reading Palo Alto Networks NGFW “SSL Inbound Inspection” with different Certificate
Did you know that you can easily decrypt TLS (mostly HTTPS) traffic with Wireshark? Well, only if you have the keys. ;) This really is a game-changer if you’re stuck with troubleshooting encrypted data. Let’s do an example:
I had a hard time figuring out how to configure OSPFv3 authentication on a Palo Alto Networks NGFW due to its different configuration formats compared to a Cisco router.
TL;DR: The SPI must be set in hexadecimal, while the actual key (40 chars, hexadecimal) must be grouped in 5 sections, separated with hyphens.
Continue reading OSPFv3 Authentication on a Palo Alto (Logical Router)
This post guides through a basic DNS tunneling setup with the usage of the appropriate tool “iodine“. It shows how DNS tunneling works and lists the commands needed to run this type of attack. That is, you can tunnel IPv4 packets through this DNS channel via the (internal) recursive DNS resolver! Nice approach. ;)
In the end, I’m pointing out how to block these tunnelling attempts with the DNS appliances from Infoblox, and the firewalls from Palo Alto Networks and Fortinet.
On the Internet, it’s not only “always DNS” – it’s also about securing DNS. DNS faces a wide range of attack vectors, each requiring different defensive strategies. Here comes an overview of DNS security, which gives you all the keywords at a glance.
I was presenting at the annual “Wireshark Developer and User Conference“, the SharkFest’25 EU, talking about “Securing DNS – Attacks and Defences“. It covered all the buzzwords related to DNS security, such as malware using DNS, DNS spoofing, DNS exfiltration & tunnelling, while defending them with the keywords as DNSSEC, DoH/DoT, feeds & blocklists, and so on.
Quite many techniques. ;) Luckily, the whole session was recorded. So if you’re interested, have a look!
While I was working on my presentation about “Secure DNS” for this year’s SharkFest, the Wireshark Developer and User Conference, I recognised that I’m still missing some DNS-related packet captures in the Ultimate PCAP, that is DNS over TLS and DNS over HTTPS. And while working on it with the DNSDiag toolkit (thanks, Babak!), I came across DNS over QUIC and DNS over HTTP/3. 😂 Here we go:
I was faced with an interesting customer requirement: An existing guest Wi-Fi should be prefaced with a welcome page for accepting the terms and conditions. Since there was already a Palo Alto Networks firewall in place, could we perhaps use its captive portal directly for this purpose? It’s not about authenticating the users, but only for a single webpage with a simple check button that should appear once a month per device.
TL;DR: While we were able to redirect every device to a welcome page, we were not able to extend the lifetime of those sessions to longer than 24 hours. This might fit for short-term guest Wi-Fis, but is not appropriate for long-term connections aka BYOD. However, this is how we have done it:
Continue reading Misusing Palo’s Captive Portal as a Guest Wi-Fi Welcome Page
Email is still the most common communication protocol on the Internet. And since I was missing some variants of the related protocols, IMAP, POP3, and SMTP in the Ultimate PCAP, I did some captures. ✅ Here are a few details.
Again two more commonly used network protocols for the Ultimate PCAP: the Remote Authentication Dial-In User Service (RADIUS) and the Terminal Access Controller Access-Control System Plus (TACACS+) protocols. Captured with quite some details:
At SharkFest’22 EU, the Annual Wireshark User and Developer Conference, I attended a beginners’ course called “Network Troubleshooting from Scratch”, taught by the great Jasper Bongertz. In the end, we had some high-level discussions concerning various things, one of them was the insight that TCP RSTs are not only sent from a server in case the port is closed, but are also commonly sent (aka spoofed) from firewalls in case a security policy denies the connection. Key question: Can you distinguish between those spoofed vs. real TCP RSTs? Initially, I thought: no, you can’t, cause the firewalls out there do a great job.
It turned out: you can!
This post is about adding an own (trusted) X.509 certificate for the HTTPS GUI of the Cisco Application Policy Infrastructure Controller aka APIC. You can do this via the GUI itself or via the API. Here are both ways: