[-] [email protected] 1 points 2 weeks ago

I'm not sure if I agree.

You can't easy man in the middle authenticated protocols like SSH or HTTPS.

Unless you own a CA, or are a powerful country able to coerce a CA, or mandate installing one into users' PCs.

As for SSH - you missed the "TOFU" bit, Trust On First Use. Do you verify your SSH host keys every time before connecting to a new server? The docs for GitHub doesn't even mention it.

unencrypted/unauthenticated protocols are on their death bed.

I partially agree - encryption appears to be a solved problem today. Key distribution, however is not, it's layers upon layers of half-solutions of wishful thinking, glued together with hope.

The layers should be independent to allow for maximum flexibility.

Depends on your threat model and priorities, right :) HPKP is helpful and does not require DNSSEC. DANE and CAA are helpful but require DNSSEC.

[-] [email protected] 1 points 3 weeks ago

How could a hijacked DNS entry harm you?

  • redirect to ads/spam
  • downgrade to HTTP (no HSTS), then steal creds
  • MitM the TOFU of SSH
  • probably something more...

You can leverage the trust in DNSSEC to distribute TLS and SSH fingerprints too, look up DANE.

[-] [email protected] 1 points 3 weeks ago

Oh, now I see. I guess then the DNS64 server needs to do the dnssec verification on behalf of the user, then drop the RRSIG records for the v4->v6 translated names.

Oh, and now I realize I confused the direction. DNS64 makes v4 into v6.

[-] [email protected] 1 points 3 weeks ago

I'm fortunate to get native IPv6, so I'm not very familiar, tho I think I have basic understanding.

Did you mean you need to pick just one of {authoritative DNS server, DNS64} to listen on port 53? No, because the authoritative DNS only needs to be accessible from the outside. Run it on another machine or nonstandard port, then expose via port forwarding. Machines in LAN don't need direct access to the authoritative DNS server, they can just as well resolve via the regular system.

[-] [email protected] 2 points 3 weeks ago

I just self-host my own DNS server. Works like a charm. Setting up DNSSEC was a tad fiddly tho.

Long story short:

  1. Set up Knot, teach it to serve your zone
  2. Test via resolving names in your server (dig can use a specific server)
  3. Disable DNSSEC
  4. Tell your registrar to "use my own DNS server"
  5. Generate the DNSSEC keys, upload only the pubkey to registrar, reenable
[-] [email protected] 2 points 3 weeks ago

Sounds like a bug in the applet, frankly.

Try this in Bash:

$ echo $((`cat /sys/class/power_supply/BAT0/energy_now` * 100 / `cat /sys/class/power_supply/BAT0/energy_full`))
[-] [email protected] 1 points 3 weeks ago

You'll have to try :) I'd be wary of having multiple daemons managing your battery, though - it sounds like a recipe for conflicts, infinite loops and such.

[-] [email protected] 0 points 3 weeks ago

No idea about TLP, I'm not using that.

I created a systemd service for setting the charging threshold on boot, works for me.
This is NixOS syntax, but you get the idea:

	systemd.services.battery-charge-control = {  
		description = "Set battery charging behavior";  
		script = "echo 70 > /sys/class/power_supply/BAT0/charge_start_threshold; echo 81 > /sys/class/power_supply/BAT0/charge_stop_threshold";  
		wantedBy = [ "multi-user.target" ];  
	};  
[-] [email protected] 1 points 4 weeks ago

My rye sourdough ferments for 24h. That takes some planning.

view more: ‹ prev next ›

dihutenosa

0 post score
0 comment score
joined 3 months ago