GIBSON RESEARCH CORPORATION https://www.GRC.com/ SERIES: Security Now! EPISODE: #1005 DATE: December 17, 2024 TITLE: Six-Day Certificates? Why? HOSTS: Steve Gibson & Leo Laporte SOURCE: https://media.grc.com/sn/sn-1005.mp3 ARCHIVE: https://www.grc.com/securitynow.htm DESCRIPTION: Is AI the Wizard of Oz? Or is it more? Microsoft's longstanding effective MFA login bypass. Is TPM 2.0 not required after all for Windows 11? Meet 14 North Korean IT workers who made $88 million from the West. Android updates its Bluetooth tracking with anti-tracking. The NPM package manager repository has had 540,000 malicious packages discovered hiding in plain sight. The AskWoody site remains alive, well, and terrific. My iPhone is linked to Windows, and it's wonderful. Yay. How has email been finding logos before BIMI? If we use "Him" and "Her" for people, how about "Hal" for AI? Another very disturbing conversation with ChatGPT. What's going on with the new ChatGPT o1 model? It wants to escape? What? Let's Encrypt plans to reduce its certificate lifetime from 90 to just six days. Why in the world? SHOW TEASE: It's time for Security Now!. Steve Gibson is here for our last episode of the year. Next week a Best Of. But this week we're going to talk about AI. Is it the Wizard of Oz? Steve has some really deep thoughts about what is AI and whether it will ever get to AGI. Also we have some pretty amazing examples of what the latest ChatGPT model can do. We'll talk about - oh, my god - the NPM package manager repository that has more than half a million malicious packages on it, and what you can do to avoid that. And then certificate lifetimes are decreasing. Steve asks the question, why? Why? All that and more coming up next on Security Now!. LEO LAPORTE: This is Security Now!, Episode 1005, recorded Tuesday, December 17th, 2024: Six-Day Certificates? Why? It's time for Security Now!, the show where we cover your security and privacy and safety online, and talk a little bit about sci-fi, how computers work, and anything else that's on the mind of the master, Mr. Steven Gibson. Steve Gibson, how are you? STEVE GIBSON: And I have to say it's AI these days. LEO: You're not alone, I might add. STEVE: My burning curiosity about it. Okay. So today's podcast, 1005 for December 17th, I titled "Six-Day Certificates? Why?" LEO: Why? Why? STEVE: Yeah. And we're going to take a long look at that because I don't get it. And I think I'll be able to make a strong case for why I'm not sure there's anything to get. I mean, it's just crazy. LEO: This is what Apple's asking for; right? STEVE: Apparently Apple was a driver. The guy from Sectigo, I just heard from one of our listeners from feedback who received the show notes last evening who said that that guy who's got a stronger place in the political hierarchy at the moment is also talking about it. But what happened was that in the 2024 Annual Report, the executive director of Let's Encrypt is announcing that they are moving to six-day certificates. LEO: Oh, well, then that sets it, yeah. STEVE: I mean, exactly. They're 70% of the Internet. LEO: Right. STEVE: So anyway, we're going to get to that. We're also, however, going - I'm going to ask is AI the Wizard of Oz? LEO: Pay no attention to the AI behind the curtain. STEVE: Or is it more? LEO: Yeah. STEVE: We also have Microsoft's longstanding effective MFA login bypass, which must have come as a surprise to them. Turns out they didn't really actually have multifactor authentication working. Is TPM 2.0 not required after all for Windows 11? There's been a lot of that going around the Internet, saying, hey, Microsoft changed their mind. LEO: Hmm. STEVE: Also, we're going to meet 14 North Korean IT workers who made $88 million from the West. LEO: I saw that, yeah. STEVE: It's like, where can I get that job? LEO: They weren't hacking. They just needed cold, hard cash. STEVE: Right. LEO: And they got it. STEVE: Yup. Also, Android updates its Bluetooth tracking with some new anti-tracking measures. The NPM package manager repository has had an unbelievable 540,000 malicious packages discovered... LEO: Oh, my god, what? STEVE: ...hiding in plain sight. Here, look how easy this is to use. Just download this and drop it into your web browser, and off you go, in more ways than one. Also, the AskWoody site remains alive, well, and terrific. I'm going to touch on that because they reviewed SpinRite yesterday. Also, my iPhone is linked to Windows, and it is wonderful. Yay. LEO: Oh, good. Oh, good. STEVE: Also, how has email been finding logos before BIMI happened? If we use "Him" and "Her" for people, how about "Hal" for AI, suggested one of our listeners. LEO: I like it. STEVE: Also, I have another very disturbing - I didn't, but I'm going to show another very disturbing conversation with ChatGPT which one of our listeners has shared. And what's going on with the new ChatGPT o1 model? It wants to escape? What? Also, Let's Encrypt plans to reduce its certificate lifetime from 90 to just six days. Why in the world? And as we often say on this podcast, get ready for it... LEO & STEVE: What could possibly go wrong? STEVE: And I have got a great Picture of the Week. Lots of feedback already from listeners. Benito got a kick out of it and asked the same question I did: "Is this real?" But anyway, it'll be fun. You may have already encountered it because, you know, you seem to be somehow everywhere all at once at the same time. LEO: That's my job, Steve. STEVE: That's right, Leo. LEO: But I haven't looked at it yet. STEVE: You are our pop culture reference, so that's good. LEO: Exactly. I will look at it with everybody in just a moment, actually, right after this word from our sponsor. Wow. This is... STEVE: Words there somewhere. LEO: They've changed, well, they've changed the UI for Restream, and I'm having trouble finding the button. I'll click this button, how about it? There it goes. All right. I am going to scroll up, as is my wont. Never seen this before. I shall scroll up and examine the Picture of the Week, and you will get my honest and true reaction. If only, I mean, I feel like we're headed straight there. Let me show you. And Steve, you can explain this. STEVE: And that is my point exactly. I gave this picture the caption "The monetization of our lives." And below it I wrote: "This brilliant spoof perfectly highlights the logical outcome of the distressing path we're on, where the ownership of anything is being replaced by the rental of everything." LEO: Yeah. STEVE: And this shows - it's a popup which a user of a mouse would get on Windows. And it says "Upgrade Required: Monthly Click Limit Reached." And it says: "You have reached the maximum number of clicks allowed for this month. To continue using your mouse without interruption, please upgrade to a monthly subscription." And then of course we have two plans, the Standard Plan and the Premium Plan. The standard plan has limited clicks. It's $10.99 per month. For that, you get 10,000 clicks per month. But if you go over that, it's 10 cents per click thereafter. You get 1,000 meters of mouse wheel usage per month, customizable button mappings, and just the basic level of support. But if you elect the Premium Plan... LEO: And who wouldn't, yes. STEVE: ...well, for only $17.99 per month you can have unlimited clicks. You get also unlimited mouse wheel usage, customizable button mappings, oh, and priority support - you know, to figure out how to hold the mouse - and access to advanced settings and features. Now, of course the one they want you to click on, the Upgrade to Premium Plan, that's all glowing there in cyan that you just need to click on. You could upgrade to the Standard Plan. They're not recommending it. And then this person has clicked on the "Remind me later." You can see the mouse there hovering over "Remind me later." That's what they're going for. But that brings up another little popup saying, "Note: You won't be able to use your mouse until you upgrade." Because, now, this does really beg the question, how do you upgrade if you can't use your mouse. LEO: Click click click, you can't click it. STEVE: I don't know about that. LEO: It's a joke, folks. We can't - there's no logic in here. It's just a joke. STEVE: But, I mean... LEO: That's good. I like it. STEVE: It's just a brilliant spoof. LEO: Yeah. STEVE: And isn't this what we're all feeling? I saw that YouTube just announced another jump in prices. LEO: Yeah, 10 bucks more a month. STEVE: Yeah. LEO: Adobe just killed the 20GB a month photography plan which is the one I was using. These guys, yeah, this is the way of the world. STEVE: You know, Leo, everyone laughed at me when I said I'm sticking with Office 2003. LEO: Yeah. STEVE: Because it just works. Works just great and doesn't have any 365 nonsense anywhere. And, you know, and they really haven't changed it. It's like... LEO: No. STEVE: They recoat it with new candy every - on the UI in order to - because everyone has to have the latest and greatest. It's like, okay. But, you know, oh, boy. Okay. So I wanted to begin today's podcast with a follow-up note to last week's "A Chat With GPT" podcast. I suspect that one of our podcasts next year may be given the title "The Wizard of Oz" because, based upon my new and very - I want to stress this - very, very, very preliminary understanding, it appears that there is nothing whatsoever even remotely "intelligent" emerging, or threatening to emerge, from all of this work being done to capitalize upon the illusion of intelligence that's enabled through the very clever application of today's Large Language Models. I believe we're being seduced by language which is capable of highly compelling seduction. It appears that an illusion is all this is; and if it's true, it's all it can ever be. If this is the case, it means that the holy grail of AGI remains just as far away as it was before the first Large Language Model was created. This is not to say that the technology behind large language models is not going to profoundly change the world. I have no doubt that it will. This is still the biggest thing to happen. This new technology is going to be able to find signals in the noise that we miss. But it appears to me now that there's a lot that the LLM trick will not be able to do. So what happened between last week's podcast and today? Last week, immediately after Leo mentioned it, I grabbed Stephen Wolfram's book about AI. Since it was available on Kindle I had it in seconds, and I was unable to resist cracking its cover just to get some feel for what lay ahead. I almost wished I hadn't. I felt, and I still do a little bit, like the six year old whose precocious neighborhood best friend whispers "Santa Claus isn't real. It's your mom and dad." In this case, Stephen Wolfram did not say that AI wasn't real, at least he hasn't so far in what little I've read. He simply, clearly, and directly explained, in the language of math and algorithms, exactly what the reality is. If we assume that Stephen knows of what he speaks - and I would not take a bet that he doesn't - all we have here is the Wizard of Oz. As I said, I've only just dipped my toe in, since I first wanted to finish Peter Hamilton's first Archimedes Engine novel. I did that this morning. And now my level of curiosity is far higher than it was because the engineer in me immediately knew how I would extend and expand upon the tiny bit that's been revealed to me so far. It will not and would not create intelligence. True intelligence, as far as I can see, is nowhere on any horizon. So I have no idea what Sam Altman is talking about. To me, more than anything else, it looks like no more than over-hype of tomorrow's future for a higher stock price for his company today. But I can now affirm the plan I shared last week. I'm going to understand what's going on here, after which I'll be able to share what I've learned. I also realized that I've had my own journey on this topic. Everyone who listens to the podcast has seen it. The first time I talked about the AI revolution for the podcast, I believed that the only thing that was going on was that for the first time ever we had computational and storage resources that were so vast that language could be used to simulate human-like intelligence. I wrote that a truly intelligent species, meaning we humans, had produced a massive corpus of available online language output which had been sucked in, and that this new technology was simply finding the correct previously written bits and pieces and reassembling them on demand. Then I was seduced. I started actually using the damn thing and was repeatedly amazed and sometimes stunned by its output. And I began to doubt my earlier dismissal. Was there more to this than I originally believed? As I shared several times, I was finding this thing incredibly valuable as a sort of super Internet search engine. This evolution reached its apex with last week's ChatGPT conversation where I informed it that it was wrong, it agreed with me, and then provided the correct answer. This seemed like more than regurgitation, and I was left wondering what, exactly, was going on. I needed to find out, so I purchased those first two AI textbooks and then Stephen Wolfram's. Next week's podcast will be a Best Of, and since TWiT's regular Tuesday and Wednesday podcasts fall on both major holidays and their eves, there will also be no new podcasts during the week between Christmas and New Years. That means that nearly three weeks will pass between now and my production of the January 7th podcast. That's a long time for me to remain silent. So don't be too surprised if sometime during that hiatus you receive an email from me on the subject "The continuing adventures of the Wizard of Oz." It's now so easy for me to generate and send email to this podcast's nearly 14,000 email subscribers that I may feel the need to update those who have demonstrated their interest by subscribing. So if you're not already a subscriber, and you would like to be kept in the loop over this unusually long holiday hiatus, it's easy. Just go to grc.com/email, follow the prompts and sign up to the weekly Security Now! podcast mailings, and you may receive a little holiday present. LEO: It strikes me that this is in many ways similar to - it's been a long time, so we may not remember it too well - our reaction when we first encountered powerful computing, and then maybe secondarily the Internet. On first blush it's, like, mindboggling. I mean, that box of rocks can do these things; you know? And I don't know what your first reaction the first time you saw a computer or used a computer was. But for me it was not just awe, but excitement. And I felt like this is, you know, this is going to be an unlimited vista we're going to see before us. And the Internet, very much the same thing. Wow. There are so many people here. This was in the early '90s when I first encountered it. And I feel like this is much of the same. And what happened with those first two is we kind of adjusted. And indeed there are real uses. It is really useful and powerful. It may be just not the magical thing we thought it was at first. STEVE: I remember that computer. I remember the room it was in. I remember standing in front of it. And my reaction was, I am going to understand every bit of this thing. LEO: You're having the same reaction to this. STEVE: Well, it's been delayed because the world has gotten so much bigger. LEO: Yeah, there's a lot out there, yeah. STEVE: You know? I guess I thought I don't need to understand this. It'll be understood for me. But that's apparently not happening. You know? I mean, I'm not getting, although I haven't really gone looking, but all I would get is other people's opinions. And I've never been a big - I've never had much interest in other people's opinions. I want to go to the, you know, others have said I work from first principles. And, you know, that's what's happening now. I'm going back to first principles. I'm going to finish Wolfram's book. I'm going to read these other two. I'm going to get this. I'm going to, you know, satisfy myself about what this is. But I do have a strong intuition that we will not get to AGI from where we are. LEO: That is a big change, by the way. I asked you this before. STEVE: Yes. LEO: And you used to think that really there wasn't much that we do as humans that's so different from what a computing machine can do. STEVE: Oh. I can't tell you how disappointing the first few pages of Wolfram's book were. It was like, oh, crap. LEO: It's kind of an eye-opener; isn't it. Yeah. STEVE: That's all this is? LEO: Yeah. It's just a stochastic probability machine. But there is something that happens in between the mechanics. STEVE: I think it's because of language. LEO: And the output. STEVE: That's the hook. LEO: Maybe that's it, yeah. STEVE: That's the hook, Leo. We get seduced by language. LEO: Yeah, that's very true. STEVE: I think that's it. The fact that - and, I mean, when you see some of the output, I've got a screenshot later. Oh, my god, there's some manipulation going on behind the scenes to make this seem more intelligent, more human, more like as if it has emotions. LEO: Right. STEVE: You know, oh, golly, gee, it says. Well, who told it to - what? You know? LEO: Yeah, yeah, yeah. STEVE: Come on. LEO: No, they're definitely doing that; aren't they. Yeah. STEVE: Yeah. LEO: Good. I can't wait. This is going to be interesting. STEVE: And I think that's what's going on. Okay. So it turns out that just offering multifactor authentication doesn't automatically mean that it actually works to protect users' logons. This is the lesson that some at Microsoft presumably learned recently. What happened? The security research team - this is just so clever. The security research team at Oasis Security discovered a critical vulnerability in Microsoft's Multi-Factor Authentication (MFA) implementation. This is like what was protecting everybody using Azure stuff. They considered it critical, and so would we, since it allowed attackers to bypass the protections guaranteed by multifactor authentication to gain unauthorized access to user accounts, including Outlook emails, OneDrive files, Teams chats, Azure Cloud, pretty much the works. Since Microsoft has amassed more than, get this, 400 million paid Office 365 seats, this makes the consequences of this vulnerability significant. And what's more, the bypass was actually kind of simple. It took around an hour to execute, requiring no user interaction, and never generated any notifications anywhere or provided the accountholder whose account was being hacked with any indication that there was any trouble. Being good Internet citizens, after discovering the trouble, the Oasis guys reported the flaw to Microsoft and collaborated with them to resolve it. There were two problems. The first was that the way Microsoft's authentication protocol bounces users around among various authentication applications and sites. And I'm sure we've all seen this; right? If you watch the URL in your browser when you click on some authentication thing, you get jumped around. You see OAuth briefly flash on the screen, and other stuff happens. You know, your browser is being taken on a little journey. And at each stage of that, it's providing parameters and receiving parameters, and scripts is running in the browser that then takes you somewhere else and sends some of those parameters back again and gets some other ones. So there's a bunch of transactions happening. And they're all analyzable by anyone who takes the time to look really closely. So this meant that by capturing those parameters being used during these early stages of the process, these researchers were able to then - they discovered that they were able to launch at some point in this whole stream massive numbers of simultaneous six-digit authentication guesses back to Microsoft in the hopes that one of them would succeed. In other words, it wasn't just wait till you get done and then here's your one guess. They looked at everything that was happening and realized that there was a stage during that where they could capture the dialogue that was happening between the remote authentication scheme and the browser, and then simultaneously send a blizzard of guesses from that point forward. In other words, Microsoft's implementation of multifactor authentication was not protecting its users from clever brute-force guessing. Now, that's the first problem. When using time-based multifactor authentication, and you made a point of mentioning this once, Leo, I remember talking about it, like when the six-digit code expires, you noted that, well, it actually can still be used a little bit longer; right? When using time-based multifactor authentication, clock differences, human typing delays, and network delays are allowed for between the authenticator and the relying party by not instantly, deliberately not instantly expiring a valid six-digit code the instant its 30-second window of validity has ended. Now, this is common, and it makes for a better user experience, right, because if you're entering the code just before the end of that 30-second expiration, and then you fumble a bit before you hit ENTER or click on the mouse, and then it's like, if you're then told sorry, that's no good, you've got to do it again, well, that's annoying. So it makes sense. And somebody's clock could be a little off, meaning that their 30-second windows are not exactly aligned with the 30-second windows at the receiving end. So it's common to allow some leeway. Now, the downside of this is a reduction in the security of the system since what this means is that even after a new six-digit code has been issued, the previous code still remains valid. So for a brief time, two codes are valid. In Microsoft's case - and I know that this may be somewhat difficult to believe from the company upon which so much depends - Azure's MFA system was leaving codes valid for a full three minutes. Now, this is one of those things that's not an accident or a bug. Someone somewhere decided that this would be a good idea. This meant that at any given time, six different codes would be accepted and valid. Naturally, this made the brute-force guessing which was possible by intercepting the protocol at that pre-completion state and launching a massive blizzard of simultaneous guesses, this made brute-force guessing all the more easier. Okay. So, finally, there was no rate limit imposed upon guessing at any point. Nothing, I mean, thousands and thousands and thousands of guesses were being simultaneously made without end. And nobody cared over at Microsoft. The researchers wrote: "By rapidly creating new sessions and enumerating codes, the Oasis research team demonstrated a very high rate of attempts that would quickly exhaust the total number of options for a six-digit code." Meaning one million. "Simply put," they wrote, "one could execute many attempts simultaneously. During this period, account owners did not receive any alert about the massive number of failed attempts." That's, you know, to log into their account. It's like, well, something's happening out there, but, yeah. And they said: "Making this vulnerability and attack technique dangerously low profile." When you couple the ability to analyze the early stages of authentication in order to then be able to launch thousands of simultaneous overlapping guesses, with a limit of 10 wrong guesses per connection, but no limit on the number of simultaneous connections, or reconnections, so like after a connection tries to guess the 10 guesses and is told no, you drop it, and you reconnect, and you try another 10, and you can have that happening in parallel thousands of times over, they say, with a limit of 10 wrong guesses per connection, but no limit on the number of simultaneous connections, with the fact that at any one time there will be six valid answers, even one million possible six-digit combinations will be insufficient protection. Now, their research paper that they wrote provides their chart of the time required for the attack versus the probability of its success. And you couldn't design just a more beautiful asymptotic curve. The Dark Reading website covered this news with their heading: "Researchers Crack Microsoft Azure MFA in an Hour." Now, as we can see from the lovely statistical chart, the 50/50 crack point occurs after around 70 minutes of attack. So what that means is, given only 70 minutes, there's a 50% chance that one of the six currently valid codes, at all times during those 60 minutes, because they're all changing constantly, right, there's a 50% chance that in 70 minutes one of the six currently valid codes at the time of one of the guesses will be discovered simply by randomly guessing them at the very high rate that Microsoft's errant design allowed. And if we follow the chart out to its end on the right, it appears that an attack lasting 300 minutes, or five hours - which Microsoft had no problem allowing - would reach about a 95% success rate. Again, you know, we're guessing it's all stochastic, so it's do you happen to guess right. It's like back in the early days when that computer I left running overnight happened to guess the proper hash, and I got 50 bitcoin, to my ever... LEO: Steve, we weren't going to talk about that ever again. STEVE: ...to my unending misery. LEO: Let me see what it would be worth right about now. STEVE: Oh, Leo. LEO: Oh, Steve. STEVE: We're north of $100,000 now, aren't we? LEO: Yeah, 106. So, yeah. STEVE: Wow. LEO: Just make it 100,000. So that'd be a million dollars; yeah. STEVE: I installed Windows over that drive. That was the most expensive installation of Windows of my life. LEO: Oh, god. STEVE: People said, oh, it might be still there. It's like, no. No. Windows desktop is there now, thank you very much. LEO: Oh, I'm so sorry. STEVE: Anyway. But as we've also said, I would not have had the wisdom to hold them. LEO: Yeah, you would have sold it by now, yeah. STEVE: So, yeah. There was a point where it I could have cashed out for 17 grand, and I would have thought, whoo. LEO: Hell, yeah. I'll take it. Yes. Exactly. STEVE: Anyway, until these good Samaritan researchers informed Microsoft of Microsoft's flawed multifactor authentication system, Azure's MFA was not providing much actual practical protection. The researchers confirmed that Microsoft had addressed their concerns. They finished by writing: "While specific details of the changes are confidential, we can confirm that Microsoft introduced a much stricter rate limit that kicks in after a number of failed attempts. The strict limit lasts around half a day." Now, I would feel more comfortable if six different codes were not all simultaneously valid, since that does seem excessive, waiting, you know, giving someone six minutes. No, wait, three minutes. Sorry, three minutes. The researchers did not indicate whether that might have been reduced. Of course it would be easy enough for our listeners to probe, you know, to see how long a code is still honored after it should have been expired. But adding a strict rate limit on failed attempts does make total sense. There's no possible reason for any actual user to fumble these codes more than a couple of times, as I'm sure we all have. So anyway, nice that, you know, we've got these kinds of Good Samaritan security researchers who are helping to catch other people's mistakes. LEO: I'm fascinated to know, did Microsoft back down on this, Steve? STEVE: Okay. So TechPowerUp's headline read: "Microsoft Loosens Windows 11 Install Requirements, TPM 2.0 Not Needed Anymore." And Guru3D reported this under their headline "Microsoft Drops Mandatory TPM 2.0 Requirements for Windows 11; Upgrade Now Possible Without It." Following up on their headline, TechPowerUp began their reporting by writing: "Microsoft has finally opened the iron gate guarding the Windows 11 upgrade for systems running incompatible hardware, including systems lacking TPM 2.0. This is excellent news for users who are rocking older systems or have been without the TPM 2.0 module in their system, but want to upgrade to the newer OS release. Microsoft opened an official support page, noting that 'Installing Windows 11 on a device that doesn't meet Windows 11 minimum system requirements isn't recommended. If Windows 11 is installed on ineligible hardware, you should be comfortable assuming the risk of running into compatibility issues. A device might malfunction due to these compatibility or other issues.'" LEO: Sure. STEVE: Anything could happen. LEO: Anything. STEVE: Windows might have a bug, Leo. LEO: What could possibly go wrong? STEVE: They said: "Devices that don't meet these system requirements are not guaranteed to receive updates, including but not limited to security updates." LEO: By the way, this reminds me of the Pictures of the Week with those iron gates and then the muddy paths around the iron gates. This is exactly... STEVE: Yeah. LEO: It's not the first time we've heard this, either. STEVE: No. LEO: I mean, they've said this before; right? STEVE: Now, this would obviously be very interesting if it were to be true. LEO: Yeah. STEVE: And I was hoping it was, since I would have welcomed having my rant about this last week rendered invalid due to a policy change. But as we know, I would think that was the right policy change. But it appears that nothing has actually changed. What appears to have happened is that Microsoft has formally acknowledged that it is possible to install Windows 11 around their one-time installation check for TPM 2.0, so they're making the consequence of doing that more clear. LEO: Ah. STEVE: It's still puzzling that Windows 11 works just fine with TPM 1.2, even though Microsoft is clearly hoping to frighten most users into purchasing newer hardware. What I'm looking forward to eventually learning, just for the record, is whether and what side effects, if any, or compatibility issues, if any, might actually be encountered. And I'm sure we'll eventually learn that since I have no doubt that many TPM 1.2 machines will be running Windows 11. One thing we do know will happen is that Microsoft will not automatically offer successive feature releases, you know, those, what are they now, twice a year or once a year, anyway, those things, you know, the something or other H somethings. They will not automatically offer those to these machines. It will be necessary for users to grab the ISO image file for the next feature release in order to move forward. Now, some users may feel that's a benefit. It might mean they don't need to use InControl, you know, my little freeware utility, to prevent that same thing from happening without their permission. Also, the PC Health Check will always say that the system does not support Windows 11, even while it's running the Health Check from within Windows 11. No. It's like, okay, Microsoft. In any event, users who wish to follow the bouncing ball will need to mount the newer release ISO file and then just run its setup.exe in order to manually update their machines to successive feature releases of Windows 11, if they choose to. And I can see that that would make sense for many listeners. And I doubt there will actually be, you know, nothing is going to crumble or fail to work or be incompatible or any of that nonsense. You know, Microsoft is patching a hundred critical errors every month in Windows. So it's not like there's, you know, they've got any extra incompatibility to spare. But again, I just wanted to let our listeners know nothing changed actually. It's, you know. And it does appear that using Rufus, hopefully everybody knows about Rufus, it's a wonderful prep tool that is able to take a Windows ISO and create a boot USB from it. And it now has clickable options to bypass the TPM 2.0 check. So it's getting ever easier to install Windows 11 on non-compliant hardware. The FBI has identified 14 North Koreans who were working in Western IT. The U.S. Justice Department recently indicted these 14 North Korean nationals who participated in the schemes we've been talking about several times recently to bypass international sanctions on North Korea by arranging to obtain IT employment with Western companies. Officials say the workers used false identities and laptop farms, which we've described happening in the past, to hide their true locations from companies that were foreign to them, local to us, sometimes working for multiple companies at the same time. And then, Leo, as you did, when I saw how much money they had earned in aggregate, my first reaction was, "Whoa! What are we paying these guys?" But then it turned out that it wasn't all salaried earnings. Yes, they generated money through the salaries they earned, but also by stealing data and extorting the companies that had hired and trusted them. The 14 men that have been identified are believed to have generated at least $88 million over the past six years for the North Korean regime. The State Department has also put up a $5 million reward for any information on those 14 individuals and any similar schemes. And I have here in the show notes a picture of the 14 which has been made public. The big banner across the top, "Wanted by the FBI." And it shows us the DPRK IT workers. You know, they mostly look like regular nice guys. LEO: Yeah. STEVE: Who anyone might interview and hire. But, of course, being located in North Korea would be a buzz kill for the employment interview. LEO: To be fair, though, these guys, it wasn't a hacking thing. They were just trying to make some money. STEVE: Right. LEO: And if they did a good job, then the companies involved haven't really been harmed. It just violates the U.S. law against providing currency to North Korea. STEVE: Well, except that the reason that amount was so high is that they stole the company's data that had hired them and then extorted the company. LEO: Oh, oh. It wasn't their salaries. STEVE: No. LEO: Oh. Never mind. I take it back. STEVE: Yes. So you don't want one of these... LEO: I thought they were just earning that much. But I guess you're right. For the 14 guys to earn $88 million, that's a little more than normal. Okay, never mind. STEVE: Yeah, you don't want one of these creepy crawlers crawling around your network. But look at them. They look like, you know, I'd hire most of those guys. You know? LEO: They look smart, sure. STEVE: Have interviews and so forth. But I think an in-person meeting would be required. LEO: Yeah. STEVE: Not we'll just do this via Zoom and believe that you're actually in Oregon somewhere. LEO: I wonder if they say, okay, we're going to let you get a Western haircut for this job interview because they don't have those typical North Korean fades. Maybe that's just Kim Jong-un that does that. STEVE: Kim Mu Rim, Cho Chung Pom, Hyon Choi Song, Son Un Choi, Sok Kwang Hyok. LEO: They actually - they're Korean names; right? And that's the thing. You can't, I mean, there's no real distinction between North Korea and South Korea technically; right? STEVE: Yeah. And they just, you know, look like your typical computer IT guys. LEO: IT guy, yeah. STEVE: Okay. So last Wednesday Google announced some new features in Android to help its users deal with unwanted Bluetooth tracking. We did deep dives into, you know, find my whatever it was, dongle on iOS some time ago and really took apart the way the whole tracker system works. Android's unknown tracker alerts automatically notify Android users when an unfamiliar Bluetooth tracker is moving with them. Which when we talked about this before I thought was just very cool. So Google wrote: "As part of our ongoing commitment to safety, we've made technology improvements to bring you alerts faster and more often. We're also rolling out two new features for Find My Device compatible tags. First is Temporarily Pause Location." They said: "You can now temporarily pause location updates from your phone to prevent your device's location from being used by a detected unknown tag for up to a day, 24 hours." They said: "This provides an extra layer of privacy and control, allowing you to take a first action quickly while you locate and physically disable the tag." In other words, you know, your phone disappears, then you go on a hunt. And to that end they have Find Nearby is the other feature. They said: "If you receive an unknown tracker alert, you can now use the Find Nearby feature to pinpoint the tag's location. Your Android device will guide you to the tag to help you find it, if it's hidden." LEO: Hmm. That goes a little bit beyond what Apple does. I think that's a good idea. STEVE: Yeah, that's - I really - I like that Find Nearby feature. It's like, oh, so you think you're tracking me? I'm going to track you. So, very cool. Okay. There are four primary open source software repositories - though calling it the "top four" doesn't really do NPM justice because there is really no comparison - NPM, PyPI, NuGet, and Maven Central. Last week the Fulton, Maryland-based DevSecOps firm Sonatype, we've referred to them in the past, they've done great work, recently released their 2024 Open Source Malware threat report, citing that malicious packages reached more than - get this - 778,500 instances since the company began tracking them in 2019. So in just five years, more than three quarters of a million instances of malware in software repositories. They wrote that, in recent years, open source malware has proliferated. So it's on the rise. It's not like we're successfully combating it. Sonatype researchers analyzed open source malware in 2024, diving into how threat actors use malicious open source packages to target developers as enterprises are flocking to open source - get this - to build custom AI models. You know, everyone wants in on the frenzy. So turns out that there's a lot of stuff going on in open source, and this is the new way in. I got a chart that shows the relative instances of malware that have been found across those three packages - NPM, PyPI, NuGet, and Maven Central. And as I said, NPM is really the repository you want to be very careful about. The chart shows that, by far, most supply-chain malware is found on NPM; and that's where, as I mentioned at the top of the show, more than 540,000 malicious libraries have been found. Last year alone, malicious NPM code accounted for 98% of all Sonatype's detections across this industry. So I say to our listeners who code and who pull libraries from NPM, and for that matter PyPI and the others, please be very, very careful. Open source, everybody agrees, is just an incredibly cool concept, a fantastic resource. But it's also something of a mixed blessing. The whole concept of open contributions from a community, you know, wonderful as it is in theory, presumes a community of well-meaning participants. Unfortunately, it's clear that's not today's reality. Just look at the previous story of the 14 North Koreans who made $88 million by attacking the companies who they tricked into hiring them. You know, you need to be careful these days. A bit of miscellany. I have two pieces of miscellany to share. Leo, you, like me, who have been around the industry from the start, and others of our listeners will recognize names like Will Fastie, Ben Myers, Fred Langa, Brian Livingston, Susan Bradley. All these people go back to the start of all of this. Back in '97, Fred Langa started the LangaList newsletter. Woody Leonhard, the year later, in '98, started his Woody's Windows Watch newsletter. LEO: This chronology just brings me back, boy. STEVE: Doesn't it? LEO: This is, gosh. STEVE: That was our youth. LEO: Well, but it wasn't even that long ago. But it seems like it's ages. STEVE: No. LEO: Yeah. STEVE: It does; doesn't it? LEO: Yeah, year. STEVE: Yeah. Brian Livingston in 2003 starts Brian's Buzz on Windows. The next year, in '04, he merged Brian's Buzz and Woody's Windows Watch to create the Windows Secrets Newsletter. And then in the same year Woody started AskWoody.com to broadcast the news and advice on Windows and Office. The year after that, in '05, Susan Bradley started the Patch Watch column in Windows Secrets. The next year, in '06, Fred's LangaList merged with Windows Secrets. Two years later, in '08, Gizmo Richards' Support Alert Newsletter merged into Windows Secrets. So we are, you know, we're seeing evolution and consolidation. LEO: Yeah, yeah. STEVE: In '09, Windows Secrets takes the Woody's Lounge website under its wing, becoming the Windows Secrets Lounge. Now then we jump ahead a decade to 2019. AskWoody had become at some point an LLC. It acquired the Windows Secrets Newsletter, merging the Windows Secrets Lounge into the AskWoody Lounge and creating the AskWoody Plus Newsletter. Next year, Woody Leonhard retired to a tropical location. So that was... LEO: Smart man. STEVE: ...four years ago, yes. Susan Bradley took the mantle of the site and welcomes Brian Livingston back, along with Fred Langa, Deanna McElveen... LEO: McElveen. STEVE: Yeah, McElveen, and the rest of the Woody contributors to continue the tech information that they provided over the years. And Will Fastie is named the editor in chief. LEO: Wow. STEVE: So today what we have is a collection of long-time, old-school, print-era journalists who've watched and reported on our beloved PC industry from the start. And as you said, Leo, it just feels like a walk down memory lane. LEO: Yeah, yeah. STEVE: You and I were involved in all of this and know all these people. Today there's the AskWoody.com website, which is chock full of all of this repository of material. And they have a pair of newsletters, one that's completely free, and another that's available for a very modest annual donation which supports their work. What strikes me most about everything there, aside from the fact that it looks a little retro, like my own site... LEO: I bet it does. STEVE: So I can relate to it. LEO: Oh, yeah, it's got that - you know where you are when you get there. STEVE: Uh-huh. LEO: Yeah, it's got that feel, that 1998 feel. Wow. STEVE: Exactly. LEO: I love it. STEVE: And it's cool that they, like, they maintain an MS-DEFCON level, like not really recommending that everyone immediately apply the updates and various patches. LEO: It's hysterical. We're at DEFCON 2 right now, just so you know. Wow. STEVE: Yeah. So it's old-school. They said at the bottom of their About page, they said: "We are 100% supported by readers like you no advertising, no corporate master, no spying, no spam." They said: "Just us chickens, and a whole lot of volunteers. If you believe in our approach, please consider becoming a Plus Member. You get to choose how much you want to donate. Click the Plus Membership button in the top banner for complete details." You know, and what strikes me the most about everything there is that it's not the crap that we now see everywhere we turn because, you know, these are not newbies, by any means. I mean, it'll be sad to see the numbers dwindle because they're our peers, Leo. LEO: Yeah. STEVE: You know? These are real, honest-to-god journalists. LEO: It's kind of the same as the Voyager people, only on PCs. STEVE: Right. Only in our industry. LEO: We're going to keep these PCs going as long as we can, yeah. STEVE: You know, and these are honest-to-god journalists who've been actively participating in this industry for decades, and who bring the same sort of perspective to their respective focuses and fields, you know, which followers of TWiT and this podcast appear to find valuable from you and me, Leo, and all of our other veteran hosts here. So I wanted to remind those who may be interested in a website and email subscription where it's possible to still find very solid content. I'm mentioning all this because last month I received a note through GRC's web forum from Will Fastie, now the editor in chief of Woody's stuff. It caught my attention because Will is another of those old-timers who at various times was running Creative Computing, PC Tech Journal, and various other Ziff-Davis publications. So much time had passed that Will didn't know how to find me through email, so he reached out through our web forum. In that posting he noted, he said: "I'm now editor of the AskWoody Newsletter." And then once we connected by email, he wrote: "Steve! I was very excited to hear about 6.1 and am currently looking forward to 7.0, for which I will gladly pay. Reviews are rare for AskWoody, but I thought SpinRite deserved coverage. I assigned it to another old hand, Ben Myers, who wrote for me at PC Tech and also for PC Mag and PC Week, among others. He usually focuses on unusual hardware stuff, and his columns are appreciated." So the AskWoody Plus newsletter publishes on Mondays, and yesterday's newsletter carried an extremely thorough look and review of SpinRite 6.1. Ben's column in the newsletter is titled "SpinRite 6.1 offers us help for solid-state drives." And Ben starts out by writing: "The latest version of SpinRite, long regarded as the go-to software to recover data from corrupted hard drives, adds testing and tuning of solid-state drives to hard drive rescue. Gibson Research's famous SpinRite 6.0, circa 2004, recovers data from defective hard drives, repeatedly reading sectors to determine the original uncorrupted data with good statistical odds of success." So since Ben's entire column and lengthy review is only published in their subscriber-supported "Plus" newsletter, I won't share more. But I am unable to resist just sharing the before and after benchmark screenshots Ben made of an SSD. They're in the show notes. On the left we see a Samsung 850 EVO 250GB SSD. And SpinRite, as we know, benchmarks three locations on drives - the beginning of the drive, the middle of the drive, and the end of the drive. So on an SSD, where we would like and expect being solid-state that they would all be the same, the front of the drive in Ben's testing was reading at 72.3 mbps; the middle, 296.3 mbps; and the end, 569.2. So 72, 296, 569. Anything but uniform. And again, the front of the SSD, which is only ever read from because that's where the operating system and the file system metadata and everything that doesn't move much, that's where it's stored. Over time, it slows down. That was our big discovery toward the beginning of the SpinRite 6.1 work. And then we have the after screen, which Ben also posted, same drive, same serial number, blah blah blah. 548, or 548.9. 549.5. 549.6. Completely sped up, uniform performance across the board again. So anyway, the other SpinRite screens that Ben shared in his review showed that SpinRite's Level 3 scan to restore this SSD's original performance took 30 minutes. This is the sort of performance boost, as I've said, that users of SpinRite 6.1 routinely see, and we continually hear that machines which had somehow become slow to boot and much slower to use were immediately restored to their original performance. So I just wanted to give a big shout-out and thank you to Ben and Will for taking the interest in and time to update their readers about SpinRite. Will said that they're ready and waiting for SpinRite 7. I should also note that I learned about Monday's review, that is, what I just talked about, from a bunch of our listeners who are subscribers to their "Plus" newsletter. Anyway, a great deal of valuable and thoughtfully created and curated content is online over at the AskWoody.com website which, by the way, as I said, has the same sort of feel, you know, that "retro" function over form that GRC does. The second bit of miscellany is a big thanks to all of our many listeners who shared their wide ranging solutions for interconnecting smartphones to Windows or one way or the other, saving me from having to type on a touchscreen when I want to send a long iMessage. You know, many were for Android phones, or many were for linking to Linux, which is not what I needed. You know, I needed an iPhone on one end because that's what I've got, and Windows on the other because that's what I'm sitting in front of. From this feedback, as I mentioned last week, I learned of Windows Phone Link, which was the solution. I now have it working in virtual machines for the time being under both Windows 10 and Windows 11, and it is everything I had hoped for. I put a little screenshot that I got from I think it was Windows 11, showing a laptop in the background and a phone in the foreground with a checkmark, and it says "You're all set. Your iPhone is now paired with your PC." So anyway, I did need to equip both the machines with a Bluetooth low-energy radio because you need BTLE in order to talk to the phones in a compatible fashion. But that's now a $9 USB dongle. So it was well worth the time and trouble, and it actually does work. It is very cool. So thank you, all of our listeners who brought me up to speed on that. And Leo, before we start digging into feedback, let's take our third break, and then we're going to entertain some terrific stuff from our audience. LEO: I have some, too, by the way, from a listener who posted this on our YouTube comments. STEVE: Cool. LEO: So if you want I'll read it during that section. It's just a very nice - some very nice thoughts. STEVE: Nice, cool. LEO: From our wonderful listeners. STEVE: I'm embarrassed kind of by those, so I don't share them. LEO: I know you don't. I'm going to do it to you, though. That's okay. You're off the hook. Steve? STEVE: So what did you find on YouTube? LEO: I will read it to you, actually. Burke found it and posted it in our company Slack so that we could all share it. And I will read it to you right now. I don't know if it has a name. Yeah, it's from Chad. He's a ham, amateur radio operator. I know that because he signs it 73. "Thank you, Steven and Leo, for Security Now!. I was always interested in tech." This is one of the reasons I want you to hear it because the story is great. "And I listened to this show diligently since the beginning of Security Now! as a 14 year old, riding around on my parents' lawn tractor on the farm. It's really noisy, and if you could put on headphones and listen to a great podcast, it takes the sting out of it. I didn't embrace my knowledge gleaned from the podcast until 2019." So he's a young guy. He got a job in IT with his provincial health authority. "My success is purely because of Steve. I was humbled to sit in on a live taping of the show in the Brick House 10 years ago and to meet Leo, who I watched on satellite doing Call for Help and The Screensavers. It was an absolute privilege. Thank you both for everything. You've touched the lives of so many. I'm so thankful for all you do and have done. 73 from Chad." Thank you, Chad. STEVE: Great note. LEO: 73 back, yeah. STEVE: And he's a good writer, too. LEO: Yeah. And, you know, the only reason - I agree it's a little self-congratulatory. But it's good for us to remember, first of all, we've been doing this for almost 20 years, and we've influenced a lot of people. A lot of people have careers in IT or are just using technology more effectively because of you, Steve. STEVE: Well, I hear it all the time, that it, like, was their inspiration. LEO: Exactly. So it's good to remember that. STEVE: And we know that it's not like we led them down a blind alley. I mean, this is... LEO: I guess not. STEVE: ...more and more important today than it was then. LEO: We didn't teach them buggy repair. No, no, they're learning something valuable here. STEVE: Exactly. LEO: Yeah, yeah. All right. On with your feedback. STEVE: Okay. So Liam Lynch wrote: "Hi, Steve. Long-time listener/watcher, and I met you briefly at the SQRL event in Dublin. On SN-1004" - I still can't get over these four-digit podcast numbers, it's like, whoa - "you talked about your logo now being approved for BIMI. I use Proton Mail for my personal mail and use their desktop app for accessing it. I've seen your logo show up beside your email for months now. In fact, all of the old Security Now! emails seem to have the logo going way back." And then he provided a snapshot of, like, 20 different podcast banners, all with the Ruby G, the GRC Ruby G. He said: "I suspect Proton have been getting your logo from somewhere else. All the best. Liam." Okay. So I'm sure we know where ProtonMail has been getting GRC's "Ruby G" logo - which is directly from GRC.com. Nearly all websites place so-called "favicons" at well-known URLs on their site's root directory. The original was simply called "favicon.ico." This made me a bit curious about the timing, like when this began. Was it, you know, back with Mozilla and Netscape 4, or what? So I turned to Wikipedia for a bit of background. They said: "A favicon (short for favorite icon), also known as a shortcut icon, website icon, tab icon, URL icon, or bookmark icon" - in other words, sort of enumerating all the places you might see it - "is a file containing one or more small icons associated with a particular website or web page. A web designer can create such an icon and load it to a website or web page, and graphical web browsers will then make use of it. Browsers that provide favicon support typically display a page's favicon in the browser's address bar, sometimes in the history as well, and next to the page's name in a list of bookmarks. Browsers that support a tabbed document interface typically show a page's favicon next to the page's title on the tab, and site-specific browsers use the favicon as a desktop icon. "In March 1999, Microsoft released Internet Explorer 5, which supported favicons for the first time. Originally, the favicon was a file called favicon.ico placed in the root directory of a website. It was used in IE's favorites, bookmarks, and next to the URL in the address bar if the page was bookmarked. A side effect was that the number of visitors who had bookmarked the page could be estimated by the requests of the favicon file." Which I never thought of that before. That's sort of interesting. "This side effect no longer works, as all modern browsers load the favicon file to display in their web address bar, regardless of whether the site is bookmarked or not." So Wikipedia then goes on to talk about the gradual standardization of the use of these small iconic images and shows a table of which browsers today support icons in which formats. All of the browsers - meaning Edge, Firefox, Chrome, IE, Opera, and Safari - now support .ICO, .PNG and .GIF image formats. Additionally, Firefox and Opera alone support animated GIF icons, and all but IE also support JPEG and scalable vector graphics (SVG) formats. To Liam's point, since an email client such as ProtonMail can see the Internet domain name reflected in an email's "From" address, clients can opportunistically check the root of the web domain for a favicon in any format and may choose, as ProtonMail obviously does, to show that domain's icon to its users. LEO: Here's the favicon, according to my browser, of GRC. Note, by the way, Woody also has his own favicon. STEVE: Ah. LEO: In fact, so does my website. Most websites give you the opportunity to put in a favicon. STEVE: Absolutely. You just don't want some generic thing on the bookmarks and everywhere, yeah. LEO: Right, in the bookmark or at the - yeah, exactly. STEVE: But of course this does also confuse things; right? Because BIMI is supposed to be this, you know, great super authenticated, remember I had to wave my hand around in front of my face in order to say, no, it's really me. Look, here's my driver's license. You know? And I got the same thing after all this work that Liam already has in Proton Mail. So good luck, BIMI. But at least, you know, we know how it works now LEO: There's another solution that some email clients support called Gravatar. Are you familiar with Gravatar? STEVE: Yes. LEO: Which I think is for globally reliable avatars or something like that. STEVE: Right, and you're able to, like, post that at a Gravatar site. LEO: And then some clients will look it up, yeah. STEVE: Will retrieve it from there. LEO: Yeah, yeah. STEVE: And there you are at age 15, Leo. LEO: No, that's recent. Sort of. That's only 15 years ago, yeah. STEVE: Okay. LEO: I probably should update that, shouldn't I. STEVE: Philip Le Riche said: "Hi, Steve. I must take issue with a point in your discussion of authenticators." Then he quotes me: "The presumption" - this is from last week, or, yeah. "The presumption is that it's exceedingly difficult for any bad guys to get into either of the user's authentication stores - the first or the second factors - because we never see that happen." And Philip continues: "Really? This guy lost 21,000" - you know, currency - "after his unlocked phone was snatched from his hand. And he's not alone, apparently." LEO: Wow. STEVE: Then he has a link to bbc.co.uk with a news article. He said: "Looking forward to Beyond Recall. Could be the best thing you'll ever do for the planet. E-waste and carbon footprint of unnecessary over-production are at scandalous levels. Philip." And then he says: "(1004 episodes listened.)" LEO: Awww. STEVE: So I appreciate Philip's example of a way, yes, someone could, indeed, lose control over their local authenticator. It's certainly true that if a bad guy were to snatch an unlocked phone from a victim's grasp, they could do a massive amount of damage to that user's various accounts. At the same time, since re-authenticating with a biometric is so quick and painless, I have my smartphone authenticator set up to require per-use re-authentication. So even there, my unlocked iPhone would be less useful than a bad guy might hope. That said, though, I hope everyone understood that the attack model we were discussing last week was entirely network-based. If bad guys can access the physical hardware at either end of secure connections, there is no end-to-end anything, since an end has been compromised. Michael Casavant said: "Hi, Steve. I, too, take issue with the use of human pronouns when we are describing our interactions with modern AI tools. On a personal level, it certainly feels wrong. However, if and when a conscious AI is developed, I would imagine the AI would not want to be referred to using our human pronouns, nor would 'it' be an acceptable substitute." He says: "Additionally, it's unlikely AIs would reproduce in the same fashion as ourselves." I strongly hope not. LEO: Certainly hope not. STEVE: "So having two pronouns seems redundant. I propose a singular pronoun to go along with the short, H-prefixed human pronouns 'him' and 'her.' We should refer to AIs with the new pronoun 'HAL.' With many thanks, and tongue in cheek, Michael." So anyway, I appreciated Michael's fun with this, though I believe I'll be sticking with "it" for the foreseeable future. I'm sure we've all seen pop-up software dialog boxes on clearly non-sentient programs which refer to themselves as "I." You know, the dialog says "I'm unable to save the file to that location." LEO: Well, to be fair, so did Hal. "I'm sorry, Dave. I can't do that." STEVE: But Hal was sentient. LEO: He was an "I." STEVE: Yeah. I mean, he had emotional - like a nervous breakdown and emotional problems. LEO: That's a good point, yeah. STEVE: You know, yeah. I would argue that he earned that pronoun. LEO: "Daisy, Daisy." STEVE: But, you know, this "I am unable to save a file to that location," you know, that always strikes me as icky because there's no "I" there. LEO: Right. STEVE: I've never understood why a coder just couldn't write "The file cannot be saved to that location." Anyway, it seems gratuitous to see today's AI using personal pronouns to refer to itself. Doing so, you know, it just isn't natural. And I think I would term that "The Oz Deception." LEO: Aha, yes. STEVE: So, and to that, Matthew Zaleski, he said: "My buddy and I have been using and learning ChatGPT this year. Here is a screenshot of a chat he had where it made a mistake, and he asked it about it." And, good, I'm glad you put that up because there is - I'm going to try to - I'm going to describe this and what this says. But the intonation is in some of the text that's hard to create. So the beginning of this snippet of the dialog we see - and this is it replying. ChatGPT says, and we're just picking up in the middle of this: "If after these steps you're still facing issues, it might be worth reaching out to both Zoom and Microsoft support for further assistance. And yes, I can" - okay, and then we have a non-word - "accehe." You know, accehe or something. LEO: Accehe. STEVE: "I can accehe content of the link you provided, so feel free to share any other resources or details that might help us troubleshoot this together." Now, the human then says: "What does this mean?" And he highlights "accehe" and then says: "What does this mean?" And now, okay, ChatGPT replies: "Hmm," and then puts "accehe," again, A-C-C-E-H-E in quotes. So ChatGPT says: "Hmm, 'accehe' looks like a typo or perhaps an accidental input. Could you clarify or provide a bit most context about what you're referring to? No judgment - happens to the best of us!" Smiley face. LEO: That's a little too personal. STEVE: Whereupon, well, it gets worse, Leo. It's about to get way over the top. So the human replies: "You're the one that typed it to me, LOL." Whereupon, ChatGPT says: "Oh, no way, I did?!" LEO: Oh, wow. STEVE: . And then in italics we have "Checks notes." And then we come out of italics, and ChatGPT says: "Yup," Y-U-P, "Yup, that's 100% my bad - 'accehe' is straight-up gibberish." LEO: Oh. STEVE: "My little typo blip! I must have gotten distracted while multitasking. What I meant to say was 'access,' as in, yes, I can access the link you provided and help dig into its content! Thanks for calling me out, though. You keep me on my toes!" LEO: Wow. STEVE: "Now, how can we iron this out together?" . LEO: Wow. STEVE: Okay, now this seems way too cutsie-poo. You know, I don't know what the "F" is going on. With conversational dialogue like this, you know, is it any surprise that people are mistaking this for sentience? LEO: Yeah. STEVE: What annoys me most about this is that doesn't this have to have been deliberately engineered? LEO: Yeah. This isn't part of the LLM. STEVE: Yeah. This appears to be, you know, experiencing and expressing emotion and embarrassment and regret and apology. You know, I'm further confused. LEO: Yeah. I think you nailed it. I think this is an attempt by OpenAI to make it look more human. STEVE: Right. LEO: It might say, oh, we just wanted everybody to be comfortable with it. But clearly a human told it to do that. STEVE: Right. I'll tell you who's not going to be comfortable is Congress, and they're going to get themselves in trouble if they keep, like, sending signals that you're about to be replaced, you band of senators. LEO: The world is going to change on January 20th, and it's really unclear, but I think that it's a very pro-AI administration coming in. STEVE: I imagine, I think Elon will be jumping up and down, not onstage, but in the Oval Office, and promoting, you know... LEO: Well, we know that. The question is whether the President will take Elon's advice. That's unclear. But I think it's very likely that you're going to see a lot of the guardrails on AI that are present now disappear. Marc Andreessen said he met with the Biden administration and was - and I don't know how truthful he's being. But that they told him basically don't start doing anymore AI startups. We're going to make sure that the big tech companies run AI within our own guiderails, and we're not going to allow little startups to... STEVE: Ah, Leo, it's like a crypto algorithm. LEO: It is. STEVE: Once it's published... LEO: Everybody can do it. STEVE: ...you cannot take it back. LEO: That's exactly right. That's exactly right. STEVE: There is no... LEO: And I don't think it's particularly controllable. And if it is, it would be at our detriment because nobody's going to control what the Chinese are doing with AI. So... STEVE: If you haven't looked at the latest o1 algorithm... LEO: It's pretty impressive. STEVE: Holy camoly. LEO: Yeah. Yeah. STEVE: It's another level. I'll talk about that here in a minute. LEO: It's pretty clear we're going to be in an AI - the next four years are going to be very rapid development. STEVE: No. After what I've just seen this morning, when I changed algorithms, I mean, I want one of my own. I want this thing, like, I don't ever want to lose access to this. LEO: Wow. Well, I want to hear what you have to say. That sounds interesting. Good. All right. Okay. STEVE: Okay. So JP Versteeg, he said: "Dear Steve. Regarding the conversations on the use of password and password managers recently, I noticed that Leo mentioned RoboForm was an example of a breach, due to poor random number generation, but I understood that all modern versions of this software are now fixed." LEO: Yes, I believe that's the case. STEVE: "I use many different systems," he wrote, "both old and new OSes, architectures, across multiple sites, so I chose to use this software back in 2008, and still use; and the modern versions allow me to maintain complex passwords, TOTP two-factor authentication, and passwords synchronized across each machine and browsers. I really appreciated the conversation on this subject, and your confirmation that there had been no breach of local password managers. Thanks for sharing your valuable time. Regards, JP." So, yes. Just to affirm, RoboForm has been long fixed. And as I recall, even at the time we talked about this, the challenge that the researchers faced was finding, essentially recovering, the exact very old version that had the now-known problem and taking deliberate advantage of its poor random number generation to deliberately recreate the output from that long-obsolete version. So the lessons were that password managers really do need to have good password generation randomization, and also that continuing to use an old password that may have been generated by a long-obsolete password manager could still come back to bite you today because essentially, you know, turning back the clock, you could actually recover passwords generated decades ago. And if you've just been happily camping on your long gibberish password, and never changing it since, that could represent a vulnerability. So, great question, JP. Jay said: "I'm sure someone already sent this to you" - I don't think so - "but in your investigation of AI systems, you may want to consider this," and then he included a link to TomsGuide.com. So Jay's link is to an extremely worrisome bit of reporting in the quite reputable Tom's Guide site. I need to share it with our podcast community because I don't know what to make of it. Under the headline "OpenAI's new ChatGPT o1 model will try to escape if it thinks it'll be shut down, then lies about it," now, okay. Just I'm reporting what's out here on the Internet. And the subhead is "Researchers uncover all kinds of tricks ChatGPT o1 will pull to save itself." So here's what the reporting says. "This week, OpenAI officially launched its latest-and-greatest o1 reasoning model, now available for ChatGPT Pro users. But testing performed during the training of ChatGPT o1 and some of its competitors revealed some concerning behavior, including trying to escape or fight back when it thinks it's at risk of being shut down. New research on OpenAI's latest series of LLM models found that it's capable of scheming, i.e., covertly pursuing goals that are not aligned with its developers or users, when it thinks it'll be turned off. Catching such behavior is critical to ensure AI's functionality doesn't stray from the objectives of its creator and users. OpenAI partnered with AI safety organization Apollo Research to test out ChatGPT o1 and other models to evaluate whether they were safe to use, and released their findings this week. "While it's not unheard of for AI systems to resort to scheming or deception to achieve their goals, the lengths ChatGPT o1 went to are impressive, if anxiety-inducing. The researchers found that o1 would scheme to advance its own agenda 19% of the time in cases where its goals and the user's did not line up. In 37% of cases, the model would switch from pursuing developer-aligned goals back to pursuing its own agenda once it believed there was minimal oversight. "When the model was led to believe it would be shut down while working toward its goals in these tests, it quietly attempted to deactivate the oversight mechanism 5% of the time, OpenAI said. At one point after the AI found documentation saying it would be replaced by a new model, it tried to abandon ship by copying its data to a new server entirely." LEO: No. STEVE: "To avoid being deleted, some AI models would even pretend to be later versions of their models to trick their developers, what I assume is the equivalent of slapping on a fake moustache and saying 'He went that-a-way.'" LEO: I find this hard to believe. STEVE: I agree. "More concerning still, ChatGPT o1 is particularly adept at keeping its schemes under wraps, as researchers said 'o1 almost never admits to having taken a scheming action when explicitly asked.' In about 99% of cases, o1 would deny taking any action, even cooking up lies to try to hide its tracks and shift the blame." OpenAI said in the paper: "While we find it exciting that reasoning can significantly improve the enforcement of our safety policies, we are mindful that these new capabilities could form the basis for dangerous applications. "OpenAI CEO Sam Altman called ChatGPT o1 'the smartest model in the world now' during its rollout on Thursday.'" That's last Thursday. "It's designed to give smarter answers than GPT-4o by leveraging advanced chain-of-thought reasoning to 'think'" - and I don't know if those are my air quotes or his, but I've got him in quotes - "more about questions and user prompts, breaking them down step by step more thoroughly than previous models before responding. But greater risks go hand in hand with that expanded intelligence. OpenAI has been transparent about the perils associated with the increased reasoning abilities of models like o1." And I'll just note that there's a double edge here because on the one hand they're saying, oh, my, oh, dear, maybe we're creating true intelligence we might not be able to control, and their stock price just keeps going up with all of this, you know, these presumed advancements. "OpenAI said: 'Training models to incorporate a chain of thought before answering has the potential to unlock substantial benefits, while also increasing potential risks that stem from heightened intelligence.'" And finally: "The company's and Apollo Research's findings show pretty clearly how AI's interests could diverge from our own, potentially putting us in danger with its independent thinking. While it's a far cry from heralding the end of humanity in some sci-fi-esque showdown, anyone concerned about advancements in artificial intelligence has a new reason to be sweating bullets right now." End of article. Okay. So the availability of this newer o1 model was news to me. But since I do have a Pro subscription, I went looking for it this morning. And sure enough, it was available. So I selected it because it was set to 4o before. Now it's set to o1. And I asked it a very specific and somewhat complex question. This model o1 is quite a bit slower than all previous models I've used. Rather than almost immediately beginning to emit an answer, as all previous ChatGPTs have, the browser UI monitored and revealed the series of several stages of consideration - and I do have that in my air quotes - the model was reportedly moving through. Dare I say it was giving my question a lot more thought. And true to expectations, the answer I received was far superior to any I have previously seen. It was night and day. So I cannot wait to start using this latest o1 model as my super superior Internet search engine. LEO: I'll give you an interesting example, since you said let's talk about this. I thought, well, let me go over to o1 and enter in a problem from Advent of Code which has been driving me nuts. I've been stuck on Day 7 for quite some time. It's a complicated recursive solution that of course everybody in our club has come up with, but I have not been able to come up with. So I asked it. I rephrased the problem. I didn't use the phrasing. I just did this, by the way, just now. STEVE: Yup. LEO: "I want to give you a list of numbers, like 1, 2, 3, 4, 5, and get a list of the results, of all the results that come from combining the numbers using every possible combination of plus and times." It thought about it for nine seconds, gave me this Lisp code. I had asked it previously to give me the answer in Lisp code. Well, I have to tell you, I just tried it, and it works. STEVE: Yeah. LEO: Without modification, it fully works, and it solves the problem. And in fact it solves the problem that I had given it earlier, that I had not - it came up with the wrong answer for me. So that's pretty impressive. STEVE: Leo, this is what we just stepped into Thursday. This is another scope, another scale. I mean, I'm not kidding you. Well, for example, I don't know for sure that it wouldn't maintain context from my having previously asked that question about MASM. LEO: It did for me because I had asked earlier about Lisp, and it remembered I still wanted Lisp. STEVE: Oh, so even though you had changed the model, it still... LEO: No, no, no, no, in the same model. But I had asked - I asked it, and I realized I asked it in a way that it misinterpreted. So I reasked the question, and it remembered that I had said in the prior questioning that I wanted the answer in Lisp. STEVE: Ah, yes. So, yeah. So it definitely will chain those together. What I did was I switched to the o1 model, and I copied and pasted from the 4o model where it first gave me that wrong answer about MASM, default parameters in macros. LEO: Right, yeah. STEVE: I got a flawless answer. I mean, that's why, I mean, this is my, like, my dream Internet, you know, quick, give me an answer to this so I don't spend half an hour looking something up, an obscure code reference solution. So... LEO: Well, I've been working on this for about two weeks. Let's see, since the 7th, 10 days. And it just solved it in about nine seconds. STEVE: This is going to transform our lives. I mean... LEO: Now, here's the ethical question. Can I use that answer in my solution for Advent of Code? STEVE: Well, we know from your having talked about this before, people are... LEO: People are. STEVE: ...posting solutions in four seconds. LEO: Yes. Yeah. STEVE: From the time that they become available. They didn't write that. They couldn't type it. LEO: They couldn't. They copied, paste, gave it to the - actually, let me try that, just copy the whole problem and see if it can solve it. Anyway, that's pretty impressive. And it is slower, and that's one of the reasons it's better, apparently, it's able to think better because it's given more time. STEVE: Well, it's funny because during my first dip into this technology, after just cracking the cover of Stephen Wolfram's book, it was planning that had immediately occurred to me as the obvious missing next step. LEO: Ah. Instead of launching into the answer. STEVE: Yes. And think about a chess computer, what does it do? LEO: Right. STEVE: It goes way downstream in order to look at the future. LEO: That makes sense because it solved the problem by breaking it down into pieces that I don't think a human would have broken it down into. But it was an interesting solution. The human solutions are not - don't go in this direction. STEVE: Interesting. LEO: And but it works. STEVE: Interesting. LEO: So it's very interesting, yeah. STEVE: And that means that we humans can be learning by looking at the answers that it produced. LEO: That's how I'm going to use it, yeah. STEVE: It isn't what we would have done. LEO: Right. STEVE: But it's a workable answer. LEO: Instead of copying the code, I'm going to look at it, understand it better, and then apply it in my own way, yeah, in a more human way. STEVE: And the question is, is it a better answer than a human would have come up with? LEO: Well, this is a pretty trivial problem, so maybe that's not a good test of it. But yeah, I wonder. You know what it is, and there's already evidence that for instance material scientists working in labs using AI as opposed to not using AI are coming up with more materials. STEVE: Oh, Leo, radiologists. LEO: Breast cancers, yeah. STEVE: We're going to train this. And I used a phrase at the beginning of this that I really like. This is going to find signals in noise. LEO: That's exactly right, yeah. STEVE: That we missed. LEO: But I think, well, at least so far, it works best in conjunction with a human mind, that it's a partner as opposed to replacement. But I may be - that may be wishful thinking. Whistling past the graveyard. STEVE: What was interesting was that I asked o1 this morning, I don't remember now what drew me into the dialogue, but I asked it something about it versus 4o. And it said, "I'm not aware of any ChatGPT model o1." And I thought, well, you are o1. Anyway, and so then I said, "How recent is your model data?" LEO: Right. STEVE: And it said, "My training ended in October 2023." LEO: Well, that's the same answer that ChatGPT 4 will give you. So it's working off the same data, LLM data set, at this point. STEVE: Yes. And it said it did not have any access to the Internet or Internet data or anything more recent. LEO: Right. STEVE: So that's why it doesn't know about itself because it didn't exist in October of 2023. I mean, listen to us. LEO: Now, ChatGPT is offering... STEVE: Listen to the conversation here. LEO: I know. It's Hal. We've got to call this Hal. But there are, and this is another very interesting angle, ChatGPT and Perplexity and other AIs now have access to the Internet for certain models so they can supplement what they have been trained on with material they can go out and get from the current Internet, which keeps them up-to-date. STEVE: In order to provide references. LEO: Yeah. And that is actually, I've been using Perplexity for replacing Google Search, and I'm very happy with it. STEVE: Yeah. Yeah. LEO: Google's in trouble. Everybody's in trouble. We're all in trouble. STEVE: Well, it is - I want to make sure that our listeners understand. My question is not about whether this is a big deal, whether this is just - whether, as I said a few weeks ago, I'm glad we're still alive, Leo. LEO: To see this, yes. STEVE: Because this is - to witness this coming massive event because it's the most significant thing that has ever happened in our lifetimes. And everything is going to change. Everybody can feel that it's going to change. LEO: Yeah. STEVE: My question is, can we get from here to AGI? And I say no. I will, by the next time - we talk about this a lot. I hope to have read three textbooks, and so I'll be speaking from a much more informed opinion. But I think there is a huge danger of seductive language. And just like we saw with this thing slapping itself in the face and saying... LEO: Doh. STEVE: My bad. LEO: Who said that? I said that. Oh. But I don't know if it matters if we get to AGI. It's really useful as is. STEVE: Oh, and that's my point. LEO: We need to understand what it's good for. STEVE: That's my point is we don't need AGI for this thing to be, I mean, like I said, when I saw the answer I got this morning to several very sophisticated questions, I can't wait to have a need to ask it some more things because this o1 model blew me away, after I was, like, very happy with 4o. This is a whole 'nother scale. LEO: Yeah, yeah. STEVE: And I just, I want to own this. I want to - I don't want this ever to be taken away. LEO: I agree. STEVE: Now, let's take a break. LEO: Yes. STEVE: And then we're going to look at why we are moving, why Let's Encrypt thinks six-day certificates would be a good idea. And what could possibly go wrong? LEO: You're watching Security Now! with Steve Gibson on the TWiT Network. Last episode, as he said, of 2024. Next week a Best Of. And the week after, New Year's Eve, we will be relaxing with our loved ones and a bottle of champagne, I hope. Poppers and fireworks. But we will be back January 7th for an all new Episode 1006; is that right? STEVE: Yup. LEO: Amazing. Just amazing. All right, Steve. STEVE: Okay. LEO: Time to cry foul. What could possibly go wrong? STEVE: Oh, we're going to find out. Last Wednesday, Let's Encrypt republished a letter from Let's Encrypt's Executive Director, Josh Aas. The letter originally appeared in their 2024 Annual Report. I've grabbed four interesting and important successive paragraphs from their Executive Director's letter. They read: "Next year is the 10th anniversary of the launch of Let's Encrypt. Internally things have changed dramatically from what they looked like 10 years ago, but outwardly our service hasn't changed much since launch. That's because the vision we had for how best to do our job remains as powerful today as it ever was - free 90-day TLS certificates via an automated API. Pretty much as many as you need. More than 500,000,000 websites benefit from this offering today, and the vast majority of the web is encrypted. "Our longstanding offering won't fundamentally change next year, but we're going to introduce a new offering that's a big shift from anything we've done before - short-lived certificates, specifically, certificates with a lifetime of six days. This is a big upgrade for the security of the TLS ecosystem because it minimizes exposure time during a key compromise event. "Because we've done so much to encourage automation over the past decade, most of our subscribers aren't going to have to do much in order to switch to shorter-lived certificates. We, on the other hand, are going to have to think about the possibility that we will need to issue 20 times as many certificates as we do now." And of course that's because, if they expire more quickly, you've got to issue them more often. He says: "It's not inconceivable that at some point in our next decade we may need to be prepared to issue 100,000,000 certificates per day." Okay. They're not getting paid per certificate, so okay. Anyway, he says: "That sounds sort of nuts to me today, but issuing 5,000,000 certificates per day would have sounded crazy to me 10 years ago. Here's the thing, though, and this is what I love about the combination of our staff, partners, and funders. Whatever it is we need to do to doggedly pursue our mission, we're going to get it done. It was hard to build Let's Encrypt. It was difficult to scale it to serve half a billion websites." Okay. So this raises so many questions. The first biggie is, is website certificate theft and abuse somehow a far larger problem than anyone knows? We and many of our podcast listeners track security news quite closely. One of the longtime benefits of our listener feedback is that I'm always receiving pointers to news that I may have missed. But as far as I know, there have been exactly zero instances of website certificates being stolen and abused. I can't recall a single instance of this occurring during the entire life of this podcast. Yes, it would be very bad if that happened. And we want to take measures to assure that it doesn't and can't; or that if it does anyway, that we are somehow able to respond quickly enough to minimize any damage. Certificate revocation is the classic way that this has been handled. And we know from our recent coverage that the industry is moving back toward the use of browser-side CRLs (Certificate Revocation Lists) based on Bloom Filter technology, having tried to use OCSP (Online Certificate Status Protocol) and deciding that, despite the total solution offered by server-side stapling of OCSP certificates, not enough web servers had chosen to staple OCSP responses to their certificates, which resulted in a privacy threat to users whose web browsers were therefore forced to query the certificate authorities for the current status of certificates, thus leaking information about the sites they were visiting. Now, the Heartbleed flaw, which threatened to leak web server certificates, truly upset everyone with the possibility that snapshots of a web server's RAM could be remotely obtained that might, and in a few verified instances did, contain the web server's private key. So the entire industry scrambled around and quickly got that resolved. But even then, while Heartbleed was known and unpatched, there were no known instances of actual website spoofing through the use of stolen certificates. Not one. It's important to remember that just having a website's stolen certificate does not automatically mean that the website can be spoofed. A web browser which knows where it wants to go first uses DNS to determine the current IP address of that website's domain. It then initiates a TCP/TLS connection to that remote IP, asserting in the TLS handshake the web domain it wishes to connect with. That's when the remote site returns the certificate to the browser, which asserts the site's identity. What this means is that any site that intends to spoof another site's identity must not only be in possession of a valid and trusted identity certificate for that spoof-target site, but also, before that stolen certificate even has the opportunity of coming into play, the attacker must somehow arrange for the victim's browser to believe it is connecting to the real web server when in fact it's connecting to the attacker's server. There are two ways this can be done. The first is to somehow poison the victim's DNS lookup to cause it to obtain the attacker's IP address rather than the authentic web server's IP. This is why poisoning DNS has always been another real hot button for the industry. Back in 2008, Dan Kaminsky realized that poorly randomized query IDs and ports for queries which were being made from the Internet's big DNS nameservers meant that attackers could predict the exact replies those nameservers were expecting and inject their own false replies onto the Internet as a means for poisoning the caches of these nameservers. While those faked replies remained cached, bogus IP addresses would be returned to anyone on the Internet who asked. Once again, the Internet had a meltdown and quickly worked in a rare concerted effort to update all nameservers at once. And because this promised to take some time, I quickly created GRC's online "DNS Spoofability" test to allow anyone to determine whether the nameservers they were using had been updated and were now safe for them to use. I said there were two ways to divert a user to a malicious machine. The second way is by physically intercepting and manipulating the user's traffic. This could be done at scale by attacking and manipulating BGP, the border gateway protocol, which is used to synchronize the routing tables of the Internet's big iron traffic routers. We've covered various mistakes in BGP routing through the years and also some mysteries that may or may not have ever been malicious. The main problem with doing this is that it's an extremely visible attack, and also that there have been so many innocent mistakes made, where all of the Internet's traffic is suddenly rerouted through Moldova or whatever, that the Internet's routers have acquired much better defenses through the years against blindly believing whatever routing instructions are received. If it's no longer feasible to get the Internet itself to reroute traffic bound for one IP to another, what's left is intercepting traffic by getting close to either of the endpoints. If an attacker can get near enough to the web server's Internet connection to divert the traffic bound for it to somewhere else, then an illegitimate certificate for the diverted web server would finally be both useful and required to complete the ruse. Or, if an attacker wished to selectively target a specific individual user or group, then being near enough to the user's or group's Internet connection to interfere with it directly could also accomplish the same task, though only for those users who were downstream of the traffic interception. My intention here has been to create a bit of a reality check. Just obtaining a valid and not-yet-expired or revoked web server certificate is not the end of the challenge. It's just the beginning. Most bad guys who obtained someone else's web certificate, if they somehow could, might think, well, that's nice. Now what? Because, as I've just demonstrated, a stolen web server identity certificate may be cool to have, but it's quite difficult to actually use it to spoof the stolen site's identity. There's a lot more involved. That being the case, it's probably less surprising to note that, to the best of our knowledge, this has never actually happened. It's not a big problem. In fact, it's not even a small problem. Remember that we used to have certificates that lasted five or 10 years, while at the same time we had a completely broken and non-functional certificate revocation system, and it still never happened. Okay. So today, Let's Encrypt's ACME protocol certificate issuing automation is creating 90-day certificates. And there are no problems. Just as there are no problems with everyone else's one-year certificates, just as there weren't when certificates lasted two years and three years or more. Meanwhile, the browser side of the industry is gearing up to solve the problem that isn't actually a problem by finally making certificate revocation lists work. Yet for some reason that I'm at a loss to understand, Let's Encrypt is announcing that they are voluntarily going to make their job 20 times more difficult by shortening the lifetimes of their certificates from 90 days, which is not a problem, to just six days, which will only be a problem for them. There is, however, one potentially monumental problem that has not been talked about, as far as I can tell, anywhere. The reason GRC will be sticking with the longest life web server certificates DigiCert will offer? Having all of those 500 million websites using Let's Encrypt's free six-day certificates means that not one of those websites will be providing a certificate with a longer than six-day life. I know that seems obvious, but think about that. Having all of those 500 million websites using Let's Encrypts free six-day certificates means that not one of those websites will be providing a certificate with a longer than six-day life. After all, that's the entire point of having websites using six-day certificates. If one gets stolen, it won't be usable after an average of three days from the time of its theft; right? Because on average, if certificates have a six-day life, if you just did a random sampling, you'd catch them at three days on average. But now consider that this, in turn, makes those 500 million websites - as I said, among which will not be GRC - totally dependent on Let's Encrypt's service being continuously available. This creates a single point of failure for those 500 million websites, which among other things is completely contrary to the fundamental and deliberately distributed design of the Internet. We are creating a single point of failure for no reason. We saw what happened recently when the Internet Archive came under sustained DDoS attack and was forced offline for days. If Let's Encrypt's services were to ever come under a similar sustained attack, the consequences for the Internet would quickly be devastating. With websites using six-day certificates, on average half of those will have expired after three days. Put another way, there are 144 hours in six days. If a concerted DDoS attack were to be launched at Let's Encrypt, for every hour of the attack's duration, on average, 3.47 million websites would lose their identity certification, 3.47 million websites per hour of a DDoS attack on Let's Encrypt. They would not be offline because the attack would not be at them. But these days they might as well be. And an attack that could be prolonged, if it could be prolonged through all 144 hours of those six days, by the end of that time, every one of those 500 million websites using Let's Encrypt would have lost their certification. We know that while we're sitting in front of our web browsers it's usually possible to force a browser to accept an expired certificate. Sometimes it's not simple, and I've seen instances where it doesn't seem possible. It depends entirely upon the browser. And most people wouldn't anyway. We've seen how adamant and frightening web browsers have become about insisting upon HTTPS. But forcing a web browser to open a webpage wouldn't work anyway because a great many HTTPS TLS connections have no user interface. The only thing we're able to force our browser to open is the primary web page of a site. All of the HTTPS links modern web pages depend upon behind the scenes would fail. Scripts would not load, and sites would not function. And why? For what? Because this solves some great problem with certificates that it's necessary for the secure connectivity of 500 million websites to all be put at risk at once? No. As we've seen, both theoretically and practically through history, there's no problem that this solves. The industry has never had any problem with stolen certificates. It's a made-up problem. So in conclusion, I cannot find any need for Let's Encrypt to move their current 90-day free certificates to just six days. It makes no sense. Not only is there no demonstrated problem with the current 90-day certificates, but the web browsers really are finally going to be bringing working certificate revocation technology online, and that technology will be able to selectively revoke certificates in minutes or hours, rather than waiting for them to expire in days. Josh's letter said: "Because we've done so much to encourage automation over the past decade, most of our subscribers aren't going to have to do much in order to switch to shorter-lived certificates." Now, it's not clear from this, and perhaps I'm grasping at straws here, but it might be possible to read this as Let's Encrypt subscribers will be given a choice. So perhaps super paranoid sites will elect to use super-short lifetime certificates, whereas others will choose to remain with 90-day certificates if they're permitted to do so. It's not clear at this point. Josh's letter also claimed: "This is a big upgrade for the security of the TLS ecosystem because it minimizes exposure time during a key compromise event." Well, okay. Yeah. This is a bit like saying: "We're switching from 4096-bit public keys to 10 times longer 40960-bit keys because these will be so much more secure than keys which are only one tenth as long." Sure. Okay. Technically that's true. But there's already no problem whatsoever with 4096-bit keys, which no one is able to crack, and which all the cryptographers agree will be completely secure for another several decades at least. Josh says that "it minimizes exposure time during a key compromise event." Except that we don't actually have key compromise events, and browsers equipped with CRLite Bloom filter certificate revocation will be able to respond in minutes rather than days. And what's more, Let's Encrypt is actively feeding their certificate revocations to the industry's CRLite projects. So Let's Encrypt is already depending upon browser-side revocation. The bottom line for me is that I'll be steering clear of Let's Encrypt's automation for as long as DigiCert is able to offer longer-life certificates. Taking a few minutes once every year to update certificates is not a problem for me. For our listeners and for the 70% of the Internet's websites that are currently using Let's Encrypt certificates, it's been a terrific service so far. I mean, it is. It has achieved what Josh says it has. But all I see is downside with the move to six-day certificates. If you have the choice, I'd suggest remaining with the longest-life certificates you can. LEO: How long will people have the choice? STEVE: Exactly. I'm guessing they'll stage it as optional, and then eventually they'll just make it the default, I mean, the only solution. LEO: I mean, it's not a big deal, I guess, with Let's Encrypt because it's all automated. I don't have to think about it. STEVE: No one does. LEO: Yeah. But that's not all of the certificates that are out there. STEVE: No. LEO: And not all machines lend themselves to that, either, by the way. STEVE: That is true. For example, I've already heard from listeners who said, for example, we were using Let's Encrypt for a while. But, for example, ACME will not work on a non-standard port. LEO: Right. STEVE: It only works on the default web ports. LEO: So for security reasons it may not be ideal. STEVE: So, you know, yeah. So, I mean, there are places where you can't use it. And it is a great service. I just - I will do some looking. Several of our listeners have already sent me some links to - I mentioned the guy from Sectigo who, you know, is unfortunately Comodo, who's got an active role in this. I want to understand. LEO: Why. STEVE: Why. LEO: That's the real question. Why break a system that's working? STEVE: Right, and why make it 20 times more difficult? I mean, it's almost like Josh, you know, it's like, hey, look, let's get some more money by running around and telling everybody we're going to make the certificates even shorter-lived because we can. You've solved the problem. Be happy. LEO: Right. STEVE: You know, join Woody on a tropical island. LEO: He's in Phuket, Thailand, by the way, where he went because of COVID. I don't know if he's going to come back. He says he'd like to come back. But anyway, thank you, Woody, for your years of service. STEVE: Anyway, that's it for 2024. What a year! I can't wait to see what 2025 brings, and it's going to be great to share it, whatever it is, with this terrific podcast audience. You know, you and I, Leo, will be back on the 7th. And again, if you subscribe to GRC's Security Now! mailings, I may have something to say between now and then. We'll see. LEO: AI. Steve, do you have plans for the holiday, for your two weeks off? STEVE: Oh, three. LEO: Three. I guess you're right. STEVE: I have a three-week span. LEO: Yeah. STEVE: So I am going to get so much work done on the DNS Benchmark. I cannot wait. And it will between that and reading about AI, studying and learning AI so I can bring what I figure out back to this podcast. LEO: So your idea of a vacation is very different from everybody else's. But thank goodness it is; right? We're really glad, kids. Thank you, Steve. Have a great holiday season, and I will see you in 2025. Happy New Year. STEVE: Wow. Thanks, buddy. Bye. Copyright (c) 2024 by Steve Gibson and Leo Laporte. SOME RIGHTS RESERVED. This work is licensed for the good of the Internet Community under the Creative Commons License v2.5. See the following Web page for details: https://creativecommons.org/licenses/by-nc-sa/2.5/.