Live data from Hacker News

Intercepting t.co links using DNS rewrites

djharper.dev

31–40 of 60 posts

Re: Intercepting t.co links using DNS rewrites

#31
post #22
post #19

Earlier quoted context omitted.

Your clicks being logged by Twitter.

It’s not like the original URL is somehow encoded in the short URL, so this bot still has to request from t.co (and everywhere in between) to get the target.

The proxy is resolving all links, therefore denying twitter the information on which links you actually click (see also ad nauseum).

Re: Intercepting t.co links using DNS rewrites

#32

Earlier quoted context omitted.

There are different models here: for every person like you who's trying to reasonably proxy their local traffic, there's a nation state, overbearing educational software provider, &c. who's trying to get access to sensitive and potentially life-affecting communications. When it comes to things like finances, private chats, &c. I think there's a reasonable argument to be made that it's in the website's (and my!) inter…

The problem is that in practice, at least in the US, the most realistic threats are from websites you visit delivering drive-by malware (e.g. spyware and adware), which they actually do constantly. It's such a common practice that it's not even usually phrased that way, but just imagine if you exploited eBay's web servers to port scan their internal network, which is exactly what they did to customers. The responsibl…

IIRC comcast and friends used to intercept plaintext HTTP connections and add advertising to them, so I don’t see why you’d consider this scenario uncommon.

Re: Intercepting t.co links using DNS rewrites

#34

Earlier quoted context omitted.

There are different models here: for every person like you who's trying to reasonably proxy their local traffic, there's a nation state, overbearing educational software provider, &c. who's trying to get access to sensitive and potentially life-affecting communications. When it comes to things like finances, private chats, &c. I think there's a reasonable argument to be made that it's in the website's (and my!) inter…

The problem is that in practice, at least in the US, the most realistic threats are from websites you visit delivering drive-by malware (e.g. spyware and adware), which they actually do constantly. It's such a common practice that it's not even usually phrased that way, but just imagine if you exploited eBay's web servers to port scan their internal network, which is exactly what they did to customers. The responsibl…

I think you're setting up a false dichotomy here: I believe strongly in client filtering and in empowering users to do whatever they need to do to flush out the junk that comes with the modern online experience. I do it on my own devices, though both browser extensions and a local DNS server. I'd even consider doing it with a root CA, if it came to that (but so far it hasn't).

When I say "audit," I mean in the sense that existing ecosystems like CT already provide automatic auditability of certificate issuance. We're not talking about a private company sleuthing through your computer; we're talking about a way to enforce the stated security model that most users expect when a connection is described as "encrypted."

Re: Intercepting t.co links using DNS rewrites

#35
post #31
post #22

Earlier quoted context omitted.

It’s not like the original URL is somehow encoded in the short URL, so this bot still has to request from t.co (and everywhere in between) to get the target.

The proxy is resolving all links, therefore denying twitter the information on which links you actually click (see also ad nauseum).

?

It only resolves the links navigated to, right? It shows you the interstitial page, but only when you try to navigate to the link.

It does enable you to get the clean link and share that.

Re: Intercepting t.co links using DNS rewrites

#40

Will this show up in Certificate Transparency logs?

> I run my own self-signed Certificate Authority (CA) and my reverse proxy uses certs signed by this CA

There's no need to track certificates from private CAs. In order for your browser to trust the certificates you need to manually trust the CA (or your system admin will configure it). Everyone else will see it as invalid.

Post reply on HN