Hacker Newsnew | past | comments | ask | show | jobs | submit | chipb's commentslogin

How well does the redirect scheme work for a device that connects to a central DNS server listening on, say, port 5353 instead? What about 80 or 443?



Well, it’s more complicated, but in theory you could do some deep packet inspection that understands the protocols: personally, I’d use this to break DoH connections (for every host name seen in SNI, attempt a DoH query, if it resolves, reset the connection) and attempt to force everything to fall back to plain DNS. Then, whitelist a couple outbound ports (on most networks, maybe just 443 + 53?) and block VPNs.


With the Portmaster (https://github.com/safing/portmaster) we're going in that direction, but it will take a couple more years to be able to go that deep. Have a look!


> or every host name seen in SNI

Not going to be possible in a few years or so:

https://news.ycombinator.com/item?id=25344311


meh. The outer SNI and the IP address still tell a lot about what you are doing online.


Also, with things like this, you can just reset connections using HTTPS features you don’t support. It might eventually become painful, but it’ll be fine for the near future. And, if enough enterprise middleboxes do this, the standards will be DOA.


> How well does the redirect scheme work for a device that connects to a central DNS server listening on, say, port 5353 instead? How about 80 or 443?

Just because it is not a silver bullet doesn't mean it is not effective for a large percentage of users.


Or just try a not-so-random one:

   kill(1, 9);


Huh. I guess it’s not too surprising, but that doesn’t work at all. init gets special treatment for signals.

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...


Docs seem to indicate that it is: http://doc.freenas.org/11/services.html#s3


Except you can already query/set the color palette to arbitrary RGB values with control sequences (at least with xterm, rxvt-unicode, and I imagine others).

As far as I've been able to tell, "truecolor" terminal support is about simultaneous display of a range of colors beyond what fits in a palette. Which, eh...seems a bit much for a terminal.


You're right, but I think that truecolor support is easier to program.

I vividly remember when I wrote DOS programs which used VGA/SVGA graphics in the early 90s; switching from palette-based colors to RGB colors was something I really enjoyed! Back in the 90s, loading a 256 color image that used its own palette into DeluxePaint would change the colors of DP's interface too.

Something similar would happen today under tmux, I think: if two side-by-side panels contain two different programs, and one of them reprograms the palette, the other program would be affected too.


Although there's some real gems in there (I can't believe I never ran across vipe before!), its Debian package conflicts with the GNU parallel package: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=718816 Quite annoying.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: