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

11–20 of 60 posts

Re: Intercepting t.co links using DNS rewrites

#11

Post by woodruffw »

bourgeoismedia wrote: post #10
woodruffw wrote: post #8

Nice writeup, and a nice demonstration of one of WebPKI's limitations! I understand why both HPKP and Expect-CT have been obsoleted, but it's a bummer that we still don't have a good enforcement mechanism for CA/cert pinning for a particular site. CT itself does a reasonable job of mitigating the "globally visible mis-issuring CA" problem, but does nothing to help users whose certificate stores contain all kinds of m…

Is your argument that it shouldn't be possible for a user to intercept t.co in this way? Seems like a perfectly valid use case (sidecar process to unwrap 9 layers of redirects from an anonymous browsing context). If the sidecar is validating the original t.co certs and you trust it then what's the problem?

> Is your argument that it shouldn't be possible for a user to intercept t.co in this way?

Not necessarily; the argument is that it's indistinguishable from a malicious MiTM. I think this is a great and legitimate use, but it's also probably something that website providers should be able to make themselves resilient against (or, at the least, be able to audit when it happens).

Re: Intercepting t.co links using DNS rewrites

#12

Post by djhworld »

bourgeoismedia wrote: post #10
woodruffw wrote: post #8

Nice writeup, and a nice demonstration of one of WebPKI's limitations! I understand why both HPKP and Expect-CT have been obsoleted, but it's a bummer that we still don't have a good enforcement mechanism for CA/cert pinning for a particular site. CT itself does a reasonable job of mitigating the "globally visible mis-issuring CA" problem, but does nothing to help users whose certificate stores contain all kinds of m…

Is your argument that it shouldn't be possible for a user to intercept t.co in this way? Seems like a perfectly valid use case (sidecar process to unwrap 9 layers of redirects from an anonymous browsing context). If the sidecar is validating the original t.co certs and you trust it then what's the problem?

One thing I'd neglected to mention in the post is the sidecar uses a public DNS resolver to get the actual t.co link, but it's making the assumption that Go's stdlib enforces this: https://github.com/djhworld/theunwrapper/blob/main/unwrap/un... and doesn't fallback to the system one.

So there is that issue....I guess one way to mitigate it would be to run the sidecar out of the network, or at least have a clean DNS config and not have my custom CA in the root store...i.e. you'd want to be double sure you're going to the real thing and only accepting trusted certs signed by a trusted root.

Re: Intercepting t.co links using DNS rewrites

#13

Post by quesomaster9000 »

I wish there was an easier way to uniformly rewrite links across applications, one which annoys me is Reddit - they seem incapable of consistently linking to content on their own site, some could be fixed with a greasemonkey script but that doesn't work on mobile or across apps.

But this is part of a wider pattern of the internet becoming deep fried, instead of a link we get a short code to a facebook page with a bot reposting tiktok videos of a phone screen-recording of an editorialized livestream of somebody watching a screen-recording of the video on youtube - and ofcourse it starts half way through then loops round again and plays twice with three sets of black bands, content creator @names, watermarks, wifi & signal indicators etc.

If we could all do one thing to help stop the spread of this cancer, that would be great: de-duplication via content addressable links / tags.

But it'll never happen.

Re: Intercepting t.co links using DNS rewrites

#14

Post by jeroenhd »

Just installed this in my own network. Already had my own CA so I just took all the supported domains and generate a certificate for it. The list kind of pollutes my Pihole domain overrides but that's alright by me.

It works well! I'm running it with Nginx in a Proxmox LXC container where I've allocated a meager 64MB of RAM for it and it still has RAM to spare. I wish I could say the same of other "small" tools from across the web that I'm running.

I like the minimalist web pages and the fact it auto-resolves multiple redirects on its own (bit.ly -> msft.it -> aka.ms -> ...) without making you wait for the page to load and the fact it removes tracking parameters for you. I know there are online tools and extensions that the same but those are a pain to install on mobile.

Re: Intercepting t.co links using DNS rewrites

#15

Post by djhworld »

jeroenhd wrote: post #14

Just installed this in my own network. Already had my own CA so I just took all the supported domains and generate a certificate for it. The list kind of pollutes my Pihole domain overrides but that's alright by me. It works well! I'm running it with Nginx in a Proxmox LXC container where I've allocated a meager 64MB of RAM for it and it still has RAM to spare. I wish I could say the same of other "small" tools from…

This is awesome, thanks for taking the time to try it out! I honestly threw it together over a few hours this weekend so it's in a very rough state, and there's no unit tests for it, and none of the code is commented or structured that well so there's probably a lot of edge cases it does not account for.

But still, glad it worked!

Re: Intercepting t.co links using DNS rewrites

#20

Post by b112 »

jojobas wrote: post #19
h43z wrote: post #17

What is this trying to protect from? You see the actual URL in the tweet. Are you worried about redirects, if so why?

Your clicks being logged by Twitter.

And google, facebook, reddit, everyone. I suppose it is another thing to push back against, though.
Post reply on HN