🇨🇦
I think I’ve found the problem:
It seems my issue is pihole being unable to block/modify dns requests for HTTPS records, which don’t match the LAN IPs pihole handed out in A/AAAA records.
I’ve disabled cloudflare proxying so they don’t have HTTPS records to serve, but I’ll have to replace pihole with a better lan DNS solution if I want to turn that back on.
Thanks. That seems to be a similar, but slightly different error. I think the below may apply though.
I believe I’ve tracked down more of my issue, but fixing it is going to be a hassle:
When cloudflare proxying is enabled, there are 3 DNS records involved; A record with cloudflares ipv4, AAAA record with cloudflares IPV6, and the key to this puzzle: an HTTPS record with cloudflares ech/https config.
With pihole I can set DNS records for A/AAAA, but I have no way of blocking/setting the HTTPS record so it gets through from cloudflare.
The LAN A/AAAA records don’t match the HTTPS record from cloudflare, so browsers freak out.
Once I disabled cloudflares proxying, I no longer get HTTPS records returned and all works as intended.
I’ll either have to keep cloudflare proxying disabled, or switch pihole out for a more comprehensive DNS solution so I can set/block HTTPS records :(
Thank you @bobslaede@feddit.dk for pointing me in the right direction.
That unfortunately did not work. I am only getting the ipv4 address now, but I still get the same ECH error in chrome 1/5 tries.
Firefox now changed errors from ‘invalid certificate’ to ‘connection is insecure but this site has HSTS’ (true). Still wont show the cert or provide any further info. (forgot to grab a screenshot before the below ‘solution’)
I’m really annoyed at this point and have just disabled cloudflare proxying for this service. That seems to have sorted it for all browsers. I may look further later, I may just say fuck it and leave it like this. Gotta walk away for a bit.
I’ll look into that next if what I’ve done doesn’t work. (see other comments)
Added an AAAA record to pihole:
ombi.mydomain.example 0000:0000::0000:0000
Now nslookup returns the correct ipv4 address, and ‘::’ as the ipv6.
We’ll see if that works.
Crap, looks like that’s exactly what it is.
Now how to fix that…
I do have external acces to Ombi via cloudflare; but the device I’m seeing this problem on is permanently connected to a VPN hosted from the same server machine as ombi/nginx with ‘block all connections without VPN’ enabled. And this testing has been done from within the same LAN.
It should never see/reach cloudflare for this service.
/edit; I’ve also disabled ‘use secure DNS’ in chrome. I host a local DNS within that lan/vpn network.
You’ve done enough, keeping it behind your routers firewall.
You could block LAN access and require a VPN connection to that specific machine if you really wanted more, but I’m not that concerned about it.
Yup. Point is; if you’re not depending on just its login page to keep it secure, there’s not a whole lot needing ‘security patches’, so I wouldn’t be all that concerned about slow updates. As long as it remains bug free, I’m happy.
And security patches
Something with the power of dockge should be behind a seprate form of authentication imo.
I only access it via VPN, it’s not exposed to WAN.
Considering how old Facebook is, you’d think they would have their shit together when it comes to password security…
I tend to just use FolderSync myself. To avoid battery issues, I have a schedule for most folders; but my DCIM/Pictures folders sync immediately upon changes. I then have a widget on my homepage that triggers a ‘sync all’. Anytime I need files synced immediately, it’s easy enough to click that button.
it doesn’t necessarily take full resolution images
just because it can capture images a few hundred milliseconds apart doesn’t mean it’s continuously capturing images. It could be several in short bursts with a delay between groups of images.
There’s quite a bit of info here:
https://en.m.wikipedia.org/wiki/List_of_Internet_top-level_domains
Some are entirely open, some have usage restrictions like .gov and .edu, some had restrictions but later removed them.
To be fair, they aren’t specifically targeting this data.
Rootkits give the software unrestricted access to all the data on the computer. You then trust that they don’t use that access for anything nefarious… Aswell as trusting there’s no bugs/vulnerabilities in that software that give a third party access to that data.
While I haven’t looked into this particular anti-cheat; they frequently prevent Linux users from playing altogether, ban users due to false positives, and sometimes even gain/require access to data entirely unrelated to gaming, such as your personal documents or even browser data (cookies, history, passwords/tokens, etc) as many of them contain Rootkits
GNOME Linux I use it regularly to switch between tasks/windows, as well as windows+arrow keys to snap windows to edges or minimize them.
If you use usenet, many indexers have a requests section. I’ve had a couple filled at NZBgeek in the past.
I remember doing this with a group of friends at one point. It was late at night, and we wanted to make as much noise as possible; so we were absolutely pounding on people’s doors before running and hiding in their bushes or around the corner. Wherever we could be out of sight, but still see their reaction as they opened the door and raged into the darkness.
One of my friends decided to kick one door, and managed to break the latch literally kicking the front door in… (must have been pretty weak/damaged already, we couldn’t have been more than 13yo at the time) We didn’t manage to hide in time and got chased for like 6 blocks before the guy was too tired to chase us anymore and we lost him.
(I’ll note this was not in America; firearms were not a concern in the slightest)
@bobslaede@feddit.dk I could kiss you. You’ve been invaluable my friend, thank you!
Just gave this a test: CNAME ombi.domain -> local.domain with cloudflares proxy re-enabled.
Now the HTTPS, A, and AAAA requests all receive the CNAME response and browsers are happy. I didn’t even have to modify ngnix to recognize local.domain like I thought I might.