B (112:34)
Gavin has a confession to make. Another listener of ours, he said, hi Steve. And he says right up, I have a confession to make. I have knowingly opened up public database access in production systems. He said. Here's how this came about. A few years ago, I became the sole software developer at a small UK isp. Following the departure of several senior team members, the company had a plethora of legacy systems scattered among various cloud service providers. Following COVID 19, sales plummeted. With many customers shutting up shop and very few businesses investing in connectivity products, we had to start cutting costs or risk going under ourselves. One of our biggest costs was managed database instances. My predecessors had spun up individual database servers, many SQL and PostGri for each of our many applications across different clouds. AWS, DigitalOcean, etc. And multiple different accounts within each. In terms of application isolation, it was a great approach, but it was costing a small fortune. My task was to consolidate as many of these databases as possible, which would bring our costs down quickly, amounting to thousands of pounds per month. There were three possible ways of accomplishing this. After first migrating all application databases to a central instance, first move all of the applications from the various cloud accounts into a single account and VPC so they could all, you know, virtual PC so they could all access the new database instances privately, or give each of Our applications static IPs and set up security rules in front of the new database instances to limit their access or open up full public access to make the pat and make the passwords as strong as possible. Now remember this. Gavin is a listener, so he knows what he's saying. He wrote, the problem with moving all of our applications is that it would take a very long time, and many of them relied on cloud provider specific utilities and network configurations for which we would need to find alternatives and rewrite large swaths of legacy code. In other words, there was a lot of lock in and actually moving them would have meant, you know, would have been a huge burden or the second question, he says the problem with the static IP solution is that they became quite expensive, meaning static IPs, and some of our platforms, Digital Ocean apps, for example, at the time didn't offer them at all. So static IPs were out, you couldn't use static IPs and firewall rules. So, he writes reluctantly, the third option was chosen and management were happy to take on the additional risk. Right, right up, up until there's a major breach, they're happy, he says. But he said management were happy to take on the additional risk, which I explained to them, especially in light of the immediate expected cost savings, he says. And so for about four years we were running with our main databases publicly exposed to the Internet. But now, today, after a lot of work, all of our apps are in private subnets and linked VPCs and thankfully our databases are no longer exposed. I know that my company was not alone in doing this sort of thing, having spoken with other devs in the industry. So here it is, a real world example of how this can happen. And not through negligence, rather through unfortunate resource pressures. Luckily, we were never compromised to our knowledge. Good for you, Gavin, for acknowledging that. And we just about managed to bounce back as a business and I'm making sure this sort of thing won't happen again. All the best, Gavin. Listening since 2018. So, first of all, Gavin, confession is always good for the soul. Second, I have no problem whatsoever with what you needed to do, because none of it was done blindly or without thought and a clear understanding and balancing the costs and the potential consequences. So I would judge that to be, while of course not maximally safe, at least entirely responsible, you were not irresponsible. And given the constraints you were operating under, the interim solution you adopted was the best you could achieve. No one should fault you for that, John David Hickin. His subject was on ISPs selling your DNS data, he wrote. Can't you just set up the ISP's modem router as an edge router? He says, turning off WI fi as well, and connect another router or more behind that, he says, an old solution of yours repurposed. Cheers, John. Okay, so I received other similar questions and he's talking about ISP spying. So I wanted to take a minute to examine the ISP's advantage. What we need to consider is that our ISPs, minus Cox cable, knows exactly who we are by household name, address and payment information. And they're in the very special and privacy sensitive position of having direct access to our individual Internet traffic. We've invested endless podcasts examining cookies and fingerprinting and tracking beacons and all manner of privacy breaching and privacy protecting solutions and technologies. And there among it all sits our ISPs through which every bit, byte, kilobyte, megabyte and gigabyte of our traffic flows. No one else on the entire planet enjoys such direct access to exactly what those in our household are doing from moment to moment now. Before the era of let's encrypt and their great encrypt the Internet TTLs revolution, our ISPs were often privy to the detailed content of everything we did. In retrospect, it was quite bracing. Today, with everything encrypted, ISPs are unable to see into our connections, but they can still see where we're connecting. And if we're not encrypting our DNS, they can also track every domain name anyone in our household and any of our home's IoT devices looks up. Tracking the remote IP we're connecting to is much less useful today than it was years ago due to the massively widespread use of multi domain hosting. Cloudflare has a large pool of IP addresses which provide services to their large pool of customer websites. Among those, there's a many to many relationship, so having an ISP only able to see a customer's traffic destination is far less useful today than it was 20 years ago. However, there's still a problem, and that's that sni, the server name indication that's carried in the TLS client hello handshake is only encrypted when both ends support and negotiate. TLS version 1.3 TLS 1.3 introduced ECH encrypted client hello for the express purpose of preventing anyone who might be examining Internet traffic like an ISP from picking up the destination domain of any new connection. At this point in time, at the start of 2026, more than half of all Internet traffic is now using TLS version 1.3, but less than half and at least a third is still not. But yet the privacy leakage that has continued to occur during the TLS handshake is slowly draining away over time and eventually we'll all get to 1.3 after destination IP and TLS handshake leakage DNS is the remaining potential privacy leak. Firefox users are now being automatically protected thanks to an agreement between Mozilla and Cloudflare to use Firefox's built in DNS over HTTPs with Cloudflare's DNS resolvers by default. So Firefox users default protection, but the Chromium browser family by default will upgrade to DOH if and only if the DNS provider the user has manually configured for unencrypted DNS also supports DoH. This is called opportunistic DoH, but since most users have not manually reconfigured their DNS and just run with whatever DNS their ISP has provided, that will be unencrypted DNS over udp. So only people using Firefox today will have their DNS lookups masked from DNS snooping. And I don't know why, but that's the way it is. One increasingly popular solution is to use or obtain a home router that can perform its own remote DOH lookups and configure it to use one of the major free CDN DNS solutions offered by, you know, Cloudflare, Google, Open DNS, NextDNS, or whatever service you choose. After that, all of the internal networks DHCP configured devices, meaning typically all of your computers and mobile devices and IoT devices which would all be using DHCP to get their LAN IPs will be using standard DNS to the router. But then all queries for domain names will be encrypted and handled by the router. ISPCs nothing. So with everything using TLS now and TLS Moving to version 1.3 with encrypted client hello to mask the target domain and your browser or router using DoH, the only remaining privacy concern is an ISP able to observe the destination of your traffic. I don't see that ever going away. As I noted, thanks to the increasing use of CDNs and cloud hosting, which aggregate many domains among IP addresses, that's far less, you know, certain than it once was that an ISP can't absolutely know where you're going. But for anyone desiring absolute privacy from ISP snooping, the final step would be to use some form of traffic tunneling. So that means Tor or a VPN using one of those means that the ISP is able to determine nothing beyond the fact that you're using Tor or a VPN that they can see, but nothing else. So, circling back around to John's question, it should be clear that as long as an ISP is the carrier of a subscriber's traffic, nothing else the user might do inside their network, like a router within a router, would change the nature of the traffic which emerges from their LAN to pass under the ISPs watchful and perhaps curious traffic logging and monitoring. I if they're doing that, don't know one way or the other on any specific issue. And finally, Troy. Wow, Shahumian. I hope I said that right. Troy, he said Steve omg. I just realized how many podcast files I have that probably need rewinding. Can you recommend a program? Can you recommend a program to do this? Okay, so Troy, first of all, I feel your pain and I can only imagine the size of the podcast rewinding backlog you might be facing. Now. I know that many of our listeners also listen to other podcasts, so your burden might be even larger. But just taking security now, since this is podcast 1062, if you've been listening from the start, or if you started late, then went back to catch up from the beginning, and if God help you, you have not previously rewound any of those before now. Well, it's not. It's not going to be pretty. I don't envy the corner that you've painted yourself into. Okay, now what you really need is some sort of and this is what you're asking for, right? Some sort of mass gang parallel podcast rewinder. And I was thinking about this. Once I finish reworking GRC's E Commerce facility and Lori and I get moved to our new place that'll be a project in the spring. Here I plan to readdress GRC's Validrive freeware and although I don't have it on my roadmap, I may see whether I might be able to sneak in some sort of mass podcast rewinding facility, sort of as a side feature. So you could copy the podcast onto a, onto a thumb drive or, you know, USB attachable storage. And then I would have validrive just rewind them all for you.