You know Herman, I was looking at the digital landscape this morning, specifically how we try to protect our infrastructure here in Israel, and I realized something kind of funny. We spend so much time talking about digital borders and firewalls as if they are these massive stone walls, like the ones we see around the Old City here in Jerusalem. But in reality, the way most people use them, they are more like a screen door with a polite sign that says please do not enter if you are from a specific zip code. It is a psychological comfort more than a physical barrier. We see these maps with red zones and green zones, and we think that by clicking a button to block a country code, we have somehow built a fortress. But the wind just blows right through a screen door, doesn't it?
That is a perfect analogy, Corn. Herman Poppleberry here, and you are hitting on what I like to call the great geo-blocking fallacy. It is this persistent myth that if you just draw a line on a digital map and say no traffic from this country allowed, you have actually secured something. Our friend Daniel was asking about this recently, specifically how defenders, especially those in high-pressure environments like the ones we see around Israeli government sites, actually deal with the fact that these digital borders are essentially invisible to anyone with a few dollars and a half-decent proxy. We are living in March of twenty-twenty-six, and the tools available to even a hobbyist hacker make simple IP-based blocking look like trying to stop the tide with a plastic bucket.
It is a fascinating question because it exposes the gap between what makes a manager feel safe and what actually stops a motivated adversary. If you are a nation-state actor sitting in a room halfway across the world, and you see a four-hundred-three forbidden error because your IP address is from a blacklisted region, you do not just pack up and go home. You do not say, oh well, the firewall is too strong today. You just click a button, route your traffic through a residential gateway in Tel Aviv or New York, and suddenly, to the web application firewall, you look like a guy sitting in a coffee shop down the street ordering a latte.
And that is why we need to have a real conversation about moving beyond the where and focusing on the what and the how. Because as of early twenty-twenty-six, the sophistication of these residential proxy networks has reached a point where standard geo-IP databases are almost entirely ineffective for anything beyond stopping low-level noise. We are talking about a massive shift in the threat landscape. According to the latest industry data, over seventy percent of nation-state-backed web attacks now utilize these residential proxies. They are not using data centers with known IP ranges; they are using compromised internet of things devices, home routers, and even smart refrigerators located right in the target country. If you are a defender in Jerusalem and you see an attack coming from an IP address assigned to a residential apartment in Haifa, your geo-block is worse than useless—it is misleading.
So if the map is a lie, what are we actually looking at? If I am a defender managing a WAF, a web application firewall, and I cannot trust the IP address to tell me the truth about the origin, what are the signals that actually matter? I want to dig into the nuance here because I think most people think it is just a game of cat and mouse with IP addresses, but it feels like the real battlefield has shifted to the protocol level and the behavioral level. We need to talk about what happens when the identity of the user is no longer tied to their location, but to the digital signature of their machine and the way they interact with the server.
It absolutely has. The first thing we have to talk about, and this is where it gets really nerdy and exciting, is TLS fingerprinting. Specifically things like JA3 and the newer JA3S fingerprints. Think of it this way: an IP address is like a return address on an envelope, which can be faked with a bit of white-out and a pen. But the TLS fingerprint is like the handwriting, the specific type of paper, and the way the envelope was folded. It tells you exactly what kind of software is making the request, regardless of where the request claims to be coming from. Even if an attacker is sitting in a bunker in a hostile nation, their computer still has to negotiate an encrypted connection with your server. And the way it does that is incredibly revealing.
That is interesting. So even if the attacker is routing through a local IP, they are still using specific tools to launch their attack. They might be using a customized Python script, or a specific version of a headless browser, or a known exploitation framework like Metasploit or Cobalt Strike. And each of those has a unique way of negotiating the encrypted connection, right? It is like they are wearing a uniform even if they are standing behind a local mask.
Precisely. When a client connects to a server via HTTPS, it sends what is called a Client Hello packet. This packet contains a bunch of technical details—the versions of SSL or TLS it supports, the cipher suites it prefers, the extensions it wants to use, and even the elliptic curve formats it understands. In a standard browser like Chrome or Firefox, those settings are very specific and they do not change much from version to version. But an automated tool, or a botnet client, often has a very different, very distinct set of parameters. JA3 takes those five specific fields from the Client Hello, concatenates them into a string, and produces a simple MD5 hash. That hash is your fingerprint.
So as a defender, I can look at my traffic and say, okay, this request is coming from a legitimate-looking Israeli IP address, but its JA3 hash matches a known scraping tool or a specific vulnerability scanner that we have seen used by hostile actors before. At that point, the geographical location becomes totally irrelevant. I do not care if they are in Tel Aviv or Timbuktu; I know they are using an attack tool.
Right. And what is even more powerful is that modern platforms like Cloudflare have integrated this directly into their bot management engines. They have these massive databases of millions of known fingerprints. So they can tell you with a high degree of confidence, hey, this might look like a person on a mobile phone in Jerusalem, but the underlying TLS handshake is identical to a bot we have seen performing credential stuffing attacks on ten thousand other websites this morning. That is a massive shift from static rules to dynamic intelligence. It is about identifying the actor by their tools, not their supposed location.
I remember we touched on some of the early versions of this back in episode seven hundred thirteen when we were looking at that Radware report on Israel being a global testing ground for these kinds of attacks. Back then, it felt like a bit of a dark art, but now it seems like standard operating procedure for any high-security site. The Radware report was really eye-opening because it showed that attackers often use the Middle East as a laboratory. They test their bypass techniques against Israeli infrastructure because they know the defenses here are top-tier. If they can get past a WAF in Jerusalem, they can get past one anywhere. But Herman, what about the actors who are sophisticated enough to spoof those fingerprints? If they can mimic a standard Chrome browser perfectly, does TLS fingerprinting still hold up?
It is a constant arms race, Corn. Sophisticated actors can absolutely use tools like TLS-client or modified versions of Playwright to try and mimic a legitimate browser fingerprint. They can essentially forge the handwriting. But this is where we move into the next layer of the defense stack, which is behavioral analysis and what Cloudflare calls their bot score. This is not just about the handshake; it is about how the client interacts with the page once the connection is established. This is where we look for the human element, or the lack thereof.
You are talking about things like mouse movements, keystroke dynamics, and how the browser actually renders the page, right? I have heard about systems that can detect if a mouse is moving in a straight line, which humans almost never do, or if a form is being filled out faster than a human could possibly type.
Yes, but it goes even deeper than that in twenty-twenty-six. Think about the physics of a human interaction. A human moving a mouse has a certain amount of jitter, a certain acceleration curve, and a certain amount of hesitation. A bot, even a sophisticated one, often has movements that are too perfect, or too randomized in a way that does not match human biology. But even beyond the mouse, there is the timing of the requests. If a client is requesting twelve different assets from your server in a perfectly rhythmic pattern, that is a bot. Humans are messy. We are distracted. We click things, then we wait, then we scroll, then we hover over a picture of a cat for three seconds before moving on.
It is funny to think that our human messiness is actually a security feature. Our inability to be perfectly efficient is what proves we are real. But I imagine that for a defender, analyzing that in real-time for every single visitor is a massive computational challenge. How do you do that without slowing the site down to a crawl? If I have to wait five seconds for the server to decide if I am a human, I am just going to close the tab.
That is the beauty of the edge architecture. When you use a service like Cloudflare, this analysis is happening at the edge node closest to the user. They are using machine learning models that have been trained on trillions of requests. They are looking for signals like the HTTP version, the order of the headers, and even things like the TCP window size. There was a huge update in January of twenty-twenty-six to the Cloudflare WAF engine that introduced improved HTTP-three fingerprinting. Since HTTP-three is built on QUIC and handles encryption and transport differently than traditional TCP-based TLS, it provides even more granular client identification. It looks at how the QUIC streams are prioritized and how the connection is established at the UDP level. It is much harder for an attacker to spoof the entire transport stack than it is to just spoof a browser header.
So we have gone from where are you to what are you, and now we are at how are you behaving. But let us look at the practical reality for a government site here. They have a mandate to be accessible to citizens but they are under constant barrage. If they just rely on these automated scores, what is the risk of false positives? I mean, what if someone has a weird browser extension or an old operating system that makes them look like a bot? Or what if someone is just a very fast typer?
That is the big fear, right? You do not want to block a legitimate citizen from accessing their health records or paying a bill just because their browser fingerprint is a bit non-standard. This is where the concept of the managed challenge comes in, and it is a huge improvement over the old-school geo-block. Instead of a hard block, where you just say access denied because you are on a VPN or in a suspicious region, you issue a challenge.
Like a CAPTCHA? Because those are getting pretty annoying, and honestly, AI can solve most of them now anyway. I feel like I spend half my life clicking on traffic lights and crosswalks just to prove I am not a robot, only to be told I missed a pixel of a bicycle.
The old CAPTCHAs are dead. AI can solve them faster and more accurately than humans in most cases. What we have now are things like Cloudflare Turnstile or other private access tokens. These are often invisible to the user. The browser has to solve a complex mathematical puzzle in the background to prove it has a real rendering engine and a real CPU. It might take half a second, and the user never even sees it. It is checking for things like the presence of specific web APIs that only a real browser would have. If the browser fails the challenge, then you know it is a headless script or a basic bot. It is a way of saying, okay, I do not quite trust you yet, so prove you have the computational resources of a real device.
So instead of a digital wall, we have a series of invisible speed bumps. If you are a normal user, you do not even feel them. If you are a bot, you hit them and you stall out because your script isn't designed to solve those puzzles or it would be too expensive to do so at scale.
Right. And you can layer these challenges based on risk. Maybe you do not block traffic from a specific country, but you say, okay, any traffic coming from this specific ASN, which is an Autonomous System Number, or this specific internet service provider that is known to host a lot of residential proxies, they have to pass a much harder challenge. Or maybe they are limited to a much lower rate of requests. This is rate limiting based on session-level anomaly scoring, rather than just IP. You are tracking the behavior of the session across multiple IP addresses.
This reminds me of our discussion in episode five hundred thirty-seven about the architecture of secrecy and zero trust. It feels like we are applying zero trust principles to the public web. You do not trust the connection just because it came through the front door or because it has a local IP; you are constantly verifying the identity and the intent of the client at every step. You are assuming the perimeter is already compromised.
That is exactly what it is. It is the death of the perimeter. We have to assume the perimeter is already breached, or rather, that the perimeter does not exist. Especially for administrative endpoints. If you are a government worker trying to log into a sensitive backend system, you should not be relying on a WAF rule that says only allow IPs from the office. That is the old way of thinking. You should be using mutual TLS, or mTLS.
Can you explain mTLS for people who might be familiar with standard TLS but have not seen it used in this context? How does it differ from the green padlock we see in our browser?
Sure. In standard TLS, the server proves its identity to the client—that is how you know you are actually at your bank's website and not a fake one. The server shows its certificate, and your browser says, okay, I trust you. In mutual TLS, the client also has to provide a certificate to the server. It is a two-way street. So before a single byte of application data is even sent, before the login page even loads, the server and the client have both verified each other's cryptographic identities. If the client does not have the correct certificate installed on their device, the connection is dropped immediately at the protocol level. It does not matter if the attacker has the correct username and password; without that certificate, they cannot even talk to the server.
That seems like the ultimate solution for those high-risk administrative ports. It is like having a key that only fits one specific lock, and the lock won't even show you the door unless you have the key. But obviously, you cannot do that for the general public. You cannot give every citizen a cryptographic certificate to install on their phone just to check the weather or pay a parking fine.
No, you cannot. But you can use identity-aware proxies for the next level down. This is where you put a layer between the internet and your application that requires a successful login through a trusted identity provider—like a government ID system or a corporate single sign-on—before the traffic even reaches the application server. This moves the defense from the network layer up to the identity layer. It doesn't matter what your IP is; it matters who you are and if you can prove it through a trusted third party.
I want to go back to something you said earlier about residential proxies because I think this is the part that really blows people's minds. Most people think of a hacker as someone using a VPN like NordVPN or something they saw an ad for on a YouTube video. But you are saying that is child's play for a nation-state. They are using our own devices against us.
Oh, absolutely. A VPN IP is very easy to identify. Most data centers and VPN providers have specific IP ranges that are publicly known and listed in databases. If I see traffic coming from a known VPN exit node, I can just flag that as suspicious immediately. But a residential proxy is different. There are companies out there—some legitimate, some very much not—that have built networks of millions of home IP addresses. Sometimes they do this by paying people to install an app that shares their bandwidth, but more often, it is a botnet of infected devices. We are talking about millions of nodes.
So if I am a defender, I might see a request that looks like it is coming from a smart toaster in a suburb of Tel Aviv. And to my WAF, that looks like a perfectly legitimate domestic user. It is not coming from a data center in a foreign capital; it is coming from a residential ISP like Bezeq or Hot.
And this is why threat intelligence feeds are so critical. You need to be subscribed to feeds that are tracking these exit node clusters in real-time. These are lists of IPs that have been observed acting as proxies. But even then, the IPs rotate so fast that the list is obsolete in an hour. That is why the behavioral stuff we talked about—the JA3 fingerprints, the mouse movements, the header ordering—is the only thing that actually scales. You have to be able to spot the bot regardless of the IP it is hiding behind.
It really highlights why the old-fashioned geo-blocking is so lazy. It is a feel-good measure. It allows someone to go to their boss and say, look, we blocked all traffic from these five hostile nations. And the boss feels safer, they sleep better at night, even though the actual threat actors from those nations are just laughing and routing their traffic through a server in the next town over. It is security theater.
It is worse than lazy, Corn, it is a false sense of security that can lead to negligence in other areas. If you think your geo-block is protecting you, you might not be as diligent about patching your software or implementing strong authentication. It is like locking your front door but leaving the windows wide open and thinking you are safe because you have a very sturdy lock. In twenty-twenty-six, the attackers are coming through the windows, the vents, and the chimney.
So, for the defenders listening, especially those who might be working in high-target regions or for organizations that are constantly in the crosshairs, what is the actual roadmap? If we are saying geo-blocking is a fallacy, what is the alternative that actually works in twenty-twenty-six? Give us the practical steps.
The first step is to change your mindset from blocking to challenging. Instead of a blanket block on a country, you set your WAF to issue a managed challenge to all traffic from high-risk regions or suspicious ASNs. This filters out the automated noise while keeping the door open for legitimate users who might be using a VPN for privacy or who are traveling. You want to increase the friction for the attacker without ruining the experience for the user.
And what about the fingerprinting? How do you actually implement that if you are not a giant tech company with a thousand engineers?
If you are using a platform like Cloudflare, you should be enabling their bot management features and specifically looking at the bot score. You can write rules that say: if the bot score is below thirty, which means it is almost certainly a bot, just block it. If it is between thirty and sixty, which is the gray area, issue a challenge. If it is above sixty, let it through. You can also create custom rules based on JA3 hashes. If you see a specific hash that is associated with a known attack tool, you block that hash regardless of what IP it is coming from. It is about being surgical rather than using a sledgehammer.
I also think it is worth mentioning the importance of rate limiting at the session level. We used to rate limit by IP, but with residential proxies, that does not work because each request might come from a different IP. So you have to track the session—maybe through a cookie or a persistent TLS connection—and say, this session is requesting too many pages too fast, even if the IPs are changing every few seconds.
That is a great point. Session-level tracking is much harder for an attacker to spoof because they have to maintain state across all those different proxy nodes. It increases their operational cost significantly. And that is really the goal of all of this, isn't it? We are not trying to make an attack impossible—nothing is impossible for a motivated nation-state with unlimited resources and time. We are trying to increase the cost of the attack until it is no longer worth it, or until they make a mistake that allows us to detect them. We want to make them work for every single request.
It is about friction. You want to be the most annoying, most expensive target in the neighborhood. If you make it hard for them to use their automated tools, if you force them to use human operators to solve challenges, if you force them to constantly rotate their infrastructure and rewrite their scripts, you are winning the war of attrition.
And for the really sensitive stuff, the message is clear: get off the public web. If it is an administrative interface, if it is a database backend, it should be behind an identity-aware proxy or require mTLS. There is no reason for a database management portal to be accessible to anyone on the internet, even with a password. If you can't see the door, you can't kick it down.
You know, it is interesting to see how this connects back to what we talked about in episode one thousand three, about the sky being a snitch and how geolocation has changed. Back then we were talking about physical geolocation through photos and horizons, but this is the digital version of that. The digital horizon is blurring because of these proxies, and we have to look for much more subtle clues to figure out where we actually are and who we are talking to. We are looking at the digital DNA rather than the digital address.
It is all part of the same trend, Corn. As our digital and physical worlds become more integrated, the traditional markers of identity and location are breaking down. We are moving into a world where identity is proven through behavior and cryptography, not through a return address on a packet or a mountain range in the background of a photo. The map is no longer the territory.
So, to summarize for our listeners who might be looking to audit their own security posture: step one, look at your WAF and see how much you are relying on simple geo-blocking. If that is your primary defense, you are vulnerable. Step two, start exploring behavioral challenges and TLS fingerprinting. Move from hard blocks to smart challenges. Step three, for anything sensitive, implement zero trust and identity-aware proxies. And step four, stay updated on the latest protocol shifts, like the move to HTTP-three.
And do not forget to keep your threat intelligence up to date. You need to know what the latest fingerprints look like and which residential proxy networks are currently active. It is a full-time job, which is why using a large-scale provider who sees all this traffic across millions of sites is usually more effective than trying to build it all yourself. You want to benefit from the collective intelligence of the entire network.
This has been a really enlightening deep dive, Herman. It is easy to get caught up in the headlines about cyber warfare and forget that it often comes down to these very technical, very specific battles over protocol handshakes and mouse movements. It is a war of centimeters and milliseconds.
It is the front line, Corn. And here in Jerusalem, we see it every day. The sophistication of the attacks being leveled against Israeli infrastructure is truly staggering, but it also means the defenses being developed here are some of the most advanced in the world. It is a fascinating place to be if you are a nerd like me who loves a good challenge.
Well, I am glad I have you to translate all that nerdery for me. And I hope our listeners found this as useful as I did. If you are enjoying the show and finding these deep dives helpful, we would really appreciate it if you could leave us a review on your podcast app or on Spotify. It genuinely helps other people find the show and helps us keep doing this. We are almost at a thousand episodes, and every review counts.
It really does. We love seeing those reviews come in, and we read every single one. And remember, you can find all our past episodes, all nine hundred ninety-three of them now, at our website, myweirdprompts.com. There is an RSS feed there for subscribers and a contact form if you want to get in touch with us or send in your own prompt.
Thanks again to Daniel for sending in this prompt. It gave us a lot to chew on and really forced us to look at the reality of modern defense. I think I am going to go double-check the WAF settings on my own little server now, just to be safe. I don't want any smart toasters poking around in my files.
Good idea, Corn. You never know who might be trying to poke at your screen door. And remember, even a small site can be a target if it is part of a larger campaign.
Fair point. Alright, that is it for this episode of My Weird Prompts. We will be back next time with another deep dive into whatever weird and wonderful topics come our way.
Until next time, stay curious and stay secure.
Thanks for listening. Bye for now.
Goodbye.
You know Herman, before we go, I was just thinking about that residential proxy thing again. It is wild to think that someone's smart fridge could be part of a nation-state cyberattack. Imagine your fridge is helping a hacker while you are just trying to decide what to have for dinner. It is the ultimate betrayal by your kitchen appliances.
It is the world we live in, Corn. Every sensor is a potential weapon. Every connected device is a potential jumping-off point. That is why the behavioral stuff is so important. Your fridge doesn't move a mouse. Your fridge doesn't scroll through a page. It just sends data in a very predictable way. When we start looking for those human signals, the fridge becomes very easy to spot, no matter how many proxies it uses.
That is a comforting thought, I guess. My fridge is a snitch, but at least it is a bad one. It doesn't have the human touch.
It lacks the nuance of a human being.
Alright, let us wrap this up. Thanks again, everyone. We will talk to you soon.
Take care.
So, we talked about the JA3 fingerprints, but what about the newer stuff? You mentioned HTTP-three. How does that change the game for fingerprinting? Is it just a faster version of the same thing?
Well, HTTP-three is built on top of QUIC, which is a UDP-based protocol. Traditional TLS happens at the TCP layer, but in HTTP-three, the encryption is integrated much more tightly into the transport layer. This means there are even more unique parameters to look at—things like the flow control settings, the maximum number of concurrent streams, and how the client handles packet loss. It is like going from analyzing someone's handwriting to analyzing their DNA. It is much harder to fake because it is baked into the very way the data moves.
So even if an attacker manages to perfectly mimic a Chrome browser's TLS handshake, they might still mess up the QUIC parameters. They might be too efficient or handle congestion in a way that a standard browser wouldn't.
Each layer of the stack provides another opportunity for the defender to spot an anomaly. And because these protocols are so complex, it is very difficult to get every single detail right. Most attackers will take shortcuts to save time or resources, and those shortcuts are what get them caught. They might get the headers right but get the transport layer wrong.
It is the attention to detail that wins the war. It is about being more meticulous than the person trying to break in.
It always is. In cybersecurity, the devil is not just in the details; the devil is the details.
That is a good line. You should put that on a t-shirt, Herman.
Maybe I will. Along with a picture of a very suspicious-looking smart fridge with a hacker hoodie on.
I would buy that. Alright, let us actually go this time. Thanks for the extra insight, Herman.
Any time, Corn.
This has been My Weird Prompts. We will see you in the next one.
Bye everyone.
You know, I was just thinking about one more thing—the false positive rate on those behavioral challenges. If we are looking for human jitter, what about people with accessibility needs? People who use screen readers or alternative input devices? Do they get flagged as bots because they don't move a mouse in the traditional way?
That is a really important point, Corn, and it is something the engineers at companies like Cloudflare and Google spend a lot of time on. They have to train their models on a wide variety of human behaviors, including those who use assistive technologies. A screen reader, for example, interacts with the Document Object Model in a very specific way that is different from a bot. A bot is trying to extract data as fast as possible; a screen reader is trying to present data to a human in a logical order. The patterns are different. But you are right, it is a delicate balance. You never want security to come at the cost of accessibility.
It is a reminder that even in this high-tech world of AI and cryptography, the human element is still at the center of everything. We are building these systems for people, and we have to make sure they still work for everyone, regardless of how they interact with the web.
Security that excludes people is not really security; it is just another kind of barrier. The goal is to keep the bad guys out while making sure the door is wide open for everyone else.
Well said. Alright, for real this time, thanks for listening to My Weird Prompts. We will catch you in the next episode.
See you then.
Bye.
Goodbye.
Hey Herman, do you think we should mention the Radware report again? Just to give people a sense of the scale of what we are talking about? I mean, the numbers in that report were pretty staggering.
We could, but I think the point is made. The key takeaway is that the threat landscape is constantly evolving, and if you are still using tools from five years ago, you are already behind. The Radware report was a wake-up call, but the real work happens every day in the WAF configurations and the zero trust policies. It is about constant vigilance.
True. It is the steady, quiet work that keeps things running. The stuff that doesn't make the headlines.
No one notices when the security is working perfectly. They only notice when it fails. It is a thankless job in many ways.
The unsung heroes of the digital age.
That is us. Or at least, the people we are talking to. The ones in the trenches.
Well, to all those unsung heroes out there, keep up the good work. We see you, and we appreciate what you do.
We definitely do. Alright, let us sign off.
See you at the house, Herman.
See you there, Corn.
Bye everyone.
Bye.
