Live data from Hacker News

Identifying Airtel middleboxes that censor HTTPS traffic

iamkush.me

111–120 of 130 posts

Re: Identifying Airtel middleboxes that censor HTTPS traffic

#111
post #60

Earlier quoted context omitted.

My job overlaps with microwave and millimeter wave RF engineering somewhat. R&S also has no qualms about selling high-end spectrum analysis equipment to authoritarian regimes. Probably done through middlemen. For instance, you can find the Iranian government using their equipment in Tehran to hunt down things they don't like. To be fair, there's probably less than ten manufacturers of their category of spectrum analy…

Interesting, so triangulating people forwarding "open" internet over consumer-grade microwave (like Ubiquiti or similar)? I assume they can't do much about Toosheh since it's "read only", multiplexed with legitimate TV channels on the same transponder, and uplinked from the UAE.

Not with perfect accuracy, but the local oscillator of a receiver (which is mixed with the signal from the antenna to produce an intermediate frequency which is further processed) leaks back out the antenna a little bit.

In the case of an FM radio, this means you can tell what station a given receiver is tuned to, if you make certain assumptions about common LO/IF frequencies. There was a company monetizing this called "Mobiltrak", but I haven't seen much about them lately.

In the satellite case, there's the IF of the LNB itself, which leaks fairly loudly out the feedhorn, but it only tells you which band they're tuned to. There's likely a second IF used in the IRD, which should be much fainter from outside, but if you could recover that, you could tell which transponder is being demodulated.

That still wouldn't tell you if the Toosheh packets are being saved, but if the program they're muxed with isn't particularly popular, it would be a strong hint.

Re: Identifying Airtel middleboxes that censor HTTPS traffic

#112
post #99
post #69

Earlier quoted context omitted.

It'd be nice if we could address some things like BCP38 (anti spoofing), RPKI, route filtering and folks who knowingly support infrastructure that's used for outbound ddos (c2s and regular hosts), spam and malware phishing. Plenty of hosting shops in US and Canada have these problems. That seems a bit more within our reach whereas an ISP in India is more than happy to pay a vendor to implement middlebox packet molest…

I've been dealing with a ban evader/forum shock image spammer for months now, and the place he is buying proxies from is actively doing BGP hijacking on resources owned by AT&T, Windstream, hospitals and universities - for the primary purpose of carding and fraud. I haven't managed to get anyone knowledgeable at those companies to figure out how to pressure the small upstreams (that are not those T1s) to stop it.

Good luck. When I wrote forum software, moderation controls, what people might call shadow banning these days, and other filtering took up 70% development time. Retaliation was DDOS. I was one of Cloudflare’s first customers.

Re: Identifying Airtel middleboxes that censor HTTPS traffic

#113
post #106
post #44

Really loved your article buy why no SSL/HTTPS? It's free afterall.

HTTPS is not free. It has a very significant management/maintenance and compatibility overhead, which is unavoidable by the very nature of HTTPS.

Which can be automated.

Re: Identifying Airtel middleboxes that censor HTTPS traffic

#114

Earlier quoted context omitted.

Censorship is fine if it's opt in. I don't use facebook and censor myself from it. I opt in to use a pihole and adblocker. It filters many things I otherwise would see. You can't often choose your ISP so this makes it extra important for censorship of any kind of to be opt in rather than forced.

My kids will not opt-in to censoring "Thomas the Train" videos when they should be doing their school work. I think I just got everyone to take a step down the slippery slope.

You can opt in to parental control software :)

https://wellbeing.google/

https://support.apple.com/en-in/HT208982

https://support.apple.com/en-in/HT210387

Re: Identifying Airtel middleboxes that censor HTTPS traffic

#115
post #106
post #44

Really loved your article buy why no SSL/HTTPS? It's free afterall.

HTTPS is not free. It has a very significant management/maintenance and compatibility overhead, which is unavoidable by the very nature of HTTPS.

On the scale of a personal blog, its approximately 0 minutes per year to maintain HTTPS certificates using Lets Encrypt with something like certbot (or use Caddy, which handles it on it own).

Re: Identifying Airtel middleboxes that censor HTTPS traffic

#116
post #99
post #69

Earlier quoted context omitted.

It'd be nice if we could address some things like BCP38 (anti spoofing), RPKI, route filtering and folks who knowingly support infrastructure that's used for outbound ddos (c2s and regular hosts), spam and malware phishing. Plenty of hosting shops in US and Canada have these problems. That seems a bit more within our reach whereas an ISP in India is more than happy to pay a vendor to implement middlebox packet molest…

I've been dealing with a ban evader/forum shock image spammer for months now, and the place he is buying proxies from is actively doing BGP hijacking on resources owned by AT&T, Windstream, hospitals and universities - for the primary purpose of carding and fraud. I haven't managed to get anyone knowledgeable at those companies to figure out how to pressure the small upstreams (that are not those T1s) to stop it.

I'm about to start down a road that might lead to where you are, but my target audience is a bit more mature and laid back so it might not be an issue.

But what you said reminded me of a conversation we had here a month ago. I think it may be that I reserve image upload functionality for users who have proven their humanness (and their humanity).

In my case image quality matters much more than quantity, so I can afford to make that choice.

Re: Identifying Airtel middleboxes that censor HTTPS traffic

#117

Earlier quoted context omitted.

That RFC is marked as "PROPOSED STANDARD" which is why I saw it as work in progress but you're right, that seems to be the end of the road for RFC's (for example RFC 6455 December 2011 (websockets) is also marked as proposed standard but this is what everyone has implemented)

The IETF deliberately has no power whatsoever. Whether an IETF standards track proposal in fact becomes a standard everybody implements is entirely up to the implementers. This is in contrast to many standards development organisations (and indeed whether the IETF is even an organisation is open to doubt) which are government functions and can produce de jure standards you're obliged to implement or in the worst case…

> As a result IETF standards are only proposed and that is as you say "the end of the road".

Not really, after PROPOSED STANDARD there's INTERNET STANDARD, the STD series. For instance, IPv4/ICMPv4 (RFC 791/792) is STD 5, UDP (RFC 768) is STD 6, TCP (RFC 793) is STD 7, DNS is STD 13, and so on (STD 1 has the full list).

However, an IETF standard only reaches that level after it's been in use for a while; according to RFC 2026 (BCP 9), "A specification for which significant implementation and successful operational experience has been obtained may be elevated to the Internet Standard level. An Internet Standard (which may simply be referred to as a Standard) is characterized by a high degree of technical maturity and by a generally held belief that the specified protocol or service provides significant benefit to the Internet community."

Re: Identifying Airtel middleboxes that censor HTTPS traffic

#118
post #115
post #106

Earlier quoted context omitted.

HTTPS is not free. It has a very significant management/maintenance and compatibility overhead, which is unavoidable by the very nature of HTTPS.

On the scale of a personal blog, its approximately 0 minutes per year to maintain HTTPS certificates using Lets Encrypt with something like certbot (or use Caddy, which handles it on it own).

Absolutely false. On the scale of a personal blog, the cost of HTTPS is enormous, but the benefit is approximately 0.

Re: Identifying Airtel middleboxes that censor HTTPS traffic

#119
post #106

Earlier quoted context omitted.

HTTPS is not free. It has a very significant management/maintenance and compatibility overhead, which is unavoidable by the very nature of HTTPS.

Which can be automated.

Yes, you gotta automate a whole bunch of things if you need HTTPS, you have to update the protocols every few years, certificates as often as every few months, OpenSSL versions on a moment's notice.

Or, you could decide to just go HTTP-only for your blog, and never bother doing any of the above, never worry about any automation failing for any reason, never worry about any expired or revoked certificates, never worry about the extra compatibility issues that TLS brings. There's no benefit for HTTPS for a personal blog. It's only there to restrict the access, increase attack surface, and cause compatibility issues.

Re: Identifying Airtel middleboxes that censor HTTPS traffic

#120
post #117

Earlier quoted context omitted.

The IETF deliberately has no power whatsoever. Whether an IETF standards track proposal in fact becomes a standard everybody implements is entirely up to the implementers. This is in contrast to many standards development organisations (and indeed whether the IETF is even an organisation is open to doubt) which are government functions and can produce de jure standards you're obliged to implement or in the worst case…

> As a result IETF standards are only proposed and that is as you say "the end of the road". Not really, after PROPOSED STANDARD there's INTERNET STANDARD, the STD series. For instance, IPv4/ICMPv4 (RFC 791/792) is STD 5, UDP (RFC 768) is STD 6, TCP (RFC 793) is STD 7, DNS is STD 13, and so on (STD 1 has the full list). However, an IETF standard only reaches that level after it's been in use for a while; according to…

Good point, thanks for correcting that.
Post reply on HN