As laboratories around the world race to build out a cryptographically relevant quantum computer, we at Cloudflare are racing towards a 2029 target deadline for full post-quantum readiness. While we’ve already transitioned many of our products to post-quantum encryption, we still have work to do to support post-quantum authentication and achieve full post-quantum readiness across our platform.
We’re taking a maximalist stance (“PQ everything!”), because as an infrastructure provider to the world, we want to give our customers the peace of mind that using Cloudflare ensures that their traffic is future-proofed against quantum adversaries.
But how does one accomplish such a massive migration at an organization of our size and scale? After all, cryptography is the base layer for almost all of the world’s digital systems, including the software services and the networking protocols that power our platform.
To drive our PQ migration, we have three key goals.
First, we want to help our product and engineering teams understand how cryptography is being used and how they should be upgrading it. This should cover both the upgrades to post-quantum encryption and to post-quantum authentication. Many of our products have already been upgraded to post-quantum encryption over TLS 1.3, but we Continue reading
Twelve years ago, during Birthday Week 2014, we turned on Universal SSL and nearly doubled the number of encrypted sites on the web overnight, giving free TLS to every site behind Cloudflare, including the ones that never paid us a cent. Encryption stopped being an expensive, time-intensive undertaking and instead became the default.
For Birthday Week this year, we are taking the next step on that path. For more than a decade we have been one of the largest consumers of publicly trusted certificates on the Internet, and have never issued a single one ourselves. That is changing. Cloudflare is announcing our intent to become a public certificate authority (CA).
Today we are announcing the first concrete milestones in that effort: We have applied for inclusion in the Chrome, Apple, Microsoft, and Mozilla root programs, and we have signed a definitive agreement to acquire an established, broadly trusted root from GlobalSign, so that we can offer certificates with the widest possible device reach the day we begin issuing. We’re also announcing our plans to be one of the first CAs to serve post-quantum certificates, targeting Chrome’s recently announced Quantum-resistant Root Program.
We are not issuing certificates yet, and it will be Continue reading
Andre Toonk published yet another Internet-measuring tool: watchthenet.com tries to ping every IPv4 address every few hours (probing every /24 every 49 seconds), resulting in a rapidly updated state of the Internet. If an ISP has a bad hair day, Andre knows within minutes.
Make sure you bookmark his website and read his blog post for more details.
Almost every modern piece of network gear has some form of REST API these days. Cisco DNAC, Meraki, Palo Alto Panorama, Juniper Mist, Arista CloudVision, NetBox, and countless others. If you want to automate anything beyond SSH, you will end up talking to an API sooner or later. In this part, we will look at how to do that with Python.
We will use the requests library, which is the most popular HTTP library in the Python world. It is not built into Python, but it is so widely used that most Python developers install it by default. requests handles all the messy details of HTTP for you, headers, cookies, authentication, encoding, so you can focus on the actual work.
To keep things easy at the start, we will use a service called https://mockhttp.org/, which is a testing sandbox for HTTP requests. It has endpoints that do exactly what their name suggests, /get returns a GET response, /post returns a POST response, /status/404 returns a 404, and so on. The responses are simple JSON that echo back the details of the request you sent, which is really helpful when you are learning what is happening under the hood.
Though inter-subnet communication in a BGP
EVPN-based network between hosts happens through the anycast default gateway of
the subnet, it can use two different forwarding models: Asymmetric and
Symmetric Integrated Routing and Bridging (IRB). The basic difference between
these two IRB models is how the packet is forwarded between the ingress and
egress VTEPs.
When an ingress VTEP receives a frame whose
destination is in a different subnet from the source, the initial forwarding
operations are common to both IRB models. The VTEP performs a MAC lookup in the
local VLAN's MAC address table and resolves the anycast gateway (AGW) MAC
address. The packet is then routed toward the tenant IP-VRF, where an IP lookup
determines the route toward the destination IP address. The routing information
identifies the remote VTEP as the overlay next hop. The remote VTEP's underlay
IP address is then resolved for use as the outer VXLAN destination IP address.
This resolution can involve recursive lookup through the underlay routing
table.
The forwarding paths diverge after the ingress VTEP performs the IP lookup. In asymmetric IRB, the ingress VTEP performs an additional MAC lookup in the bridge table associated with the destination subnet. The resulting Continue reading
When I implemented prefix filters in netlab (release 1.9.0), I wanted them to match the final device configurations as closely as possible, including the one prefix per entry rule to match the device configuration sequence numbers. That worked well, but resulted in YAML bloat, since each matching prefix requires several lines of YAML.
We tried to use the same approach with ACLs but quickly gave up when we realized the port not in range operation requires multiple ACL entries on most platforms. With the matching sequence numbers paradigm gone with the wind, it made no sense to limit ourselves to one prefix per ACL entry – the initial ACL entry implementation already accepted lists of prefixes and expanded them into ACL entries.
If you have installed Python and worked on a few projects, your usual workflow probably looks something like this. Install Python, make sure pip and venv are available, create a virtual environment for each project, and use pip to install packages inside it. That is how we have been doing things throughout this series, and it works. It is what most of the Python world has been doing for years.
uv is a relatively new tool that bundles all of this into one command. It manages Python version installs, virtual environments, package installs, and dependency locking, all in a single binary. It is written in Rust, which makes it fast (like really fast). Most operations that take pip several seconds finish in milliseconds with uv.
In this part, we will start from a completely fresh Ubuntu machine (24.04) that only has the system Python installed. As you will see in a moment, we do not have pip or venv available yet, and normally we would need to install them separately before we could do anything.
Here is what is happening on the fresh Ubuntu VM. python --version fails because Ubuntu does not ship the python Continue reading
You have already used regular expressions once in this series when we told deepdiff to ignore uptime fields. I promised we would cover them properly later, and now is the time.
Regular expressions (regex for short) are a way to describe patterns in text. Instead of asking "does this string contain the exact word up?" you can ask "does this string contain any four-digit number followed by a slash and another number?" That kind of question is hard to answer with the string methods we have used so far, but regex handles it easily.
For a network engineer, regex comes up in a bunch of places. Extracting an IP address from a config line. Pulling interface names out of a log message. Parsing show output when there is no ready-made TextFSM template. Validating that a value looks like a MAC address before you use it.
Regex has a reputation for being cryptic, and honestly, it is cryptic. A complex regex pattern can look like someone leaned on the keyboard. But you do not need to master all of it to be useful. Learning even the basics unlocks a lot of what you will actually need day Continue reading
Previously I successfully did some receiving and some transmitting over the amateur radio transponder on the satellite QO-100. That is to say, my FT8 was heard by others (but not me, due to my small dish), and I successfully decoded FT8 from some others.
There are three problems with my QO-100 ground station:
I really appreciate the constant FT8 activity when tuning my station. Sure, I could look at the band edge beacons, but I like this too. And strangely, I can not actually find the edge beacons.
Today is about the third issue: Frequency stability. Because the B200 was GPS locked last time, the main suspect was the LNB. The Othernet Bullseye LNB TCXO from Passion-Radio.com is a fine LNB, but it’s Continue reading
Over time, services like DNS and email have been centralized, leaving the Internet itself much more centralized. In this episode of the Hedge, Doug Jacobson joins Tom Ammon and Russ White to discuss centralization and service consolidation.
download
