ironsoap

joined 1 year ago
[–] ironsoap@lemmy.one 3 points 1 month ago (1 children)

Indeed, I'm feeling lazy and need a non-ai translator please... ?

[–] ironsoap@lemmy.one 18 points 1 month ago

If approved, it will affect all Safari certificates, which follows a similar push by Google, that plans to reduce the max-validity period on Chrome for these digital trust files down to 90 days.

Max lifespans of certs have been gradually decreasing over the years in an ongoing effort to boost internet security. Prior to 2011, they could last up to about eight years. As of 2020, it's about 13 months.

Apple's proposal would shorten the max certificate lifespan to 200 days after September 2025, then down to 100 days a year later and 45 days after April 2027. The ballot measure also reduces domain control validation (DCV), phasing that down to 10 days after September 2027.

And while it's generally agreed that shorter lifespans improve internet security overall — longer certificate terms mean criminals have more time to exploit vulnerabilities and old website certificates — the burden of managing these expired certs will fall squarely on the shoulders of systems administrators.

Over the past couple of days, these unsung heroes who keep the internet up and running flocked to Reddit to bemoan their soon-to-be increasing workload. As one noted, while the proposal "may not pass the CABF ballot, but then Google or Apple will just make it policy anyway…"

...

However, as another sysadmin pointed out, automation isn't always the answer. "I've got network appliances that require SSL certs and can't be automated," they wrote. "Some of them work with systems that only support public CAs."

Another added: "This is somewhat nightmarish. I have about 20 appliance like services that have no support for automation. Almost everything in my environment is automated to the extent that is practical. SSL renewal is the lone achilles heel that I have to deal with once every 365 days."

Until next year, anyway.

[–] ironsoap@lemmy.one 2 points 1 month ago (1 children)

Agreed, now the fun part of coming up with a legal basis to do so and convincing regulators.

[–] ironsoap@lemmy.one 2 points 1 month ago (3 children)

I don't think this requires an act of congress. I think you might see more consumer advocation on the part of FTC (although it doesn't currently regulate online broadcast), or potentially the CFPB.

Admittedly it's more likely to see the EU do some regulations, but it all depends on the election.

[–] ironsoap@lemmy.one 1 points 1 month ago

I'd you have android, I recommended newpipe or one of it's fork like tubular. Or Seal or it's fork Ytdlnis.

There are several front ends for yt-dlp on Mac and Windows as well.

[–] ironsoap@lemmy.one 11 points 1 month ago (7 children)

While I agree, I have a hard time seeing how people will stop using it until the field changes. Maybe in 10 years it will the the MySpace of the sitcom era, but right now it's still growing. That growth is giving it carte blanche to manipulate the users as it sees fit. Regulation might impact it, but it's still a bit of a Goliath.

  • Compared to 2023, YouTube’s user base has grown by 20 million this year, representing a 0.74% increase. From Global media insights

Also the active user base is 2.7 billion people in 2024 from the same source above.

The alternatives are out there, but just not in the same league.

[–] ironsoap@lemmy.one 26 points 2 months ago (3 children)

Yt-DLP and it's variation (Seal, YTDLnis, etc.), newpipe and it's variation (Tubular, Newpipe Sponsorblock, etc) already allow you to do this without having to get manual.

[–] ironsoap@lemmy.one 18 points 3 months ago

[# Systematic Destruction (Hacking the Scammers pt. 2)

Taking on the "Smishing Triad"](https://blog.smithsecurity.biz/systematic-destruction-hacking-the-scammers-pt.-2) g

His blog on the topic if you don't want the wired summary.

[–] ironsoap@lemmy.one 31 points 3 months ago

A brief technical summary from iMAP reveals what happens when users attempt to access sites using Cloudflare and Google DNS.

• On Maxis, DNS queries to Google Public DNS (8.8.8.8) servers are being automatically redirected to Maxis ISP DNS Servers;

**

• On Time, DNS queries to both Google Public DNS (8.8.8.8) and Cloudflare Public DNS (1.1.1.1) are being automatically redirected to Time ISP DNS servers.

“Instead of the intended Google and Cloudflare servers, users are being served results from ISP DNS servers. In addition to MCMC blocked websites, other addresses returned from ISP DNS servers can also differ from those returned by Google and Cloudflare,” iMAP warns.

...

"Users that are affected, can configure their browser settings to enable DNS over HTTPS to secure their DNS lookups by using direct encrypted connection to private or public trusted DNS servers. This will also bypass transparent DNS proxy interference and provide warning of interference,” iMAP concludes.

Essentially Malaysia law required ISP to drop DNS entries for some sites, local users started using public DNS. ISP started redirecting public DNS requests, and local users started using DNS over HTTPS.

The pirate wars continue in their arms races.

[–] ironsoap@lemmy.one 61 points 4 months ago

I did a quick search and they don't make it easy. Peter Lowe's ad and tracking server blocklist is the only one I found. EasyList doesn't seem to have a donation link, nor Dan Pollock at someonewhocares.org. Also worth noting that UBO doesn't take donations. You could always subscribe to AdGuard, but that's mixed.

[–] ironsoap@lemmy.one 2 points 5 months ago

Alternative link non paywalled

https://archive.ph/vY4le

[–] ironsoap@lemmy.one 25 points 5 months ago (3 children)

If this request worked, it meant that I could use an “encryptedValue” parameter in the API that didn’t have to have a matching account ID.

I sent the request and saw the exact same HTTP response as above! This confirmed that we didn’t need any extra parameters, we could just query any hardware device arbitrarily by just knowing the MAC address (something that we could retrieve by querying a customer by name, fetching their account UUID, then fetching all of their connected devices via their UUID). We now had essentially a full kill chain.

I formed the following HTTP request to update my own device MAC addresses SSID as a proof of concept to update my own hardware:

...

Did it work? It had only given me a blank 200 OK response. I tried re-sending the HTTP request, but the request timed out. My network was offline. The update request must've reset my device.

About 5 minutes later, my network rebooted. The SSID name had been updated to “Curry”. I could write and read from anyone's device using this exploit.

This demonstrated that the API calls to update the device configuration worked. This meant that an attacker could've accessed this API to overwrite configuration settings, access the router, and execute commands on the device. At this point, we had a similar set of permissions as the ISP tech support and could've used this access to exploit any of the millions of Cox devices that were accessible through these APIs.

Blows me a away that an unauthenticated API with sensitive controls and data was publicly facing. Corporations these days want all your data but wonder why some customers are worry about how it is protected, it let alone if it's being sold. Why should I allow you to control my hardware when you can't protect yourself.

view more: next ›