Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Intercepting t.co links using DNS rewrites

djharper.dev

Post reply on HN
Print view View original

51–60 of 60 posts

Re: Intercepting t.co links using DNS rewrites

#51

Post by nonrandomstring »

ianai wrote: post #49
nonrandomstring wrote: post #45

Earlier quoted context omitted.

> the internet becoming deep fried Good phrase. I've frequently heard the term "Kentucky Fried Education" applied to the decay of schools and universities under the influence of big-tech mediocrity. My Digital Vegan response would be that "heavily processed" content harms your intellectual health because it's not fresh and has no vitamins :) Ted Nelson anticipated this "death by indirection". Some of his early writin…

Couldn't a bi-directional link still be written into HTML? Like any other tag, it could simply go unused while being available so nobody feels obligated.

I'm not sure. It seems a reasonable question. I think the obstacle is the browser monopoly. For the same reasons the "semantic web" and RDF knowledge tri-graphs failed in the wild - the current paradigm is frozen in a "works for me" state of arrested development. You could theoretically build this behind the existing "web" but it would get no critical purchase.

Re: Intercepting t.co links using DNS rewrites

#52

Post by modeless »

donalhunt wrote: post #46
modeless wrote: post #25

Will this show up in Certificate Transparency logs?

Unlikely as the logs are appended to by CAs when they issue certificates. Browsers could in theory contribute data but the infrastructure to support that would likely to be orders of magnitude bigger. I'm scared even thinking about going down that rabbit hole due to the expectation of what would be found (MITM evidence). :_(

I thought browsers did contribute. Otherwise any CA could issue as many certificates as they like and simply not report them. Is that really possible?

Re: Intercepting t.co links using DNS rewrites

#53

Post by djhworld »

human wrote: post #38
meatjuice wrote: post #37

Just quit twitter and it's all good huh? Why is everyone not leaving Twitter?

It’s not just Twitter. Maybe this tool could be made to uncloack a list of known url shorteners.

It actually does work this way, you just need to setup your DNS for the other shorteners too :)

List of supported ones is here: https://github.com/djhworld/theunwrapper/blob/main/config/un...

Re: Intercepting t.co links using DNS rewrites

#54

Post by djhworld »

justusthane wrote: post #50

Clever solution! The author keeps emphasizing how hacky and what a terrible idea this is, but it's really not provided they trust their own infrastructure. This is exactly how SSL decryption in corporate environments works as well - MITM traffic using a cert issued by your own CA.

I think I was more bracing myself for a deluge of disapproving comments, so just wanted to make sure to emphasise I know the drawbacks of the approach and understand the risks etc :)

Re: Intercepting t.co links using DNS rewrites

#55

Post by throwaway81523 »

I have a messy python script that does something like this for a bunch of sites. I've been wanting to rewrite it into a browser extension someday. Doing it at DNS level hadn't occurred to me. The python script is able to clean up a lot of tracking parameters though, while leaving the base domain the same, as well as bypassing some redirectors like t.co.

Re: Intercepting t.co links using DNS rewrites

#56

Post by 1vuio0pswjnm7 »

djhworld wrote: post #42
1vuio0pswjnm7 wrote: post #33

If (hypothetically at least) the "go service" is running on the device, then if one controls DNS on the device, one can set the A record for the t.co domainname to the address of the go service. In that case, does one still need a "reverse proxy".

Yeah, I was running the service on a different port though, the proxy was just to work around that.

Why does service need to run on a different port, i.e., not 80 or 443. What about running the service on the loopback, 127.0.0.2 or whatever. I ask because I have run into similar problems.

Re: Intercepting t.co links using DNS rewrites

#57

Post by TheHappyOddish »

djhworld wrote: post #54
justusthane wrote: post #50

Clever solution! The author keeps emphasizing how hacky and what a terrible idea this is, but it's really not provided they trust their own infrastructure. This is exactly how SSL decryption in corporate environments works as well - MITM traffic using a cert issued by your own CA.

I think I was more bracing myself for a deluge of disapproving comments, so just wanted to make sure to emphasise I know the drawbacks of the approach and understand the risks etc :)

Well, it seems you've been disappointed!

I thought it was odd you kept calling it "bad" and "awful". It's exactly as secure as any other certificate on the web. Arguably more, as you're aware of any access to the keys. The only differentiation is a commercial interest, nothing "bad" at all.

Re: Intercepting t.co links using DNS rewrites

#58

Post by TheHappyOddish »

arnath wrote: post #41

Maybe I’m missing something, but it seems like this doesn’t need to be a DNS rewrite at all. Couldn’t you just set a proxy server for outgoing requests that passes through for ones that aren’t a redirect? Or is the trade off there performance (since you’re proxying every request instead of just certain DNS names)?

If you're already running a squid style proxy server, you'd need to MITM the TLS request regardless. If you're just doing it for a single site, the DNS solution is a lot more light weight.

Re: Intercepting t.co links using DNS rewrites

#59

Post by TheHappyOddish »

1vuio0pswjnm7 wrote: post #56
djhworld wrote: post #42

Earlier quoted context omitted.

Yeah, I was running the service on a different port though, the proxy was just to work around that.

Why does service need to run on a different port, i.e., not 80 or 443. What about running the service on the loopback, 127.0.0.2 or whatever. I ask because I have run into similar problems.

Using nginx, caddy, apache etc means you can offload the SSL handling there and let the application just be an application. In the age of containers, setting up a reverse proxy to handle it is minimal effort.

Re: Intercepting t.co links using DNS rewrites

#60

Post by 1vuio0pswjnm7 »

TheHappyOddish wrote: post #59
1vuio0pswjnm7 wrote: post #56

Earlier quoted context omitted.

Why does service need to run on a different port, i.e., not 80 or 443. What about running the service on the loopback, 127.0.0.2 or whatever. I ask because I have run into similar problems.

Using nginx, caddy, apache etc means you can offload the SSL handling there and let the application just be an application. In the age of containers, setting up a reverse proxy to handle it is minimal effort.

I use forward proxy, not reverse proxy. It requires minimal effort. No containers needed.

Not a caddy user, but I believe caddy, with a plugin, can function as a forward proxy.

Post reply on HN