Security Now 1010: DNS over TLS

Summary

Podcast Summary: Security Now Episode 1010 – DNS over TLS

Release Date: January 29, 2025

Hosts: Leo Laporte & Steve Gibson

---

1. Introduction to the Episode

In this episode of Security Now, hosts Leo Laporte and Steve Gibson delve into a range of critical security topics, focusing primarily on DNS over TLS. The discussion is enriched with real-world examples, listener feedback, and insightful analysis of recent security incidents affecting major corporations and individual users alike.

---

2. MasterCard's Five-Year DNS Typo

A significant portion of the episode is dedicated to a startling revelation regarding MasterCard's DNS configuration.

• The Issue: MasterCard had a five-year-old typo in its DNS settings. This misconfiguration, as reported by security researcher Philippe Catoregli, could have allowed cybercriminals to intercept or divert internet traffic for MasterCard by registering an unused domain name.

  • Steve Gibson highlights, "This tiny but potentially critical typo was discovered recently by Philippe Catoregli, founder of the security consultancy Ceralis S." [06:30]

• Discovery and Impact: The typo persisted from June 30, 2020, until January 14, 2025, unnoticed until Catoregli registered the domain akam.ne to prevent its exploitation.

  • Steve Gibson elaborates, "Philippe enabled a DNS server on akam.ne and noticed hundreds of thousands of DNS requests hitting his server each day from locations around the globe." [09:40]

• MasterCard's Response: MasterCard acknowledged the mistake but assured there was no risk to their systems.

  • Steve Gibson remarks, "MasterCard acknowledged the mistake but said there was never any real threat to the security of its operations." [16:45]

• Implications: This incident underscores the potential vulnerabilities introduced by minor configuration errors and the importance of diligent DNS management.

---

3. Script Kiddies Fall Prey to Trojanized RAT

The episode also sheds light on a deceptive cybersecurity threat targeting novice hackers.

• The Attack: A malicious actor distributed a tainted version of the Exwyrm RAT builder, specifically targeting script kiddies eager to build their own botnets.

  • Steve Gibson explains, "These script kiddies think they're getting a RAT builder tool, but instead, they're installing malware on their own systems." [38:12]

• Scale and Impact: Over 18,459 devices globally were compromised, with significant activity in countries like Russia, the USA, India, Ukraine, and Turkey.

  • Steve Gibson notes, "These wannabe hackers are being hacked themselves, installing malware they believe is a tool to enhance their hacking capabilities." [42:59]

• Malware Functionality: The Trojanized RAT can exfiltrate sensitive data, perform keylogging, and even launch disruptions within infected systems.

  • Steve Gibson states, "Browser credential theft allows actual attackers to impersonate users on any websites where they're logged in." [42:59]

• Conclusion: This incident highlights the dangers of engaging with unverified cybersecurity tools and the cunning tactics employed by seasoned threat actors to exploit the ambitions of less experienced hackers.

---

4. Explosion of DDoS Attacks

DDoS (Distributed Denial of Service) attacks continue to surge, posing significant challenges to internet infrastructure.

• Record-Breaking Attack: Cloudflare reported handling a 5.6 terabit per second (Tbps) UDP DDoS attack, the largest ever recorded, lasting only 80 seconds.

  • Steve Gibson comments, "Cloudflare successfully detected and blocked a 5.6 Tbps DDoS attack, keeping the targeted site online without any performance degradation." [52:08]

• Increase in DDoS Activity: In 2024, Cloudflare blocked 21.3 million DDoS attacks, marking a 53% increase from the previous year. Additionally, there was a 1,885% quarterly growth in hypervolumetric attacks exceeding 1 Tbps.

  • Steve Gibson states, "Nearly 5,000 DDoS attacks per hour were blocked, illustrating the relentless nature of these assaults." [52:04]

• Implications: The rapid escalation in both the frequency and volume of DDoS attacks underscores the urgent need for robust mitigation strategies and advanced defense mechanisms to protect online services.

---

5. Let's Encrypt Introduces 6-Day Certificates

Security enhancements in web encryption protocols were another focal point of the discussion.

• New Offerings: Let's Encrypt announced the introduction of six-day lifetime certificates, alongside their existing 90-day certificates, to bolster web security.

  • Steve Gibson explains, "Let's Encrypt is offering short-lived certificates to improve the security of the web PKI." [125:57]

• Technical Challenges: Implementing shorter certificate lifetimes introduces complexities, such as increased load on certificate authorities and potential connectivity disruptions during renewals.

  • Steve Gibson elaborates, "Shortening certificate lifetimes requires scaling up infrastructure to handle more frequent renewals, which can be burdensome for service providers." [124:00]

• Timeline: The phased rollout began in February 2025, with general availability expected by the end of the year.

  • Steve Gibson notes, "We expect to make short-lived certificates generally available by the end of 2025." [125:57]

• Conclusion: While the move towards shorter certificate lifetimes aims to enhance security by reducing the window of vulnerability from compromised certificates, it necessitates careful implementation to avoid service disruptions.

---

6. Spinrite and the 8-Terabyte Drive Failure

An intriguing user story highlights the reliability of modern storage solutions.

• User Experience: A Spinrite user reported that while testing four Western Digital Red 8TB drives using Spinrite Level 3, one drive exhibited significant failures midway through the process.

  • Steve Gibson describes, "One of the four 8TB drives started showing problems at 94% completion, indicating severe issues with that particular drive." [71:32]

• Spinrite's Role: Spinrite, a renowned storage maintenance utility, effectively diagnosed the failing drive by analyzing SMART (Self-Monitoring, Analysis, and Reporting Technology) data.

  • Steve Gibson explains, "The SMART parameters like ECC error correction and sectors relocated were drastically reduced, signaling imminent drive failure." [72:00]

• Insights: This case underscores the importance of proactive storage diagnostics and the utility of tools like Spinrite in ensuring data integrity and drive performance.

---

7. Listener Feedback and Discussions

a. EM Client Adoption:

Listeners shared their positive experiences transitioning to EM Client, highlighting its user-friendly interface and robust feature set, including support for end-to-end encrypted GNU PG email and address books.

• Dan Taylor positively remarks, "It's wonderful! I only got a 32GB drive for the price, and I'm thoroughly impressed." [94:18]

b. One-Time Password (OTP) Security Concerns:

A listener questioned the strength of OTPs, suggesting that with sufficient resources, an attacker could brute force OTPs despite the system's throttling mechanisms.

• Steve Gibson responds, "It's crucial for servers to implement strict throttling to mitigate such brute force attempts." [95:08]

c. Syncthing and UDP Hole Punching:

Joe Havelatt inquired about Syncthing's resilience without Tailscale, attributing its functionality to STUN protocols facilitating direct connections.

• Steve Gibson acknowledges, "Syncthing's ability to establish direct connections without Tailscale is a testament to its efficient use of NAT traversal techniques." [95:35]

d. Email Spam Mitigation:

Jason raised concerns about increasing spam with long-standing email addresses. Steve shared his strategy of annually rotating email addresses, significantly reducing spam influx.

• Steve Gibson advises, "Changing your email address periodically and forwarding old addresses can drastically reduce spam without losing important communications." [71:32]

---

8. Conclusion and Final Thoughts

The episode concludes with reflections on the evolving landscape of internet security, emphasizing the balance between enhanced privacy measures and maintaining system performance. The hosts reiterate the importance of staying informed and proactive in adopting best security practices.

• Steve Gibson sums up, "Encrypting DNS queries adds a layer of privacy but introduces complexities that demand robust infrastructure to manage effectively." [125:57]

• Leo Laporte adds, "Understanding these changes is crucial for both individual users and organizations to navigate the increasingly complex security environment." [159:32]

The episode serves as a comprehensive exploration of current security challenges and advancements, providing listeners with actionable insights to bolster their cybersecurity defenses.

---

Notable Quotes:

• Steve Gibson: "These script kiddies think they're getting a RAT builder tool, but instead, they're installing malware on their own systems." [38:12]

• Steve Gibson: "Cloudflare successfully detected and blocked a 5.6 Tbps DDoS attack, keeping the targeted site online without any performance degradation." [52:08]

• Steve Gibson: "Let's Encrypt is offering short-lived certificates to improve the security of the web PKI." [125:57]

• Steve Gibson: "Changing your email address periodically and forwarding old addresses can drastically reduce spam without losing important communications." [71:32]

---

Conclusion:

Security Now Episode 1010 provides an in-depth analysis of pressing security issues, from DNS vulnerabilities and sophisticated malware campaigns to the implications of enhanced encryption protocols. Through expert commentary and engaging discussions, the hosts equip listeners with the knowledge to navigate the complex and ever-evolving landscape of cybersecurity.

Transcript

[Leo Laporte]

It's time for Security Now. Steve Gibson is here. What an amazing find. A five year old typo in MasterCard's DNS. They say that's no problem, but is it no problem really? Also 18,459 script kiddies get pwned. And then is it possible that neural nets, Neural nets like our own brains could. I know. Attention could wander. Squirrel Steve talks about that a whole lot more. Next on Security now.

[Steve Gibson]

Podcasts you love.

[Leo Laporte]

From people you Trust. This is TWiT. This is Security now with Steve Gibson. Episode 1010, recorded Tuesday, January 28, 2025. DNS over TLS. It's time for Security now the show we cover the latest security news. Privacy news. Help you protect yourself and your company with this guy right here, the king of the hill, the king of security, Mr. Steve Gibson.

[Steve Gibson]

Steve, for episode 10, which as we noted is binary 8. No, wait, no, 10.

[Leo Laporte]

Whatever it is, I've only been doing.

[Steve Gibson]

That for 55 years or something. So. Yes, binary 10. 10. 10. Binary 10.

[Leo Laporte]

Yes.

[Steve Gibson]

For the last episode of January, January 28th.

[Leo Laporte]

Here we are.

[Steve Gibson]

Where did the year go? Where is it going? What's gonna happen? We don't know. Okay, so lots to talk about this week. Today's episode is titled DNS over tls. I'm going to share. If you were Microsoft. If we were Microsoft, I would call it my personal learnings because.

[Leo Laporte]

Yeah, I don't know why they use that word. It's so. It's awful.

[Steve Gibson]

So bad. Yes. And you can see that we suffered a power failure which I have not yet reset things.

[Leo Laporte]

Oh, there's no blinking lights.

[Steve Gibson]

No, the blinking lights are frozen lights. But I imagine after our first sponsor announcement, the blinking lights will be blinking again because magically that was over the weekend and I haven't remembered to get them started again, I had to flip. Well, you know, you've got blinking lights.

[Leo Laporte]

I have blinking lights, yes.

[Steve Gibson]

Whenever they stop, they need a little bit of kick in the blink.

[Leo Laporte]

You gotta reprogram the whole damn thing.

[Steve Gibson]

That's right, that's right.

[Leo Laporte]

Actually one, my PDP has stopped, but that doesn't mean it's frozen. It means it solved the little number problem I gave it.

[Steve Gibson]

That's right. 42, it just.

[Leo Laporte]

Yes, it's 42.

[Steve Gibson]

42, that's right.

[Leo Laporte]

So we'll restart. You'll restart yours and I'll restart mine.

[Steve Gibson]

We're going to be talking about a lot of fun things. EM client can be purchased outright. We have an astonishing 5 year old typo which was found discovered by A security researcher in MasterCard's DNS which Whoa. That was not good. And neither was their response. We have an unwelcome surprise which was received so far has been received by 18,459 low level hackers, also known as in some circles as script kiddies. DDoS attacks continue to grow seemingly without any end in sight. We've got news on that front. Let's Encrypt has clarified their plans for six day we barely knew ye certificates Spinrite uncovers a bad brand new 8 terabyte drive a little something I want to explain about that which occurred to a user of Spinrite. I thought it would be fun to share that. We've also got a ton of listener feedback about totp syncthing and UDP hole punching, email spam, validrives, speed, AI neural nets, gdi, dgi, sorry DJI geofencing advertising in the new Outlook. And then as I said, we're going to look into the trade offs required to obtain privacy for our DNS lookups. And of course as always, oh we we've got another picture of the week that I think everyone will get a kick out of.

[Leo Laporte]

Awesome.

[Steve Gibson]

Yeah. Stand back.

[Leo Laporte]

Great show. I haven't looked at it. I. I could see the caption but I can't see the picture and I won't. I'm gonna preserve my virginity for a moment.

[Steve Gibson]

Candid. Candid. A candid. Yes, I'm gonna get a candid response.

[Leo Laporte]

But first a word. Thank you Steve. First a word from our sponsor for this segment of security now those really nice folks and I know that because I've spent some time with them at US Cloud, the number one Microsoft Unified support replacement. We've been talking for at least a few months now about US Cloud, the global leader in third party Microsoft support for enterprises. They now support, by the way 55. 0 of the Fortune 500 switching to you. And there's a reason for this. Actually there's three reasons. I'll give you the first one, the one that might be easiest to sell to the Boss. Switching to US Cloud can save your business 30 to 50% over Microsoft Unified and Premier support. So it's much more affordable. But of course, you know, less expensive doesn't mean better. Except in this case it does. US Cloud is faster. That's reason number two. Twice as fast in the average time to resolution versus Microsoft twice as fast. It's also better, so less expensive, faster, better with very accomplished high end engineers with lots of experience, all based in the US it's the kind of support you wish you had, but it's yours now if you want. And US Cloud is dedicated to helping you save money in other ways. For instance, US Cloud is excited to tell you about a new offering. They just announced their Azure cost optimization services. So think about it. When was the last time you took a close look at your Azure usage, you know, and really scanned it? It's been a while. It's not an easy thing to do. You can't just look at the line items. You got to go down the hall and say, Joe, are you still using that VM you spun up six months ago? What happens is you get, I like to call it Azure Creep as your sprawl, you know, spend creep because you know, you buy this stuff, you forget to turn it off. You're not sure if Joe's still using it. Good news. Saving on Azure is easier than you think with US Cloud. US Cloud has an eight week Azure Engagements powered by VBOX that will identify key opportunities to reduce costs across your entire Azure environment. And you're going to get expert guidance in this access to, as I said, US Cloud senior engineers. They recruit the best with an average of over 16 years doing Microsoft products break fix. At the end of those eight weeks of the Azure Engagement, your interactive dashboard will actually help identify, rebuild and downscale opportunities. Unused resources, stuff that's hard to find but can save you a lot of money. You can reallocate your precious IT dollars toward needed resources like maybe US Cloud support contract or just put it in the bag, put it in your pocket. Actually, a lot of US Cloud customers do exactly that. They take the savings that they got from this Azure engagement, they put it in their US Cloud Microsoft support. You could completely eliminate your unified spend. Now that's a money saver. Sam, the technical operations manager at Bead Gaming their customers, they give US Cloud five stars. He said, quote this is the review. We found some things in the Azure engagement that have been running for three years. No one was checking those VMs were, I don't know, 10 grand a month. Not a massive chunk in the scheme of how much we spent on Azure. But once you get to 40 or $50,000 a month, it kind of starts to add up. Stop overpaying for Azure. Identify and eliminate Azure Creep. Boost your performance too. All in eight weeks. With US Cloud the best Microsoft unified support replacement, visit uscloud.com, book a call today. Find out how much your team can save. Figure out what you're wasting on Azure. That's uscloud.com, book a call today. Get faster, better Microsoft support for a lot less. Thank you, US Cloud, for your support. All right, back we go. All right, I'm ready for the picture of the week. Should I scroll up in front of.

[Steve Gibson]

You and see as Bonito said when he saw this before we began recording. Oh, my God, we've seen things like this before. I gave this the title. What do you mean you forgot to pack our Australia New Zealand plug adapter.

[Leo Laporte]

Oh, Lord above.

[Steve Gibson]

Now, what we have here is a very clever. I have to give them credit, this is a very clever use of fingernail clippers. You know those. The kind of old school chrome plated fingernail clippers where you can swing out that little nail file part from the top. I mean, I'm sure everybody has seen those. It's like sort of like, you know, the one design of the can opener which is, you know, immortal. Well, these are. This is like that generic chrome plated fingernail clipper where you can slide out the little filing portion. Well, somebody apparently did forget their Australian New Zealand plug adapter. That's the one that's got, you know, they all sort of look like a face. This one's got slanted eyes, slots and then the little grounding nose slot. But. But apparently they brought a regular US style straight prong plug. Not deterred, however, they were managed to use these, a pair of fingernail clippers to bridge from the slanty slots in New Zealand or Australia to the US Straight prong plug. And difficult to describe this. You'll have to see the picture. Anyway, it's a mess and yikes.

[Leo Laporte]

Good lord, don't do this.

[Steve Gibson]

And Benito did mention, apparently these switches are. They switch the outlet on and off. And so you certainly would want the option to turn this outlet off while you're setting up this Disastrous. And you. And I mean it's really. It's on the fringe right there. What I can't tell is whether this is a grounded plug that they're connecting to. If so, the ground is missing prong.

[Leo Laporte]

You need a paperclip. That'll solve it.

[Steve Gibson]

That's right. We need one more exposed bare metal.

[Leo Laporte]

That's all you need.

[Steve Gibson]

Item. Yeah, that's right. Wow.

[Leo Laporte]

Wow.

[Steve Gibson]

Anyway, all right. And I've already got next week's queued up. It's the return of the scissor lift because it turns out there've been some other creative applications. Oh, and Leo, last week's picture, the scissor lift on the float was, you know, some people suggested. Yeah, maybe this was photoshopped. I've got pictures of it being set up. Wow. Like where it was actually being. This was being established. So anyway, so it's real. We are going to keep having fun with our photos everybody. Thanks to our listeners. This is entirely listener generated. So thank you all of our listeners who are sending email to securitynowrc.com after [e-mail] mail okay, I have to start with errata because Leo, I thank God I have EM client to help me manage the number of responses that I receive from our listeners. Basically saying variations of Steve, you know that one big gripe you had about EM client, you know, like, you know, which you recently fell in love with is not actually a thing. So I wanted to say thank you to one and all. I have no idea how I missed the very clearly marked slider up near the top of EM of the EM client's pricing page, but I certainly did. And now that I've seen it, it's impossible to unsee it. Every time I go to the page, that's all I see is the big slider that says, you know, rent this or purchase it. And I am now, needless to say, the proud owner of a lifetime license with upgrades, updates forever of EM client. And, and I was thinking about this, Leo, I know that you're at least in is regard tivos as I am. Back in the early days of XM Satellite Radio they offered a lifetime license which I purchased since I loved the concept of commercial free streaming music just coming down from the heavens later.

[Leo Laporte]

That way you don't get all the emails from them saying hey, it's time to renew. They're very bad about that.

[Steve Gibson]

Yeah, of course then later XM merged with Sirius and somewhere along the way the option to purchase a lifetime subscription. What do you know, it's gone. No longer there.

[Leo Laporte]

But you're still active.

[Steve Gibson]

Yes. Wow. I still have mine and I'm very glad that I made that choice many years ago. You know, and I mentioned you before, back when TiVos were the way to go. I know that you and I both always purchased the lifetime subscriptions for our tivos.

[Leo Laporte]

Of course it was the lifetime of that hardware. Not.

[Steve Gibson]

Yeah, I know that, that is, that was annoying that when like, because I had, you know, I. We all had had series one tivos and they became somewhat endangered at some point anyway since I tend to stick with things until I'm forced to switch, you know, the approach of just, you know, putting the money in up front and then riding it out a long way, that's always worked well for me. So anyway, just to follow up on my raves about EM Client last week, I wanted to say I'm even more pleased now with my switch than I was then and I heard from many of our listeners who were saying things like what took you so long? They had discovered EM Client years ago and similarly love it. So in addition to thanking everyone who wrote to make sure that I knew that it was possible to own it outright and that it I oh, and that it's 100% free to take it out for a spin for 30 days to see whether you might feel the same way about it as I do. Anyway, in my opinion, you know, they really got the user experience right. And of course Leo, you perked up upon hearing that it also fully supports end to end encrypted GNU PG email and address books. So that's in there too. So anyway, my entire reason for mentioning my own discovery of EM Client last week was to make sure that everyone at least had the opportunity to check it out and that if, you know, if they too were feeling frustrated with our current solution, whatever they might be using, they would know about it. And that was a success. Dan Taylor, one of our listeners, said, hi Steve, I realize that you receive a ton of email these days and your time is valuable so I'll attempt to keep this short. I just feel the need to thank you for mentioning EM Client on the podcast. I hope you saw my message about the one time purchase option they have. It's not at all obvious on the pricing page, but it's there. And for what it's worth, I did have other people say they didn't see it either. So maybe the EM Client people could do a better job of although they probably would rather like you paid for it for the rest of your life every month. You know, I think what what you like after four years you is the break even point or something. So it's like okay, I'm going to be using this. Well more than that anyway, he said, he said Dan Taylor said I had no previous knowledge of its existence. In a nutshell, it's wonderful exclamation point. He said. I have only one Gmail account. I also own two domains via Cloudflare, which forwards all email destined for those domains to my Gmail. He said, I've configured some aliases, one of which I'm using to send this to you. It's very cool, he said. Also, I know you know this, but you've done an outstanding job on Spinrite61 as I type this My Zima board is churning away on a 256 gigabyte flash drive that's been giving me problems. I've already run a level three on another one which improved its performance. Thanks again. So Dan's need for only a single domain where he's got the other ones forwarding into it suggests that he may be able to use EM client's free single account offering forever and so never need to go. I've got four domains that I need minimum. So anyway, just wanted to close the loop on that. Thank you all of our listeners. With the audience size we have, when I make a mistake like this I get corrected. And so I'm I'm happy to stand corrected on this because I am so happy that I own this thing. Okay, this week's first piece of security news is as as they would say in the UK is gobsmacking. Our friend Brian Krebs over at Krebs on Security shared a wonderfully surprising piece of news last Wednesday under his headline MasterCard DNS error went unnoticed for Years. And before we go any further into that exactly, you know what exactly went unnoticed, I want to first highlight that it wasn't unnoticed for minutes or days or weeks or even months, but literally for years. Which is what like puts a sharp point on this. Brian wrote the payment card giant MasterCard just fixed a glaring error in its domain name server settings that could have allowed anyone to intercept or divert Internet traffic for the company by registering an unused domain name. The misconfiguration persisted for nearly five years, he writes, until a security researcher spent $300 to register the domain and prevent it from being grabbed by cybercriminals. Now Brian's article then posts the output of a DNSDIG command which returns the name servers for a portion of the MasterCard.com domain. I have a screenshot of the command's output in the show notes. Even knowing that something is wrong with this picture, you would need to be sharp eyed to catch the mistake. I missed it the first time I looked at it. I looked at the screen without having read the text yet because it's big on Brian's page and I kind of scanned over it, okay, looked okay, Brian explains. He said from June 30 of 2020 until January 14 of 2025, thanks to the work of this security researcher, he said one of the core Internet servers that MasterCard uses to direct traffic to portions of the MasterCard.com network was misnamed. MasterCard.com, he says relies on five shared domain name system DNS servers at the Internet infrastructure provider Akamai. All of the Akamai DNS server names that MasterCard uses are supposed to end in akam.net but one of them was misconfigured to rely on the domain Akam ne. Yes, whoever created this is me talking. Whoever created, edited or updated the DNS record for that mastercard.com domain on June 30th of 2020, which lists the five authoritative DNS name servers that should be referred to when looking up any IP address for MasterCard.com subdomains made a tiny and earth shaking mistake. Just a simple typo when they were entering the names of the five name servers and it's as plain as day once you know what to look for. The first name server is named a129.akam.net the second one is a767.akam.net the fourth one is a 2666. Who knows why those are the machine names but and the fifth one is a 964akam.net but the one in the middle of those five. The third one is a 2265 Akam NE. The final T of. NET was never entered and boy does that make a difference. Brian continues to tell the story, writing this tiny but potentially critical typo was discovered recently by Philippe Catoregli, founder of the security consultancy Ceralis S E R A L Y S Cataregli said he guessed that nobody had yet registered the domain Akam Ne, which is under the purview of the top level domain authority for the West African nation of Niger. And Leo in that picture on the screen, the four, the third item of the five very clearly AKA E N E. They've dropped that final T. So Cataragli said it took $300 and nearly three months of waiting to secure the domain with the registry in Niger. After enabling a DNS server on Akam Ne, he noticed hundreds of thousands of DNS requests hitting his server each day from locations around the globe. Now I'm not sure about this, Brian wrote. Apparently MasterCard wasn't the only organization that had fat fingered a DNS entry to include Akam Ne, but they were by far the largest. Now, I don't know, maybe he was seeing other DNS queries to other domains not clear to me. If so, that really makes you wonder how common these sorts of mistakes might be. Like it would be worth. I don't want to give bad guys any ideas, but you know, there might be others, Brian said. Had he enabled an email server on his new domain, akam ne. Catarigli likely would have received wayward emails directed toward mastercard.com or other affected domains. If he'd abused his access, he probably could have obtained website encryption certificates, I'm sure he could have, that were authorized to accept and relay web traffic for affected websites. He may even have been able to passively receive Microsoft Windows authentication credentials from employee computers at affected companies. But the researcher said he didn't attempt to do any of that. Instead, he alerted MasterCard that the domain was theirs if they wanted it. Copying this author, meaning Brian Krebs, on his notifications a few hours later. Okay, quickly. To their credit, MasterCard acknowledged the mistake, but said there was never any real threat to the security of its operations. Uh huh, right. A MasterCard spokesperson wrote, quote, we have looked into the matter and there was not a risk to our systems. This typo has now been corrected. Okay, Now I suppose technically it's true that there was not a risk to their systems, but there was certainly a serious risk to anyone who might be relying upon the security of of MasterCard's systems, since that flew out the window with this typo, and that was five years ago. Brian continues writing. Meanwhile, Cataract Lee received a request submitted through bugcrowd, a program that offers financial rewards and recognition to security researchers who find flaws and work privately with the affected vendor to fix them. You know, in other words, responsible disclosures and bug bounties. Brian says the message suggested his public disclosure of the MasterCard DNS error via a post on LinkedIn after he'd secured the akam.ne domain was not aligned with ethical security practices and passed on a request from MasterCard to have the LinkedIn post removed. Cataregli said he does have an account on bug crowd, has never submitted anything through the bugcrowd program, and that he reported the issue directly to mastercard. Cataregli wrote in reply, quote, I did not disclose this issue through bugcrowd before making any public disclosure. I ensured that the affected domain was registered to prevent exploitation, mitigating any risk to MasterCard or its customers. This action, which we took at our own expense, demonstrates our commitment to ethical security practices and responsible disclosure, unquote. Now most organizations have at least two authoritative domain name servers, and that's true. That's what Brian wrote and that's what I do for grc. And that's typical. That's why most people will see two DNS servers in their own computers. This has always been done to create some redundancy for the sake of DNS lookup reliability, Brian says. But some handle so many DNS requests that they need to spread the load over additional DNS server domains, which is also true. And in fact, DNS deliberately responds when there is a list of available DNS servers, it will send them in round robin fashion so that successive requests get a differently ordered list of name servers in order to further cause them to get spread out. So if they always listed the first one first, then everyone would just choose that one. And so you would wouldn't really get much effect of having five. So in MasterCard's case, that number is five. So it stands to reason that if an attacker managed to seize control over just one of those five domains, they would be able to see about one fifth of the overall DNS requests coming in. But Cataragli explained that the reality is many Internet users are relying, at least to some degree. And this is what Brian is writing on public traffic forwarders or DNS resolvers like cloudflare and Google. Okay, now, I would strengthen that statement a lot to say that there is, I would argue, no one who is not relying upon caching resolvers. As we've often discussed on the podcast, caching DNS is, is critical. It's the only way this hierarchical system of distributed domain name resolution is able to function. You know, when you turn on your computer for the first time in the morning and you go to Amazon.com, you're not hitting Amazon.com's name server to find out a list of IP addresses. Your ISP has obtained that from any other of the customers of its customers who you are sharing the ISPs DNS server with. So it's in the DNS server's cache for eight hours a day, who knows how long. So caching is crucial for this whole process, Cataragli said, quote so all we need is for one of those resolvers to query our name server and cache the result. And here's the key. By setting their DNS server records with a long ttl, which is the time to live, a setting that can adjust the lifespan of data packets on the network. Actually, it's the lifespan of the cache of the DNS record, which is cached throughout the DNS hierarchy, an attacker's poisoned instructions for the target domain can be propagated by large cloud providers. He said, with a long ttl, we may reroute a lot more than just one fifth of the traffic. Okay, and so that's absolutely true. Typical TTLs, you know, are maybe an hour or two depends upon. I mean, it's entirely up to the discretion of the person who's setting up an entity's DNS. The longer the TTL that you publish, that is how long you are telling the rest of the DNS caching hierarchy out on the Internet, it can wait before it comes back to refresh your IP address. The longer that is, the fewer requests you're going to get. Right, because a greater percentage of the request will be handled by all the caching out on the Internet. So back in the, you know, two decades ago when G. When GRC was, was first being a victim of DDoS attacks, I would decrease our TTL so that I could change IPs. Well, that's no longer feasible because it's not about changing IPs. Today's attacks just swamp the bandwidth, so there's no point in doing anything except just waiting. But if an organization's IP addresses are very stable, then it can make sense to set a TTL to 24 hours, for example. And many of them are. In fact, if you try to set it too low, many caching resolvers will ignore a too low setting and just set their own minimum, ignoring what you have asked for. Anyway. Cataragui said he hoped that MasterCard might thank him or at least offer to cover the cost of buying the domain. He wrote in a follow up post on LinkedIn regarding Mastercard's public statement, quote, we obviously disagree with this assessment, but we'll let you judge. Here are some of the DNS lookups we recorded before reporting the issue. And then his post, which Brian quoted and has a picture of in Brian's own reporting, shows a sobering list of the queries that were coming into his NE domain. We can see West Europe, east us, West US au, Southeast au, East Australia east and more. And remember that this DNS record was last changed and had been incorrect for the past four and a half years. So let's just say that if this had fallen into the hands of a malicious Russian or Chinese attacker, you know, who repeatedly demonstrated that they're looking for any advantage they can find over the west, the story we would be reporting today would have a very different ending. Now that said, mistakes happen and anyone can make an innocent mistake. I'm sure that's all this was. This was just that, you know, at least MasterCard had the good sense and grace not to threaten this researcher who helped them significantly in return for nothing other than some recognition for his sharp eyes and, you know, the demonstration of his own integrity within his community. But wow. And again, the. The thing that, the thing that really caught me out here was the suggestion that this wasn't just me. Mastercard.com queries that were coming in as a result of this typo, that would suggest that there were other places where this Azure stub domain was being referred to and somebody was referring to somebody else had it, as in their own DNS, not just MasterCard, which again, you really sort of wonder how many typos exist in DNS and how many opportunities there are to get up to some real mischief. You know, we've talked often. I mean, when Dan Kaminsky discovered that DNS recursive resolver queries had insufficient randomization in their queries, which allowed for their caches to be poisoned by bad guys guessing what a query would be and inserting a malicious response that panicked the entire industry so much that in, in a matter of 24 hours, all DNS resolvers were updated in a, like in a pre planned, staged, secret update. I mean, it was that big a deal. This is that scale. So I hope, I hope the news gets out and people check their DNS records because, you know, a typo, as we've seen here, can go unseen for five years and could cause some real damage again, not to the company, but to the people who are relying on the security of its services. Wow. And Leo, we're a little. After a little more than half an hour in, let's take a break and then we're gonna. We're gonna look at what happens when script kiddies think they're getting away with something.

[Leo Laporte]

I like low. What did you say?

[Steve Gibson]

Low.

[Leo Laporte]

Level hackers.

[Steve Gibson]

Oh, level hackers, that's right.

[Leo Laporte]

All right, that's coming up. But right now, a word from our sponsor. This portion of security now brought to you by Delete me if you don't do this, but have you ever searched for your name online? You know, this is not something anybody should do. I mean, the amount of personal information about you only. Do it if you doubt me. You will be shocked of what's online. Maintaining privacy is not just an individual's concern. It's a concern for your business. It's a concern for your family. Delete Me has corporate plans and they have family plans. With the family plan, you can ensure everyone in your family feels safe online. The corporate plan is a great. I think it's a must for any company. Protect your security by protecting the privacy of your managers. We know this because, well, it happened to us. Spear phishing attacks work only when they know a lot about the manager, their direct reports, their phone numbers and all of that. But that's easy to do if you're a determined attacker because you just go to those data brokers and you can find anything you want. That's why you need Delete Me. Delete Me helps reduce the risk, all kinds of risks, from identity theft to cybersecurity threats, of course, harassment and so forth. We used DeleteMe to protect our management, our CEO. And it worked. Steve and I know it worked because when we searched the national public data breach for our data, our socials, Steve and mine were in there. Lisa's wasn't because DeleteMe had found and removed her information from home. Hundreds of data brokers, including national public data. You're going to do it for the family. You can assign a unique sheet to each family member, tailored to them with easy to use controls. Account owners can manage privacy settings for the whole family. But whether it's family, an individual or corporate plan, the most important part is after they do the initial cleaning, they continue to scan and remove your information regularly. Because there's new data brokers popping up every day. And let's face it, data brokers are strongly incented to repopulate your information, even if you delete it, because that's where they make their money, is selling information about you. All sorts of information. Addresses, photos, emails, your relatives, your direct reports at work, for phone numbers, your social media, your property value, and a whole lot more. Protect yourself, reclaim your privacy. Visit joindeleteme.com TWiT if you use our offer code TWiT, you can get 20% off. That's joindeleteme.com twit and don't forget, offer code TWiT for 20% off. Thank you, delete me for protecting TWiT. And thank you, dear Twit listener and viewer, for supporting us by going to that address so they know that you saw it here. Join EliteMe.com/TWIT. Use the promo code TWIT for 20% off. Thank you. Delete me. Thank you. All right, Steve, on we go. I've got a pie chart here.

[Steve Gibson]

Yes. Last Friday, the security firm Cloud Sec spelled S E K, disclosed the details of their investigation into an interesting attack that, that I don't think we've seen before. Get a load of what they shared. They wrote a Trojanized version of the Exwyrm rat builder where, you know, R A T is the common abbreviation for remote access Trojan has been weaponized and propagated. It is targeted specifically towards Script Kiddies who are new to cybersecurity and directly download and use tools mentioned in various tutorials, thus showing that there's no honor among thieves. Okay, now, not that anyone ever thought there was any Rather than going with the no honors among thieves theme, I think I might have chosen there's no such thing as a free lunch because these script kiddies think that they found any A hacked version of a commercial X Worm rat builder tool. I saw one of the postings somewhere that said, you know, this is a cracked version so you get to use it for free. Uh huh. Right. Anyway, so the. So the article goes, do you have to be. Well, that's what the hack, you know, that's what the hacker sites are full of is right is you know, this or that has been cracked or here's the key for using it and so forth.

[Leo Laporte]

You only do that once, I think.

[Steve Gibson]

Yeah. So the article says the malware is spread primarily through a GitHub repo, but also uses other file sharing services, specifically the well known mega NZ upload, EE2 Telegram channels and several hacker sites it has so far compromised. And here it is. 18,004, 459 devices globally. Wow. Is capable of exfiltrating sensitive data like browser credentials, discord tokens, Telegram data and system information. The malware also features advanced functionality, including virtualization checks that is to check to see whether it's running in a virtual machine and is thus being analyzed by researchers. Virtualization checks, registry modifications, and a wide range of commands enabling full control over infected systems. Thus Remote Access Trojan, as the name goes, or RAT for short. Top victim countries include Russia, usa, India, Ukraine and Turkey. The malware uses Telegram as its command and control infrastructure, leveraging bot tokens and API calls to issue commands to infected devices and exfiltrate stolen data. Analysis revealed the malware has so far exfiltrated more than 1 gigabyte of browser credentials from these 18,459 devices globally. Okay, so these wannabe hackers really are being hacked. Browser credential theft, as we know, allows the actual bad guys behind this to impersonate them on any websites where they're logged on, the article continues. Researchers also identified the malware's Kill Switch feature, which was leveraged to disrupt operations on active devices. Disruption efforts targeted the malware's botnet by exploiting its uninstall command. While effective for active devices, limitations such as offline machines and Telegram's rate limiting posed challenges. Attribution efforts linked the operation to a threat actor. Now, so this is the this is the guy behind the creation of the malicious malware, the mal malware. He uses aliases Shinyanigma, Andilleniumrat as well as GitHub accounts and a Proton mail address, they wrote. The rise of sophisticated remote access Trojans has amplified cyber threats, with Xworm emerging as a significant example. Recently, a Trojanized Xworm rat builder has been identified being propagated by threat actors via multiple channels such as GitHub repositories, file sharing services and others. This was specifically targeted towards script kiddies who are new to cybersecurity and use tools mentioned in various tutorials. So for example, YouTube tutorials were saying, go here and get this. So this was a serious campaign deliberately looking for these, you know, as we said, low level hackers, they said. Our analysis aims to provide detailed insights into the delivery, functionality and impact of this Trojanized exworm rat builder by leveraging data exfiltrated via Telegram, these researchers said. They said we uncovered the infection sources, mapped its command and control mechanisms and identified the breadth of its capabilities and the affected devices. Additionally, we conducted disruption activities targeting the botnet infrastructure to mitigate its operations. So they went further than just being a passive observer. They got proactive, which, you know, the legal issues there are a little shaky. Apparently you're able to do it, I think the last time we checked in, if you had some state level agreement to do so. But otherwise, you know, even if you're disinfecting other people's machines, technically you're still affecting other people's machines without their permission. So that's a little sketchy. But the malware that these script kitties inadvertently installed and hosted on their own machines, believing that they were obtaining a cracked copy of the well known exworm rat builder is able to obey commands such as the browsers command, which steals saved passwords, cookies and autofill data from their browsers. Keylogger, what its name sounds like, records everything the victim types on their computer desktop, captures the victim's current screen, Encrypt password, encrypts all files on the system using a provided password process kill terminates specific running processes, which would typically be security software. And then there's the upload file which exfiltrates specific files from the infected system and 50 other commands in total. So it's a very complete command set. What struck me is that there is such a large, okay, this was like first blush, such a large and thriving ecosystem of low level hackers who apparently aspire to be running their own botnets. 18,459 specific known instances where this Trojan Trojan was downloaded, installed and run. 2,478 of them are located in Russia, but the US is the runner up with 1540 installed instances. Now, I suppose when you consider the size of the world and the number of kids who are probably enamored of the idea of being, you know, a stealthy Internet hacker, it's understandable. And when you consider the viewpoint of the more sophisticated hacker who created this double cross, your targets are easily baited with low hanging fruit. They think they're getting something for nothing, and, well, boy, are they. They're installing, you know, really bad malware into their own machines thinking that they're getting a malware builder for free.

[Leo Laporte]

So anyway, wait a minute, let me get this straight. Script kiddies who wanted to install a remote Access Trojan on their systems, installed a Remote Access Trojan on their systems.

[Steve Gibson]

Exactly. Okay.

[Leo Laporte]

By their own swords, they thought.

[Steve Gibson]

Exactly. Hoisted by their own. They thought that they were going to be getting a rat, a worm based Remote Access Trojan system, in order to create their own botnets. Yeah. And they became, you know, a victim of somebody else's effort to infiltrate their systems.

[Leo Laporte]

So unbelievable.

[Steve Gibson]

Whoopsie. Yeah. Speaking of botnets generating widespread attacks, Leo, we have set a new record. Oh, yeah. Last Tuesday, Cloudflare updated the world on the state of Internet DDoS attacks by publishing their 20th quarterly report since they began quarterly reporting in 2020. I've got a link on the next page, top of page 9. You may want to just bring that up on the screen while I'm talking about this, because this thing, I'm only going to touch on it. That's why I've got the link and I mentioned it several times because there's so many interesting charts and graphs in this thing. Okay, so today's DDoS attacks appear to.

[Leo Laporte]

Be.

[Steve Gibson]

The DDoS attack records. The size of today's DDoS attacks at this point appear to be broken just for the sake of breaking them. By that, I mean that hitting anyone with, get this, 5.6 trillion bits of traffic per second per second. 5.6 trillion bits of attack traffic per second. Well, it's massive overkill. I mean, the only exception to this would be if, if one were stubbornly trying to attack a site that was being protected by a leading DDoS mitigation service, you know, such as Cloudflare. And this is their quarterly report. And in fact, that is what happened during the week of Halloween at the end of October 2024. Cloudflare's DDoS defense systems and this is, to me, this is astonishing. Successfully and autonomously detected and blocked that 5.6 terabit per second DDoS attack, registering the largest attack ever. Regardless reported, and somewhat incredibly, the company paying for Cloudflare's DDoS attack prevention services remained online and blissfully unaware that anything had even happened.

[Leo Laporte]

That's amazing.

[Steve Gibson]

It's incredible. So in their report, which as I said I've linked to in the show notes for anyone who's interested, they Note that in 2024, Cloudflare's autonomous DDoS defense systems blocked around. And here's a number that'll sober you up quickly. 21.3 million DDoS attacks. 21.3 million DDoS Attacks, representing a 53% increase compared to 2023. So 2024 saw a 53% increase in number of attacks compared to 2023. And it's the botnets, right? I mean it's. Unfortunately there are, there are lots of botnets and it's not difficult to get to enlist them, to generate, to just to throw garbage at a given IP and to knock those IPs off the net. They said on average in 2024, Cloudflare blocked 4870. Okay, 4870 DDoS attacks per hour. Nearly 5000 DDoS attacks per hour. Okay. And that's not all of the Internet, right? That's not all the Internet. That's only the attacks against Cloudflare, its infrastructure and its customers. That means that worldwide the DDoS attack rate will be many, many times more since Cloudflare is only protecting a tiny subset of the entire Internet. Nonetheless, nearly 5,000 attacks per hour, 21.3 million DDoS attacks last year, just for Cloudflare. Also they noted in the fourth quarter over 420 of those attacks, 420 in the fourth quarter of 2024 were what they're now terming hypervolumetric, exceeding rates of 1 billion packets per second and over 1 terabyte of 1 terabit per second. So 1 billion packets per second and 1 terabits per second, 420 of those were hypervolumetric. And the number of attacks exceedingly 1 terabit per second grew by a staggering 1885% quarter over quarter. In other words, there's been an explosion in the number of these high volume greater than 1 TB attacks from the same quarter in 2023 compared to the the fourth quarter in 2024. And about this record breaking attack, they wrote on October 9th, a 5.6 TB UDP DDOS attack launched by a Mirai variant Botnet targeted a Cloudflare Magic Transit customer, an Internet service provider from eastern Asia. The attack lasted only 80 seconds and originated from over 13,000 IoT devices. Detection and mitigation were fully autonomous by Cloudflare's distributed defense systems. It required no human intervention, did not trigger any alerts, and did not cause any performance degradation. The systems worked as intended. Then they added about this attack. While the total number of unique source IP addresses was around 13,000, the average unique source IP addresses per second was 5,500. We also saw a similar number of unique source ports per second in the graph below. And, and I have this below on our next page in the show notes. Each line represents one of the 13,000 different source IP addresses, and as portrayed, each contributed less than 8 gigabits per second on average. The average distribution of each IP address per second was around 1 gigabits per second. And this is just. I have it at the top of page 10 in the show notes. It's just a beautiful chart, so you need to see the show notes to appreciate this, but every line is one of the bots. And so there's 13,000 of these little thin lines. And this is the. And so. And I have to say, this also represents astonishingly good control. You know, I don't want to give credit to the bot herders, the bot masters, but to like to bring up an attack. The earlier chart that you showed from their page, Leo, that showed just basically a big square wave. The attack began with a sharp edge. It almost immediately came to full strength. It lasted for 80 seconds, and then it immediately shut off.

[Leo Laporte]

Oh, so that's only 80 seconds. Yes, it's a test.

[Steve Gibson]

Well, yes, exactly. And in fact, in some other reading that I've done, DDoS attacks are often being aimed at people who are capable of measuring them because they want to know. Yes. And when you think about it, they don't know. They're commandeering routers. You know, they're grabbing routers and NAS boxes and random crap.

[Leo Laporte]

This is all a Mirai bot. That's.

[Steve Gibson]

Yes, 13,000 Mirai. A 13,000 agent Mirai botnet did this. And I mean, this melts wires. I mean, it's crazy.

[Leo Laporte]

A lot of data.

[Steve Gibson]

It is just.

[Leo Laporte]

It's also very impressive. And of course, that's why Cloudflare writes the blog post that they were able to mitigate this 100%.

[Steve Gibson]

Yes. If you were like a gambling site or, you know, because it's a big ad for them. It is a big ad for them. I would argue they deserve it. And of course they're not the only people who are able to do DDoS attack mitigation. We've named a bunch of them before. I think Akamai has a service. I think Microsoft offers a service.

[Leo Laporte]

Amazon does.

[Steve Gibson]

Yes, Amazon does. So there are alternatives. But wow, just 5.6 terabits trillion bits per second per second.

[Leo Laporte]

Yeah.

[Steve Gibson]

Wow. 12 days ago on January 16th, let's Encrypt posted their formal announcement, which we had a preview of a few weeks before that, which worried me a bit. On the 16th they posted their formal announcement of their plans for 2025 and a sincere thank you to one of our listeners for pointing me to this. I'm glad to have to know this and to be able to share this. The opening paragraph of their announcement says this year we will continue to pursue our commitment to improving the security of the web PKI by introducing the option to get certificates with six day lifetimes and they said in parens short lived certificates. We will also add support for IP addresses in addition to domain names. Our longer lived certificates, which currently have a lifetime of 90 days, will continue to be available alongside our 6 day offering. Subscribers will be able to opt in to short lived certificates via a certificate profile mechanism being added to our ACME API. Okay, so I am grateful for this welcome clarification. As our listeners know, I question whether this is actually solving a real problem with the industry's pki, our public key infrastructure. And it exposes, you know, it does expose its users to some threat of connectivity outage if anything should occur to prevent a timely ACME certificate renewal. But that said, why not offer it as long as it's not mandatory? This places a huge burden on anyone offering such short term renewals. It's very much like the analogy I just drew with DNS. DNS depends on caching in order not to load down the DNS name server. If it didn't have it, it would have to be fielding all these requests. Well, certificate lifetime is very much like caching the credentials out on the web server which otherwise has to come back and get updated credentials within, you know, before its cached credential, the lifetime of its certificate expires. So if you're shortening that, you're shortening the, you know, you're requiring all of the web servers that are opting to do this to come back more, much more often. But okay, if they want to do it, fine, as long as they don't make everybody do it. So again, I don't know what's driving this. The fact that they're willing to put this huge burden on themselves suggests that there must be some problem. Maybe there are people who are being kept up at night worrying about the theft of their web server authentication certificates and who place no faith in the ongoing move to client side Bloom Filter based revocation enforcement which we talked about last year, toward the end of last year and which is in place and working and being increasingly relied on. Anyway, the let's Encrypt statement included a timeline. They said we expect to issue the first short lived certificates to ourselves in February of this year. So you know, in a few days, you know, around April, we will enable short lived certificates for a small set of early adopting subscribers. We hope to make short lived certificates generally available by the end of 2025. So not tomorrow. Hope to make short lived certificates generally available by the end of 2025. Again, this is going to require some scaling up of their infrastructure in order to pull this off. And they finished. Once short lived certificates are an option for you, you'll need to use an ACME client that supports Acme certificate profiles and select the short lived certificate profile, the name of which will be published at a later date. So this is, you know, very much still nascent and on its way. I did hear from a listener of ours who received this, who received the show notes last night where I was talking about this. He said that something had changed just recently with the there with the let's Encrypt cert bot because he was having an email connectivity problem. It turned out that they defaulted. They changed the default to elliptic curve certificates from RSA and it was necessary to explicitly specify that you wanted RSA certificates because he was having connectivity problems with with other servers who are not able to support elliptic curve crypto. So just a heads up for anybody who might be caught out by the same thing. I don't have a sense of time for a timeframe for when this happened to him, but I got the sense that it had just happened and he was having an email outage as a consequence of an updated let's Encrypt certificate having changed its certificate in a way that was other email servers were having a problem connecting to. So there's another sort of gotcha for that. I want to share a spinrite story that I think everybody will find interesting. Leo, but we're at an hour in so let's tell our listeners why we're still here.

[Leo Laporte]

Indeed, indeed.

[Steve Gibson]

On the Air, as it were.

[Leo Laporte]

On the air. How does it manage to stay on the air? It manages thanks to our great sponsors and of course our Club Twit members. Great sponsors like Bit Warden this episode of Security now brought to you by the trusted leader in passwords, secrets and passkey management. In today's digital landscape, protecting your organization obviously is job one. Bitwarden has stepped up to the challenge with powerful new features designed to simplify and fortify your password management strategy. For example, recently Bitwarden expanded its team plans with robust SCIM system for cross domain identity management user provisioning. What does that mean? Well, it's great. It means MSPs and IT departments can streamline access control with ease by integrating seamlessly with leading IDPs like Azure, Active Directory, Okta, OneLogin, JumpCloud, and more. Bit Warden delivers enterprise level security capabilities that work for businesses of all sizes. And it simplifies your job with automatically provisioning and unprovisioning employees. But that's not all. Bit Warden has also redesigned its password manager browser extension. Have you seen the new one? It's beautiful. Creates more intuitive and more efficient way to manage your passwords. The new extension has a modern interface with faster navigation, clearer organization, smoother workflows. It's important because it's one thing to have a password manager at work, it's another thing to get your employees to use it. Same thing for individuals. This new UI makes it easier for businesses and individuals to manage passwords across platforms. What sets Bit Warden apart? I can think of a lot of reasons. The reason I use it is because it's open source. It's open source, but also again, it's easy to use. And if a password manager is too complicated or too difficult or gets in the way, it just encourages you to do unsafe things with your passwords. It's really not just about security, it's about simplicity. Or maybe I should. It would be better to say simplicity is good for security, right? It's very quick to set up Bitwarden. It'll only take a few minutes if you're moving from another password management solution. Imports are supported from almost all of them, so it's very quick, transparent, very easy. And of course open source is another reason I use Bit Warden. It's so important to me. The Bit Warden source code can be inspected by anyone. It's GPL licensed, you can see it on GitHub. But they go a step farther. They also have regular paid audits from third party experts and they publish the results of those audits, so you can always be assured that the program is doing what you expect it to do and no more. Your business deserves a cost effective solution for enhanced online security. You deserve Bit Warden. You can see for yourself. Get started with Bit Warden's free trial of a teams or enterprise plan for your business. Or if you're an individual, or maybe because you're smart, you're already listening to security. Now you probably already have a password manager, but I bet you have friends. We all do, and family who's still using that same password over and over again. Let them know Bit Warden is free forever across all devices. Unlimited passwords as an individual user, of course they are. They have to be. They're open source. That includes passkeys. It includes hardware keys like Yubikey. Find out more bitwarden.com TWIT send your send your security unaware friends and relatives to bitwarden.com twit they will be glad you did. And if you're not using a password manager and you're listening to this show.

[Steve Gibson]

Huh.

[Leo Laporte]

You use it to go to sleep. What I don't understand bitwarden.com TWIT all right, Steve, Spinrite Story well, I haven't.

[Steve Gibson]

Mentioned Spinrite for quite a while since I haven't had anything new to share. We all know of the discovery that the fronts of SSDs where the operating system files live slow way down after years of use, and that a single Level 3 Spinrite pass will restore the drive's original performance. I receive ongoing reports of that and I've posted some of them over on Spinrite pages. But you know, it becomes redundant after a while. I'm mentioning Spinrite today because last week we received a report that I did want to share a generic Spin Right user wrote to my tech support guy, Greg. He said, hi greg, I bought four Western Digital Red 8 Terabyte hard drives for a Zima cube and wanted to check their operation before installing the first two. That is the first two of his four drives past Spinrite level three in about 28 hours each with no errors. The third got 80% through, but then started showing problems through the smart screen by 94%, which took 106 hours. There were 216 bad sectors, 379 minor issues, 680445 command timeouts with the status screen showing four Bs for bad regions. He said, I'm running the fourth WD 8 terabyte drive on a Zima board. Like the first two drives, it's having no trouble at 68% and should finish before the bad third drive, which I guess was still chugging away and struggling. So then he had questions. He said questions. Would you return this third drive showing the problems? What do command timeouts mean? How do I know how many spare sectors remain for future swapping out? Okay, now the big news here is the picture that he included. He took a picture of that third drive's smart system monitor page in Spinrite. Now, this is what this one drive was showing him about itself. And what we see here is a brand new drive that's in serious trouble. The whole smart system. You know, smart self monitoring, analysis and reporting technology has always been a mixed blessing because it's never been a strong standard. In fact, it's an extremely weak standard. I would argue it's really not much of a standard at all. What's standardized is the way to access the drive's smart data. What's never been standardized because there was never any way to force its standardization, is the precise meaning of the various things a drive may choose to report about itself. As a result, large databases have been assembled by volunteers, and they're being maintained on a volunteer basis to show what this or that specific drives make and model means with this or that smart parameter. But that said, the one thing that is universally understood is that the drives summary health parameter has the meaning that the more positive it is, the better. You know, up is good, down is bad. So the screen that we see tells an unambiguous story. It shows us that the drive itself is. This is not spinright saying this, this is. And that's what's key here. The smart is self monitoring, analysis and reporting technology. The drive itself is saying that three clearly crucial parameters, the amount of ECC error correction being needed, the rate of bad sector relocations, and the number of relocation events. Those, those are those three red bars shown there. They are reflecting a drive that is in serious trouble. That is, the drive itself is saying, you know, I am in serious trouble. You know. Spinrite is showing those three smart parameters in red bars because what it does is it holds the maximum positive health value it has seen since it was started. And any subsequent drop in those values, which again down is bad, up is good. So any subsequent drop in those values is shown in red because that's never good. The screenshot also shows us that many other smart health parameters the drive is reporting have remained pinned at their peak of 100%, sector seek errors, recalibrate retries, cabling errors, uncorrectable errors, write errors, and pending Sector sectors are not worrying the drive at all. They're all sitting at 100 out of 100 or 200 out of 200. But ECC corrected has dropped to negative 50 out of 149. Sectors relocated is at 30 out of 200, and relocation events is down to 1 out of 200. These all reveal that something is very wrong with this drive. So the question is not should I return it? But how quickly can I return it and get it replaced? I mean, this was just, you know, it's a bum drive. And this brings me to the first of two points I want to make. If a drive is just sitting there doing nothing but spinning happily away, it will be quite fine. Many other smart monitoring tools have been created, and they can be useful. But it's important to really understand that if a drive is not being asked to do any work, if it's just sitting there happily spinning away, then the drive's sunny disposition doesn't have the same meaning as when it's still smiling while doing what a drive is there to do, which is reading and writing data. You know, human doctors who want to test someone's cardiac function put their patient on a treadmill, because it's only when the patient's heart is under some load that its response to that work can be determined. Resting state is also useful, but it doesn't tell the whole story. And here's the second point I wanted to make. This spinrite user purchased four drives, and only one of the four was brought to its knees just by asking the drive to read and write during a level three Spinrite pass. It's not as if this is some sort of torture for a drive. Spinrite is not abusing a drive in any way. It's just saying, how would you feel about doing some reading and writing? You know, three of those identical drives all purchased, all four purchased at the same time. Three of them respond by saying sure thing, while one of the four is really very unhappy about being asked to do what it was designed to do. You know, and I've shared the story before, both from hearsay and also from people who have reported from having been there themselves that in the early days, the famous IBM PC cloning company Compaq would over order the number of drives they needed, then use spinrite to pre test those drives before putting them into service. Any drives that didn't make the grade were returned. Since those drives technically worked and would have passed the manufacturer's QA testing. I imagine somebody else wound up with Compaqs rejects. But Nobody wants that. So it's interesting that even though today's technology could hardly be more different, and you know, we're talking about 8 terabyte drives, 8 trillion bytes on a drive, rather than 30 or 40 megabytes back in those early compact days, some things have still not changed. And spinrite has remained useful for performing pre deployment hard drive testing. And actually I know that that's what a lot of spinrite's users do with it. So just a perfect case in point of that, you know. Yeah, you can look at a drive smart data when it, you know, you turned it on and it's been sitting there for a while. That'll tell you a few things. But you need to ask it to do some work and see how it feels about its own ability to do that. And this drive, you know, this needs to be replaced. Okay, so a listener of ours, Steven, says, hi Steve, another incredible podcast breaking down one time passwords, but I'd like to drop a spanner in the machine. Sorry. If an attacker is trying to brute force a one time password, they already have the user's creds, which means the code space is reduced to 1 million, the weakest link in the chain. Okay, now what he means is that there's only there is one in a million possible correct answers if you're trying to log in. We know that's true. Six digits, he says. In theory, a bad actor could easily spin up a few hundred cloud instances and distribute the two factor authentication attempts across them. Multiple simultaneous attempts within the 30 second time window. Doesn't have to get the one time password the first time, but given enough resources would likely succeed. Obviously the server could throttle login attempts per account, but no server admin is perfect. Just a thought. Best regards, Stephen. Okay, so a number of our listeners shared variations on this theme, so I wanted to take a moment to mention that that last week's challenge was not so much about defeating multi factor authentication once in order to log in as a user, but rather to examine the theoretical requirements for cracking an authenticator's secret key. That was what we were trying to do. After writing and sharing that last week, I've been thinking about it since I realized that there's a somewhat clearer and simpler, cleaner way to think about the entire thing. Since it's a different construction of the same solution I want to share. It won't take long. I think it's sort of a distillation of what we talked about. Okay, so first we once again assume that we have some set of sample Outputs from an authenticator where each output is a six digit code and the time of that code, that code's timestamp. So for any given 80 bit candidate key, there will be a one in a million chance that the candidate key will produce the same code as the authenticator for the same timestamp. The key we seek is the one that produces the proper authenticator code for every time stamp. So we get a new candidate key and we start testing it against each of the authenticator samples we have. Authenticator output samples we have. The right key will match all of them. And since there's always a one in a million chance for any match, that means that non matching is always a near certainty. It's all you know, except for one in a million times. It's gonna. We're not gonna get a match. So as we test a new candidate key against our set of samples, each successful match allows us to be 1 million times more certain that we have found the one proper key that will match every sample we can test. Since 80 bits allows for. And here it comes. 1.2 million million million million keys, this makes very clear why we need at least four sample matches and why a few more would be good just to make sure. Anyway, that seems like a distillation of my longer exposition of this last week. Every sample that you can test against makes you a million times more sure that you've got the right key. Since there's only a one in a million chance that the right key will work. And since there's four millions times 1.2, if you're able to test four different keys, you're a million times more sure. Four times. So you're getting pretty sure at that point, but a few more would be good. Anyway, I wanted to acknowledge Steven's other point, which was that the authentication service on the receiving end of many failed guesses would be expected to limit and throttle the number of those a user would be allowed to make. It would seem a bit far fetched for that not to be done if we hadn't recently covered Microsoft's own multi factor authentication systems, having made exactly that mistake. So, some great points from our listener as always, Joe Havelatt. He said on the subject of syncthing and UDP hole punching. Hi Steve, thank you for all the time and effort you and Leo put into the Security now podcast. I look forward to listening to it every week. I end up using a lot of software and services you mentioned on the show, and syncthing is one of them. In the past I've used tailscale to access my internal devices remotely, including devices I use syncthing on. I recently decided to try something other than tailscale, and after I removed it from my devices, to my surprise, syncthing continued to work. Right after looking at the settings and doing a bit of reading, it appears that syncthing was making quick quic connections, leveraging Stun for a direct connection. I believe this is similar to how tail scale gets around gnats. Anyway, as my eyes were glazing over while reading about Stun, I thought this might make a good topic for one of your propeller hat discussions. If you could find the time to discuss this in one of your future episodes, it would be greatly appreciated. If not, no big deal. You always seem to come up with something that piques my interest. Thanks again, Joe okay, so I was certain that we once had a podcast titled Stun and Turn, but I was unable to locate it. I did locate a reference to that that phrase in podcast number 443 which was titled Sisyphus where I said and they use in order to do Nat traversal. We've talked about Nat traversal in the past. There's the so called Stun and Turn protocols, unquote. But you know, given my inability to locate a podcast with that title, perhaps I've only ever referred to it in passing. So Joe, if that's the case, I agree it would make a terrific and still very relevant deep dive topic because Nat traversal is something as important today as it ever was. So thank you for that. Joe Harris said hi Steve, after hearing you talk about switching to EM client for email, I decided to check it out. Currently I'm using the built in mail apps on macOS and iOS to manage my personal Gmail and Yahoo accounts. While they work fine for my needs, I'm curious about what other email clients have to offer. That leads me to a question and Leo, this would be one I'd like to hear you weigh in on. He asks, do you have any recommendations for email providers? Over the years I've noticed that my Yahoo account in particular has been receiving more and more spam. I suspect this might be due to how long I've had the address and how many services I've linked to. Thanks for any insights you can share. Best regards, Jason okay, so I first want to say that many, many years ago, and I know that you and I talked about this at the time, Leo, I spent some time looking at the spam problem. A very techie coder buddy of mine, Mark Thompson, and I developed a Bayesian Filter for spam. That was pretty much state of the art at the time. Now this was back in the famous John Dvorak I get no spam days where as I recall, John was stating that his ISP was so good that he got no spam. Meanwhile I was being buried under an avalanche of spam since my email address at the time was just steverc.com yikes. I will never forget the time I enabled real time logging for GRC's email server and watched foreign SMTP servers connecting to GRC and just running down an alphabetic list of account names using people's proper first names. I mean starting with a running through, you know, like Abigail and Annette and so forth. I realized that it wasn't only that my email address had leaked, though I'm also sure by then that it had. It was that my email account name was just likely to be valid because it was just my name, so it was clear that I needed something uncommon. The other thing I wondered was how long it would take for an uncommon email address to escape into a spammer's hands or the Internet's spammers hands widely. And this is where Jason's thought of quote. I suspect this might be due to how long I've had the address and how many services I've linked to comes in. What I started doing at least 15 years ago is changing, deliberately changing my email address annually. I'll keep forwarding all previous years email account names into my current email so that I don't miss those, but anything I generate will be from the current year. So an awareness of my current email tends to migrate forward sort of organically. And if at some point some annoying spammer does start using an older email account and if I'm unable to unsubscribe from that, I'll just delete that old account's forwarding into my current account. And here's the surprising breakthrough that this allowed me to discover. I don't understand why to this day I don't. But it appears to take spammers many years to obtain and or to begin using an email address. I often remember John Dvorak's I get no spam proclamation with a smile since now that's also true for me. GRC runs with zero spam filtering none. And spam is not any problem for sue or Greg or me because all of our email addresses are rotated annually. I truly do not understand why this is so that is that we did it works as well as it does, but it does. And it's also Been confirmed by others with whom I've shared this simple discovery. So if you're able to periodically change your email account, I believe you'll be quite surprised to see how long it takes for that new account to be discovered and despoiled by the world's email abusers a few years from now. Let me know. And Leo, any thoughts about email services?

[Leo Laporte]

Most people can't do that because, you know, that would mean that they wouldn't get email, basically. I mean, you don't care, I guess. But we rely on email for so many things and it's not connected. Convenient to say to everybody who sends this email, oh, change our address every year so people keep the same email. They're going to do that. And honestly, this guy possible. I don't. I don't think there's any service that provides effective email filtering. Dvoraks I get no. Spam goes back many years to this, to this company. And if you look at their website, you can see how many years old this is. I think they're still around junk email filter.com so it was on top of his email provider. I think spam is for most of us just a fact of life. And there are all sorts of ways. I mean, what I do is I have an email box that checks against my contact list and that box is the first one I look at. But inevitably I have to go through the spam folder every few weeks to make sure I haven't missed anything. I think spam is. I don't know if there's any real way to avoid spam except do what you do, which is impractical for 90% of the.

[Steve Gibson]

No, all my previous years still come to me, Leo, that's. As I said, I'm forwarding all of those previous years.

[Leo Laporte]

Don't you get spam on that email?

[Steve Gibson]

No. That's what's bizarre. I don't understand why. So people still write to me on old addresses. Comes through with no trouble at all. Anything I generate goes out on today's email. Anyway, I invite our listeners to give it a try.

[Leo Laporte]

There's a puzzle there. That's an interesting idea. Idea you. So you still get all the old email and. But no spam comes on your address from 2008.

[Steve Gibson]

Nope.

[Leo Laporte]

I think you're just lucky. I don't know. I don't know how you do that.

[Steve Gibson]

Just reporting what works for me.

[Leo Laporte]

Yeah, that's interesting.

[Steve Gibson]

And. And has worked for others.

[Leo Laporte]

That's interesting. Yeah.

[Steve Gibson]

A customer of ours, Jeff Parish. I'm a customer. I don't mean a customer, a listener, and also a user of freeware of GRCZ, he says. Jeff Parish wrote, I purchased a 10 pack of PNY 16 gigabyte thumb drives. This is the results I received on two of them so far. I will be checking all 10 now. He attached to his email a screenshot from Valid drives display for two of the 10 packages of the 16 gigabyte PNY thumb drives he purchased. He pointed out that whereas he believed he was only purchasing 16 gigabyte drives, what he received were 32 gigabyte drives that fully pass Validrive's scrutiny. So that was cool. I mean, you know, he got twice the drive for the price. And really it makes sense because sub terabyte thumb drives have become commodity items. So there's actually no cost difference to the supplier between 16 gig and 32 gig media. You know, who would ever imagine the day that that would be true? And frankly, this is one of the reasons why Apple's device pricing always rubs me the wrong way. They are charging so much more for double or four times the memory. You know, as if there was any marginal cost difference for them or nearly that. It just isn't. But you know, that's the game they're playing. Okay, but aside from that, what really stopped me in my tracks about Jeff's thumb drives was the total time spent reading and writing. Valid drive performs a pseudo random spot test by reading and writing 1152 4k regions. 4k byte regions uniformly spread across the drive's self declared size as the drive that you know the size the drive declares itself to be, which is if it's faking its size, we see whether it's telling the truth or not and find that we're unable to read and write spots that it says should be valid and thus valid drive's purpose. So valid drive reads and writes, rereads and rewrites and finally reads again each location gathering statistics while it's doing this. During this process, a grand total of 3.6 seconds, that is on Jeff's drive, 3.6 seconds total was spent reading, whereas 1307.8 seconds was spent writing. Okay, 3.6 seconds spent reading. 21.8 minutes spent writing. Now we know that NAND flash memory is fast to read and slower to write, but this is 362 times slower to write. I believe we're going to find that the better way to express this is that the bulk of this time was spent waiting to begin writing. We know that writing to NAND flash memory requires pushing Electrons through an insulating barrier so that those electrons are then stranded as an electrostatic charge on an insulated floating gate. In order to read bits, it's easy to sense that charge. That's what field effect transistors do. They are affected by the field. But changing that charge requires generating a sufficiently high voltage to create an electrostatic potential that will strongly attract or repel those electrons. To break down that floating gate's insulation, that high voltage charge must be dumped before the data can be read. But it takes no time to dump the charge. But then when immediately switching back to writing, that charge must first be built up again from scratch. And that's where all the time goes. Waiting to be able to start writing after reading. So this inexpensive thumb drive is very, very slow to switch from reading to writing. It's crazy that this first release of Validrive took nearly 22 minutes to validate that 32 gig thumb drive. Which explains why I cannot wait to get back to work on Validrive to create version two. In order to create Beyond Recall, which will be GRC's super secure mass storage drive wiping tool, I'm going to need to develop a bunch of technology I don't have yet. So my plan is for the second release of Validrive to be the development test bed for that new technology. Valid Drive two is going to take a different approach to solving this problem. It's going to read and store the data from all of those 1152.4K locations, then switch into writing mode and write them all with signature data. Then it will switch back to reread and verify them all. Then it will switch to writing to replace all of the drive's original data, then perform one final read confirmation of the replace data. So that will mean two switchings from reading to writing for valid drive 2, whereas valid drive 1 is doing that 2,304 times. 2,304 times it's switching. So I suspect valid drive 2 is going to be much faster, more sure of its conclusions, since it will lay down signature data across the entire drive at once and much more pleasant to use as a result. It's the thing I plan to start working on as soon as the DNS benchmark is finished and ready.

[Leo Laporte]

Take a break.

[Steve Gibson]

Yeah, let's take a break. We've got some more. We got a bunch more really great feedback from our listeners. So I really want you to figure.

[Leo Laporte]

Out why you're not getting spam. This just bothers me because if, I mean, I. I thought the whole purpose of your changing your email was to cast aside the previous year's email address.

[Steve Gibson]

Never, never comes in. The spam never catches up.

[Leo Laporte]

So why do you create a new email address every year?

[Steve Gibson]

Because I want to stay ahead of the pack.

[Leo Laporte]

I mean, I understand if you do that and then say, well, if you don't know this year's email address, you can't email me. But if you're accepting email to all the previous email addresses, I don't get it. I don't understand A, why it would prevent spam and B, why even bother? I mean, unless you believe that it prevents spam somehow.

[Steve Gibson]

I don't get any.

[Leo Laporte]

I'm really trying to figure out.

[Steve Gibson]

So I think I probably have maybe about the last 10 years. And as I said, if I start getting spam on some prior year and I think maybe like three or four years ago, someone started spamming me and I was unable to unsubscribe. Then I just killed that one year forwarding.

[Leo Laporte]

So you kill addresses if you, if.

[Steve Gibson]

They start getting, if they start getting abused. But right now about the. About eight of the past ten years are just. They've never been discovered probably.

[Leo Laporte]

I'm gonna guess it's because you very rarely use email for anything. In other words, you're not exposing your email to people, particularly most of the rest of the world. We use email address all the time.

[Steve Gibson]

I'm not in a position where my email address is being scraped. And I do. It's like my, you know, when you.

[Leo Laporte]

Buy something, do you give them an email address? Yeah, yeah. Do you give them a special email address or your regular email address often?

[Steve Gibson]

My regular email address.

[Leo Laporte]

I don't get it. Then we'll have to figure out what is Steve doing and how can we duplicate that.

[Steve Gibson]

Well, as I said to my listeners, give it a try, see what happens. You may be surprised. Set up a new email account, forward the old one into your new one so you don't lose anybody. Right. And then, you know, see, I mean, I do that.

[Leo Laporte]

I do create new email addresses all the time. But it is very quick for them to start getting spam. But then that's probably because I use them in a variety of places. That may be expo, I don't know. It's an interesting question. If you can just bottle that, Steve, I think you have a future. You could be the new Devore.

[Steve Gibson]

Just wanted to share that no one in my company gets any spam and we don't have any filtering.

[Leo Laporte]

It's fascinating. Our show today, brought to you by Zscaler now actually this is kind of. You're doing kind of a similar idea, at least in my mind because I think of zero trust as not blacklisting, but whitelisting only allowing people to do stuff that's explicitly permitted. That's the idea of zero trust. I don't know, maybe that's. There's something about what you're doing. It's kind of like that. Zscaler is the leader in cloud security. Enterprises have over the years spent billions of dollars on firewalls, perimeter defenses in effect. Right. And VPNs. Because if you've got a big wall built up, you got to have somehow to lock, let people in. Right? Doesn't help breaches continue to rise. There's been an 18% year over year increase in ransomware attacks. Last year, $75 million, a record number paid out to ransomware. That. It's just, it's these traditional security tools are not working. They expand your attack surface because you've got public facing IPs that are exploited by bad actors more easily than ever with AI tools. And of course your VPN struggles to inspect or your firewall outbound traffic. If it's encrypted, right? Which means you're letting people in, then they can browse around inside because what firewalls don't prevent lateral movement. That VPN connects the user to the entire network and just assumes, yeah, you're in. So you must be safe as so what the bad guy does. They get in, they go around, they exfiltrate stuff via encrypted traffic. You can't, you're powerless to stop it. It is not a good scenario. Hackers exploit traditional security infrastructure using AI to outpace your defenses. That's the latest flavor here. It's time to rethink your security. Don't let these bad actors win. They're innovating and exploiting your defenses faster than you can. You need Zscaler. Zero Trust and AI. It's two together. It's zero trust plus AI. It stops attackers by hiding your attack surface, making apps and IPs invisible. You can't attack what you can't see. Right. It also eliminates lateral movement because users are only connected to specific apps app they're explicitly given permission to not the entire network. And of course you're continuously verifying every request for every resource based on an identity, on context. It really locks everything down very effectively. You'll be simplifying security management with AI powered automation. You'll be detecting threats over Zscaler analyzes half a trillion daily transactions looking for the needles in the haystack. Right, the real threats as opposed to just the background noise. And it uses AI to do that very effectively. Hackers cannot attack what they cannot see. Protect your organization with Zscaler Zero Trust and AI. Learn more at Zscaler.com Zscaler.com oh, add this SL security very important so they know you saw it here. Zscaler.com Security we thank them so much for supporting the important work Steve is doing here at security now. Zscaler.com Security all right, Mr. I get no spam. On we go.

[Steve Gibson]

Okay, so as we know, I've only studied AI briefly and enough to satisfy my desire to have some sense for what the heck is going on. So I claim no deep expertise in AI, but I have spent a great deal of time, more than our listeners know. You have some idea of it, Leo quietly studying human brain function. And I've developed a deep appreciation for its complexity. Over the weekend, a question was posed in GRC's Security now newsgroup, which I thought was very much worth asking and very much worth answering. The poster wrote, just wondering if AI developments rely heavily on neural networks and as they start to approach the human brain in capability, can they also suffer from some of the same weaknesses of the human brain with experience, could they start to get distracting thoughts and produce more confused output? A case where adding training data might actually lead to deterioration in performance? Okay, so first of all, yes, I think we already see some of that behavior which those working in the field take very seriously. But I wanted to take a moment to address some of the implications of the questioner's phrase. If AI developments rely heavily on neural networks and and as they start to approach the human brain incapability. One thing our discussion of AI and neural networks never touched upon is the fact that today's current generation of AI uses structures that we call neural networks, while at the same time we all learned in elementary school that that our own human brains are filled with richly interconnected neural cells that creates networks of neurons. I am 100% certain that no one listening to this podcast imagined that there's anything more than a very loose notion of a network of interconnected somethings that AI and our brains might have in common. But I wanted to take this opportunity created by the question to make absolutely certain that even those listeners here who may have not been following all of this very closely, appreciate without any shadow of a doubt that the only thing an AI's so called neural network has in common With a biological brain's neural network is the name. The truth is that calling the addition and multiplication operations that are organized into networks of propagating values neural networks, where the use of the term neural is in any way intended to suggest that any of this bears any resemblance whatsoever to the operation of biological brains is just a joke, a total joke, really. It should almost be an embarrassment to the AI community for anything they're doing to be called neural in any way. You know, but it's certainly true that calling them, you know, what high speed GPU networks, that's far less sexy. A long time ago, when these artificial neural in quotes networks were laboratory curiosities, it didn't matter that they were, you know, what they were called because they were busy learning how to win at tic tac toe and and to play the game of nim. But things have changed radically since that time. Neural networks have obviously moved from the lab into daily mainstream life. So it's to me, and I've talked to my friends and neighbors, it's a little worrisome that the neural network moniker has struck around because it can be so misleading. And that's beginning to matter as this becomes a commonly used term. Everyone in the AI field is very clear that there is nothing whatsoever neural in the sense of a biological neuron about performing massive numbers of factor scaling, multiplications, summating, additions and thresholding. But it's easy to see how the general public could begin to get somewhat creeped out by the idea that our brains are being emulated in some way. They're not. We do not even begin to have the capability or capacity to emulate the tiniest fraction of the complexity of a biological brain. In fact, we don't even have an accurate emulation of a single solitary biological neuron, not even one, because no two are the same. And every neuron's precise operation is unique, involving and including a hair raising number of intrinsic and extrinsic factors. I say that the only behavior shared between these artificial and biological networks is the surprisingly emergent property of their ability to self organize. They both have that. And that behavior, you know, over on the artificial side was discovered and applied more than 50 years ago. That's not new. Since then the work has been about scaling and research to discover the best pre organization of to apply to these untrained artificial networks. But anyway, you know, just, I'm sure everyone's clear about this, but I just kind of wanted to dot the I here. You know, there's a collision of naming where both Artificial networks and biological networks employ the term neural, but that's it. There could not be anything further from the truth that anything about an artificial neural network relates to our biological brains. All they share is a name and nothing else. So I thought it was a neat question because the idea being, oh, if our artificial neural networks start approaching our complexity, what's going to happen? Well, nobody knows how to make anything like a biological brain. And what we have today, which is surprising people, is incredibly simple by comparison. And the fact that they both use the word neural is just kind of a coincidence of history rather than anything else. Back 50 years ago, it was a joke to call them neural networks. It's like, well, okay, let's call them. That doesn't mean anything. Doesn't mean they're like human neurons at all. Biological neurons. Lyle Halett said, I've been a listener of 1009 Security now podcasts so obviously highly appreciate the work you and Leo do to bring it to us. Listeners, I felt the need to comment on the DJI geofencing unlocking issue. I am an FAA certified part 107 commercial remote pilot, a drone operator, as well as a certified private and instrument rated pilot. Okay, so he flies both drones and planes. He says, I utilize two DJI drones and a home built drone to do commercial 3D mapping, photography and videography for the construction, real estate and other businesses. I imagine maybe wedding photography. He says drones that are considered enterprise or commercial, as well as lower priced drones that are considered consumer or recreational can and are routinely used for these business purposes. I just, I love our listeners. This is so great. Here's somebody who's right in the middle of all this. Thank you Lyle. He continues I wanted to clarify that to my knowledge no other drone manufacturers have ever limited where a drone can fly. Any other drone could fly over any of those restricted areas you mentioned, subject only to the will of the operator. The DJI restricted zones were never well aligned with where someone could legally fly a drone in the United States. In many cases their restrictions apply to areas where it's perfectly legal and safe to fly. And he says, and I believe in some cases they even permitted flying in areas where it is not legal to fly. This has been a frustration for pilots like me since I can get FAA and LAANC authorization to fly almost instantly, only to find when doing when going to the site of a job that there was some DJI geo zone that needed to be unlocked. If Internet access was not available, I would be unable to fly. In addition, I had instances where the geo zone kicked in after taking off, limiting my control. Oh boy. Of the drone. He said GPS isn't perfect and can sometimes be widely inaccurate. Combine that with a function that takes control of or limits manual control of the drone, that creates a hazard. Moreover, he said, my biggest concern with the old DJI geozones is that many, particularly recreational flyers, believe that if they're okay, according to DJI geozones, then they're safe and legal to fly, when oftentimes they're not. In many of these areas, they would need to get FAA LAANC approval to be legal and safe to fly, and they simply don't know. Now, since DJI has aligned their warning zones with the FAA areas that need approval, at least pilots will be properly warned to make sure they're legal and safe to fly. I think that on balance, the new system is better for everyone, particularly since no other drone manufacturer, to my knowledge, has ever been doing anything like this. I'm an avid proponent of safe drone flying and probably somewhat obnoxious to people recreationally flying drones when I try to educate them on what they should and should not be doing. I don't know if you have a drone, but I do know that Leo has one. So as part of my drone safety soapbox, I hope he or you, if you have a drone, have taken the FAA trust test and are legal. Sincerely, Lyle from Tennessee. So, Lyle, I better do that. Thank you so much. It is so valuable to receive feedback from someone who has a broader perspective and experience with the subject. It seems very clear that no dji, that DJI was really not giving anyone the middle finger as some in the press and on the Internet suggested, and that they were aligning with the rest of the industry and hopefully making drone operators more responsible by aligning their warning zones with the FAA's guidelines. So, you know, thank you for bringing us a reality.

[Leo Laporte]

Yeah, yeah, I was just ignorant.

[Steve Gibson]

Most people, you know, unless we know from somebody who got experience and doesn't have their own, you know, cross to bear, I hope it doesn't needlessly harm dji. As we know they're the best drones and we would like to still have access to them. Tim Clevelander said. Hi Steve, I heard you talking about the sponsors page on Twitch website. Club members can also find the links to the current show's advertisers in the episode's description in their podcatcher. Thank you for the show. It helped me to not only ace the interview, but when I moved from it into cybersecurity, a few years ago. It also helped me pass my CISSP certification exam last April. Tim. So, Tim, thank you. And I wanted to share that news with anybody else who's looking for where to find the sponsors. We talked about this last week. It's on the TWiT TV website in the upper right of the menu.

[Leo Laporte]

Yes.

[Steve Gibson]

And finally, George Atomopoulos said, Dear Steve, I'm a SecurityNow subscriber for several years. Thank you for all the hard work. I have a remark about the forced Outlook update that you talked about in security now number 1009. So that was last week. As Leo mentioned, Windows already had an email client, Windows Mail. What you did not mention is that this is being deprecated in favor of. Of this new Outlook. In fact, when I tried to open Mail just now, I got a warning that, quote, support for Windows Mail Calendar and people will end on December 31, 2024, unquote. He said, yes, that's in the past. He said next to it is a button to, quote, try the new Outlook, unquote. He said, even if I press nothing, a few seconds later, the new Outlook opens automatically. To add insult to injury, the new Outlook displays ads. Anyway, thank you and once again for the excellent work that you do. Kind regards, George Etymopoulos. Well, there's not much more I can add to that other than to say thank goodness for EM client. I have no idea whether EM client would work for the enterprise, but it looks like it checks a lot of the boxes. You know, they bill it as all compatibility, tool support and so forth that we talked about last week. Google Workspace, Outlook365, Office Exchange and all that. So anyway, that would, you know, I appreciate that and I. Leo, this is what Microsoft's doing now, right? I mean, we've talked about Edge and, and the insidification of all of this. And so here's new Outlook time.

[Leo Laporte]

Even they remember Outlook Express.

[Steve Gibson]

Yeah.

[Leo Laporte]

And they changed it and turned it into Live Mail. And then they. And then I think there have been a couple others since then. They just kind of do this on a regular basis. I guess it makes sense. You have a lot of technical debt built up in a mail client. Maybe sometimes it's good to start over.

[Steve Gibson]

Yeah. Yeah. Okay, our final break. And then we're going to talk about the expense of encrypting our DNS. From my own personal experience, about a week or two.

[Leo Laporte]

Oh, I can't wait. Well, there's not much to say on this break, except we thank our club members for making this show possible and we encourage you, if you're not a club member, to think about joining the club. We keep it affordable. Seven bucks a month. That's so that everybody can participate. We don't do a paywall, really. We, you know, this show is available to for free ad supported to everybody. But we, we do need some additional support. Advertising no longer covers the entire cost. We've cut back as much as we can. We shut down the studio, we canceled shows, we even had to lay off some people. But I don't want to do that anymore. And with your help, we won't have to. In fact, with your help, we could even grow and do more shows. If you appreciate what you hear here, I invite you to join the club. It's seven bucks a month. There are some benefits. You get access to Club Twits Discord, where there's a great community talking about all kinds of stuff 24. 7. You get access to special shows we put out just for the club. Our coffee show, Chris Markworth's photo show is coming up. Micah's got a crafting corner, things like that. We, you know, just to make it fun, we do fun things. And then of course, you could add free versions of all the shows with special RSS feeds just for you as a club member. All of that at TWIT TV Club Twit. I'd just like to invite you, if you're not already a member, to consider joining to support the work Steve's doing here and everybody else. It is not inexpensive, but your help really does make it possible. Twitter, TV Club Twit. That's all. Just wanted to say that. And now back to Steve.

[Steve Gibson]

Okay, so DNS over tls. I wanted to share my experiences thus far with the implementation of GRC's DNS benchmark, which as we all know, I'm in the process of updating to support IPv6 and the various encrypted DNS protocols that are increasingly being used to protect the privacy of users web accesses. And I think everybody's going to find this interesting and a little surprising. What I discovered was initially surprising to me until I sat back and thought about it a bit. And I believe, at least for intellectual curiosity sake, it'll be of use to our listeners. As I've mentioned before, GRC's original DNS benchmark, which I first wrote 16 years ago, provided a complete solution at the time for determining the performance of the DNS servers that everyone could choose to use. But as we know, times change. That first Release was strictly IPv4 and there was no notion of encrypting DNS for privacy. All of that has changed during the intervening 16 years. IPv6 is slowly but steadily coming online, with all recent operating systems, most ISPs now, and the intervening equipment such as consumer routers now supporting IPv6. So it's on the desktop. During the past 16 years, we've also witnessed a massive transformation in the monetization of the Internet's users. Who we are, who and what interests us and where we go is all up for sale. That information is being used to generate additional revenue for everyone at every stage of the pipeline, from the websites we visit and the Advertisers to our ISPs who connect us to the Internet. Since many who use the Internet would prefer to do so with as much privacy as possible, the ability to encrypt DNS queries which otherwise advertise our every whim and desire is of growing interest. In response to this growing interest, all of the major public DNS providers such as Google, Quad9, Cloudflare and many others already offer fully encrypted DNS services. Our routers and web browsers offer support, and it's already built into Windows 11, so it's easy to have. To the best of my knowledge, no one has ever answered the question of how much DNS query performance is sacrificed to obtain the privacy offered by encryption. How do DNS encrypted lookups using encrypted TLS or HTTPs connections compare to traditional in the clear DNS over udp? And even if this weren't a concern, I could hardly offer an updated DNS benchmark today that didn't also benchmark IPv6 dot and doh in addition to traditional IPv4. As I mentioned before, when Leo and I were talking about the work I've been doing recently, the first major change was restructuring the entire DNS benchmark to use any protocols other than IPv4. Since IPv4 addresses are all 32 bits long, and since the DNS benchmark was written for Windows win32 API 16 years ago, I took advantage of the ability to hold any DNS Name Servers IP In a native machine 32 bit register, the switch to IPv6's 128 bit addresses, not to mention dot and doh name servers which are addressed by URLs just like web pages, meant that needed a change. 32 bits, no more. Today's DNS benchmark is now, as a consequence of the updating work I've done so far, completely protocol agnostic, any protocol can be added to its underlying structure, which has largely been rewritten, so it's now ready to handle today's newer DNS protocols and and whatever else the future might hold going forward. After the benchmark's fundamental redesign, the first thing I did was to add support for IPv6 name servers, since that was just a matter of adding more name server address bits, making room for longer IP addresses in the user interface, and teaching the benchmark about the funky zeros compression that's used to shorten the many IPv6 addresses that contain one or more words of all zeros. Then it was on to tls and things suddenly became quite a bit more interesting. Windows has an API known as Secure Channel, or S Channel for short. Using the API takes some getting used to, since it was designed to provide an interface, sort of a generic interface to a large collection of very different underlying secure protocols, of which TLS transport layer security is only one. So this requires the user to do weird things like repeatedly call into the API until we're told that it that its needs have been satisfied, whatever they may be. It's all deliberately opaque, so as a coder you just have to sort of shrug and say okay, follow the weird rules and hope for the best. However, no one explained the API to me like that. In fact, the entire thing is woefully under documented. So I spent some time staring at what few examples I could find online, wondering whether what I was seeing could possibly be correct, since, as I said, it's really quite weird. I've been documenting my journey through all of this in GRC's public news groups, and I'm currently at the fifth generation of this TLS support system. The code that I finally have is actually quite lovely and I'm proud of it. It's far more clear and clean than anything I found online. And someday, after I've pulled the plug on GRC and I release all of the source code of my work, which is my eventual plan, I'll be glad to have contributed to cleaning up the mess that Microsoft created with this weird S Channel API. And I will make a point of inviting the world's AIs over to dig around in that source code so that they might be able to help others quickly get to where I wound up. So my point is, I have TLS working beautifully now, but that's where some real surprises that Microsoft had nothing to do with were encountered when GRC's DNS benchmark started, or is started when you start the program fire it up, it loads the list of DNS name servers it will be testing for every name server. It sends a couple of test DNS queries to verify that the name server is online and reachable from the user's current location and connection. It also uses the system's standard DNS name servers, whatever name servers are configured on the Windows desktop to query a couple of public databases to obtain the ownership information about the IP address space housing the name server to create a richer experience and provide more background information about all these IP addresses, who owns them. Because that's not otherwise clear from an IP address, the URLs which the encrypted name servers use does tell a much richer story. So here's where we first encounter the biggest difference between traditional DNS and any form of encrypted DNS. Traditional DNS is carried over the UDP protocol. UDP stands for User Datagram Protocol. When a user computer When a user's computer wishes to look up the IP address of a domain name, that domain name is packaged into a single Internet UDP packet, and it's sent to whatever DNS name server the user's computer has been configured to use. And that's it. Package the domain name into a packet and send it out onto the Internet with the destination IP of one of the user's configured name servers. Hopefully, the packet arrives at its destination. When it does, the name server examines it, takes whatever actions may be needed to obtain the IP address that's been requested and eventually replies by appending the answering IP to the user's DNS query, which also fits into a single packet. The original DNS protocol designers understood the value of keeping everything tucked into single packets so DNS doesn't miss a trick when it comes to quick hacks to eliminate any redundancies in DNS queries and their replies. If the sender of the query doesn't receive a reply within a reasonable length of time, either the query or the reply packets may have been dropped by a router. Along the way, they'll simply ask all of the name servers they've been configured for and accept the first reply they receive. They just try again. But typically on a retry, they ask everybody. What we have as a result is a truly elegant and minimal system. One Internet DNS query packet goes out, finds its way across the Internet, and is received by the user's designated DNS name server. That name server makes it its mission to get the answer to the user's DNS query, and once it has it, you know it might just be as I talked about earlier. It's got the Amazon.com, got the IP right there in its cache. It just immediately sends the the answer back. Either way, once it has the answer, it sends the reply back in another single packet. It's beautiful. Yes, it is. Unfortunately, what it also is, is ruthlessly hostile to encryption. It offers no privacy. Now we know what encryption requires. At the bare minimum, encryption requires that the entities at each end of any connection share a secret that no one else can possibly know. They then use that shared secret to encrypt and decrypt the messages they send back and forth. So how do they obtain that secret? We know that there are key exchange mechanisms that make establishing a shared secret in full view of the public possible, but they're vulnerable to man in the middle attacks. And we know that the only way to prevent a man in the middle attack is to be able to positively authenticate the identity of the party we're connecting to. The way that's done using the technology we currently have requires a certificate, and certificates are large, like between 3 and 6k. What this all means is that just asking for a tiny little bit of privacy here for our DNS queries and their replies completely blows all of the original elegance of DNS's fast and lightweight single packet queries and replies out of the water. All we want is for a single packet not to be eavesdropped on. But the realities of the Internet means that in order to do that, we have no choice other than to drag all of the massive overhead of connection security along for the ride. The other thing I didn't explicitly mention is that all of this back and forth exchange of certificates and handshaking and encryption protocol enumerations and agreements, on top of all of that, we cannot just have packets getting lost along the way. So the only way to carry on this dialogue, which has suddenly become much more complicated, is by moving from the minimal elegance of single packet udp, the user datagram protocol, to the reliable delivery system provided by tcp, the transmission control protocol. So that's what I built. That's TLS on top of tcp. For every remote name server that the DNS benchmark will be testing, it looks up the IP address for that name server's domain name. Because again, remember, encrypted name servers are referred to by domain names. Just like web pages, they've got URLs. So we look up the IP address of the name server's domain name. Whereas the original standard port for DNS is port 53. The standard port for TLS encrypted DNS is 853. So the benchmark establishes a TCP connection to the remote name servers port 853. It then initiates a TLS connection negotiation, negotiating encryption protocols, receiving and verifying the remote name server's certificate, because that's part of TLS agreeing upon a shared secret key and then bringing up the encrypted tunnel. And that's that whole weirdly opaque S channel API stuff that I spoke about earlier. Okay, at this point, yay, we have a connection to a remote DNS name server over tls, which should allow us to send and receive DNS queries. So it was with great joy and celebration that I got all of that working, whereupon the remote name servers began unceremoniously disconnecting and dropping their connections without warning or reason and with prejudice. I thought what? I tried it a few times, and the same thing kept happening. It seemed that these name servers were, I don't know, impatient for queries, and they were not being uniformly impatient. Some would drop the connection after a second, some would wait five seconds or in between, but without fail, the connections would be dropped. So I figured that perhaps they were getting annoyed with me for getting them on the line and and not immediately asking them for some DNS resolutions. So I started having the benchmark send them DNS queries to answer over this newly created connection. This maybe worked a little better. Things were definitely working. The connection was up and TLS was running. I was able to use wireshark to observe the transactions, the packets moving back and forth across the wire, and I was receiving valid answers to the benchmarks queries. So we were on the right track. But without warning, even in the midst of DNS queries and replies, the remote ends were still getting fed up with my questions and dropping connections. After sitting back and thinking about this for a few minutes, the reason for this all became obvious. Compared to unencrypted UDP queries and replies, TCP and especially TLS over TCP connections are incredibly expensive, not only to establish, but to maintain. Traditional UDP DNS name servers have been so spoiled compared to almost all other servers, they receive a UDP query packet to which they reply with an answering UDP reply packet, and that's it. Period. Mission accomplished. Thank you very much. We've talked about all of the back and forth that's required to establish a TCP connection, and then even more for TLS once the TCP connection is established. But there's another significant cost to maintaining a connection. Both TCP and TLS require each end to maintain a great deal of state information. Since TCP numbers every byte that's sent and received, it's responsible for providing reliable delivery of anything sent and acknowledged, and acknowledging the receipt of everything received. It needs record keeping to make all of that happen. And that also means that the TCP IP stack needs to be aware of the existence of all of the many various connections to everywhere, so that the incoming and outgoing packets can all be routed appropriately. And once the packets pass through the TCPIP layer, the TLS protocol has a bunch more of its own state. It needs to retain the knowledge of the specific TLS encryption protocol and the version that was negotiated with the end and the shared secret key for encrypting and decrypting the data, and the state of all the many options that have been added to TLS from the start of SSL up through TLS 1.3. In other words, a lot. And now consider all that in comparison to plain old standard DNS queries over udp, which has none of that. None. A packet arrives and a reply is returned. DNS over UDP has no state, nothing to remember between queries, no state to preserve, no connections, nothing. So now we switch back to those big iron DNS servers that are being operated by Quad9, Google, Cloudflare and many others. Think of how many thousands or tens of thousands of clients queries they may be handling every second of every single day. For udp, that's no problem. Pack it in, pack it out, they just do it. Done. They reply to every query and forget about it. But for DNS queries that need to establish a TCP connection, then negotiate a TLS secure tunnel on top of that, all before even the first DNS transaction. That's one heck of a lot of overhead. And now imagine with this expensive connection established, the client expects this busy, widely shared public name server to just sit there with a TCP connection established and TLS crypto negotiated and wait for the client to ask a question. Not happening. There's no way busy and super popular name servers can possibly afford that. They cannot afford to tie up their precious RAM memory with all of the state tables and flags and options and every single one that every single one of those connections requires, only to have the client not immediately needing and using its services. So it should come as no surprise that these name servers are exhibiting very little patience with inactive connections, and that even with active connections, they're only able to give anyone who asks a limited amount of their time. Given all of this, you might be inclined to wonder why all of this works at all. How can encrypted DNS, which is so much more expensive than good old DNS over udp, be be the future? The answer is that web browsers use of DNS is inherently bursty. When a user clicks a link to jump to a new web page that it's never visited before, and assuming that the browser or the operating system is configured to use DNS over TLS or DNS over HTTPs, a connection will be brought up to the remote name server to obtain the IP address of the site. Once the IP address is obtained, the browser will immediately connect to that remote web server to obtain the destination web page. Today in 2025, fully populating a typical web page requires the resolution of an average of between 50 and 150 DNS domain names. Those are the domains for the advertisements, the script libraries, the images, the various tracking gizmos, and all of the other goop that runs today's web. So upon downloading and obtaining the destination web page, the user's web browser, which would very likely still be holding open the connection to the remote name server, will send off a blizzard of those 50 to 150 DNS queries over the previously negotiated secure and encrypted TLS tunnel. And that will pretty much be it for a while. The user's web browser will have collected all of the IP address responses it needs to fetch all of the rest of the page's contents. So if either it or the far end decides to drop the expensive to maintain TCP TLS connection, who cares? This is what I meant when I said that DNS queries are inherently bursty. They generally arrive in a very brief flood with a display of a new page, which the browser then renders and the user examines and ponders before eventually clicking another link which generates another brief flurry of queries. And so it goes. This means that bringing up a relatively short lived and very expensive to maintain TCP TLS connection winds up being cost effective. It's true that doing all of this connecting, establishing and negotiating takes time and multiple many packet round trips. But once it's been done, the DNS queries and replies are able to occur with the same speed as regular DNS, even though they're now encrypted with the same state of the art crypto protocols we use to protect all of our other Crown Jewels. And if 50 to 150 queries are being sent in a burst. The time required to set up the connection can be amortized across all of the DNS work that can get done once the connection is ready, the user will not experience any different page loading performance than before. Also, the TLS protocols offer session resumption features where the answering remote server bundles up all of its post negotiation TLS state information, encrypts it under its own local secret key, and hands it back to the client to keep at the end of their initial connection negotiation. This allows the client to cache that opaque blob, which it's then able to return and offer to the server the next time it reconnects to that same server. The server receives the blob, decrypts it using its own private key which no one else has, and if everything matches up the client and the server are able to bypass, or all of the time consuming and expensive TLS renegotiation to pick up right where they left off. Having thus understood what's going on with name servers, GRC's benchmark is now working with every one of them. I have found I've got a long list and since DNS over HTTPs just wraps the DNS query and its response inside HTTP protocol which also runs inside tls, I expect to have that added and running shortly. And now everyone has a much better sense for how the industry is moving forward to encrypt the last of the simple plain text protocols which has survived until now. I imagine that DNS over UDP will someday go the way of good old unencrypted HTTP which we hardly use any longer.

[Leo Laporte]

Bravo. You have to you need some sort of musical note at the end of the like a ta ta ta ta ta ta ta da. Steve Gibson, always a pleasure. Thank you so much for the job you do and the information that you pass along. I know everybody who listens looks forward to Tuesdays. That's when we do the show right after Mac break weekly about 1:30pm Pacific, 4:30 Eastern 2030 UTC. It's not a TV station. We don't begin exactly. We begin when the last show is over and all the buttons have been pushed and we begin. So it's going to be a little loose. Don't get too upset if it's not exactly 1:30, but it's roughly around there. I only mention that because you can watch it live. It's by far the least popular way to watch it, but you can watch it live. We stream on eight different platforms. Club Twit members can watch in Discord, but There's also a YouTube live stream, Twitch, TikTok. Yes, TikTok, X Facebook, LinkedIn, Kik, and something else. I can't. I've. I've. I gotta make a list. I usually can do it by memory, but I'm missing something and I can't think of what. X Facebook. Anyway, you don't have to watch live. The whole idea is this is a podcast. So if you aren't around in the afternoon on Tuesday, all you do is you go to Twitter TV sn. You can download it there. Better yet, go to Steve's page, GRC.com because while you're there, you can pick up a copy of spinrite. Everybody should have spin, right? If you've got mass storage, it's the world's best mass storage maintenance performance enhancing and Recovery Utility version 6.1 is there. While you're there, pick it up. Then go to the Security now page. Steve has the 64 bit kilobit audio that we both have. That's kind of the canonical audio version, but he also has a 16 kilobit version for the bandwidth impaired. And really nicely written. Human created, not AI created transcripts. Lane Ferris does a very good job with that. That's nice to have because you can download that, follow along as you listen, use it to search. Or you could search on his site and search it there. It's a. And it's just a handy thing. Make it maybe a spiral notebook and bind it in. And then you'd have all of the episodes. You could read along and listen along and that kind of thing. We have, of course, the 64 kilobit audio at our webpage, but we also have video and there are some people who like to see the. Steve's blinking lights. Did you get it? Did you get them all?

[Steve Gibson]

They're blinking away, Firing them all up.

[Leo Laporte]

Is it just a reboot or do you actually have to enter a code?

[Steve Gibson]

No, I just flip a few switches. Yeah, it's essentially a restart.

[Leo Laporte]

Yeah, I just unplugged my PDP 11, plugged it back in again.

[Steve Gibson]

Oh, it's going again.

[Leo Laporte]

Yeah, nice. The bottom one, the inside, I do have to start a program. I have underneath it, I have a piece of paper. They flip that switch up, flip that switch down, then toggle that switch in it and it gets it blinking.

[Steve Gibson]

So the videos, we used to have dents in our fingers from, from. From pushing all the little switches up and down.

[Leo Laporte]

Yeah, guys, just nuts. Just nuts. So get the video. You know, subscribe. You can subscribe in your favorite podcast player. And get audio and. And video. Audio or video. So a lot of different ways you can watch the show or listen to the show. We do. Hope you'll do that every week if you're a club twit member. Even better. You get ad free versions of the shows for seven bucks a month plus a lot of other benefits. It is still possible to buy it individually, I think, for $5 a month on Apple. And I. I think we also offer that on YouTube. So you just buy an individual show. But do me a favor, Spend a couple bucks more and get them all. Why wouldn't you. Why wouldn't you want to. Anything else to say, Steve? Are we. Are we done here?

[Steve Gibson]

We got it.

[Leo Laporte]

I think we got it all.

[Steve Gibson]

And I'm excited, too, because we'll be back next week with another episode that only has ones and zeros. It'll be 10:11, which is episode 11.

[Leo Laporte]

If my binary rhythm arithmetic is correct.

[Steve Gibson]

That is correct. And it will not be until our episode 1100 that we're back to ones and zeros, so.

[Leo Laporte]

So enjoy it while you got it, is what you're saying.

[Steve Gibson]

Yeah. Thank you. That's what I'm saying.

[Leo Laporte]

We'll see you next week on Security Now.

[Steve Gibson]

Bye.

[Leo Laporte]

Security now.