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

Identifying Airtel middleboxes that censor HTTPS traffic

iamkush.me

Post reply on HN
Print view View original

91–100 of 130 posts

Re: Identifying Airtel middleboxes that censor HTTPS traffic

#91

Post by pixl97 »

joosters wrote: post #62
walrus01 wrote: post #59

Earlier quoted context omitted.

> let's use the typical examples, e.g. child porn sites, malware domains a futile game of whack-a-mole that only serves to make politicians feel good, and so they can claim they're "doing something" about social threats. malware domains can be adequately addressed at the application level through things such as: https://www.google.com/search?channel=fs&client=ubuntu&q=goo...

Devil's advocate response: If these content blockers are just 'futile games of whack-a-mole', then why are you getting up-in-arms about their existence? Should be easy to avoid them if you truly believe what you say.

Because they will block unintended things.

"Oh, you want to do breast cancer research, sorry, boobies R bad, the sky God said so"

Re: Identifying Airtel middleboxes that censor HTTPS traffic

#92

Post by occamrazor »

commandlinefan wrote: post #71

We have SNI because it's needed to support virtual hosting, which we really only need because IPv4 addresses are scarce. If we could ever get to IPv6, SNI could be retired completely.

True, but then IP based blocking would be highly effective.

Re: Identifying Airtel middleboxes that censor HTTPS traffic

#93

Post by Dylan16807 »

PowerBar wrote: post #82
hedora wrote: post #73

I wish the world would adopt tcpcrypt. SSL provides two services, encryption, and authentication. tcpcrypt just does the encryption part. Once the connection is established, userspace on both sides can invoke an ioctl that provides a session nonce. If the nonce matches on both sides, the connection is not man-in-the-middled. It’s easy to confirm the nonce matches: Both sides sign it and send it to the other party. Th…

That would still rely on A) some kind of secret that only the server knows that the client can verify in order to ensure it's not trading nonces with the MITM. B) A way for the client to ensure that the nonce isn't being passed through a second tcpcrypt session between the MITM and the server with the connection being in cleartext between the 2 tcpcrypt streams. Currently the best supported method of implementing bot…

> which means you may as well use TLS

Even if you don't authenticate at all, it makes it much more expensive to intercept all these connections.

And TLS lacks a way to automatically apply it to all connections.

Also I don't understand what scenario you're outlining with B.

Re: Identifying Airtel middleboxes that censor HTTPS traffic

#94

Post by bpmooch »

addicted wrote: post #87
walrus01 wrote: post #59

Earlier quoted context omitted.

> let's use the typical examples, e.g. child porn sites, malware domains a futile game of whack-a-mole that only serves to make politicians feel good, and so they can claim they're "doing something" about social threats. malware domains can be adequately addressed at the application level through things such as: https://www.google.com/search?channel=fs&client=ubuntu&q=goo...

Whack a mole can be a highly successful strategy if there is a cost to having the mole appear somewhere else and the whacker has more resources than the one controlling the mole.

Successful does not imply sustainable. There is an argument to be made for doing manual strategies like whack-a-mole until you have a generic solution, but if you don't have the generic solution coming down the pike, it's time to go back to the drawing board.

Re: Identifying Airtel middleboxes that censor HTTPS traffic

#95

Post by tialaramex »

davidhyde wrote: post #85
tialaramex wrote: post #38

Earlier quoted context omitted.

TLS 1.3 was published as RFC 8446 back in 2018. I know it sometimes seems like this is still 2016 somehow, but it is not.

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 force may be exercised against you by those with a monopoly on its use.

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

Re: Identifying Airtel middleboxes that censor HTTPS traffic

#96

Post by eggsnbacon1 »

Tepix wrote: post #24
airtelblock wrote: post #11

Earlier quoted context omitted.

Setting esni to enabled in Firefox partially works. But Airtel really, really wants to run scripts and show ads on blocked pages. Duckduckgo - https://i.postimg.cc/SqkRhpRC/Mozilla-Firefox-29-09-20-w-PA.... Pirate Bay - https://i.postimg.cc/qMmwMXVY/t-29-09-20-9-Dv.png

How do they inject stuff into HTTPS pages?

Unless the site uses certificate pinning its possible to do a downgrade attack that forces browser off of HTTPS. The extension HTTPS Everywhere is a stopgap against this

Re: Identifying Airtel middleboxes that censor HTTPS traffic

#97

Post by kitteh »

walrus01 wrote: post #86
kitteh wrote: 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…

Absolutely agreed. It is really easy to be a shitty, lazy colocation/hosting/VPS hosting company. It is somewhat more effort and more difficult to be a proper one. Margins are so thin in the hosting business that it would be own version of a personal hell... I feel a lot better about operating symmetric gigabit last mile residential services.

Yes. Many of these shops follow the same design patterns. Ports for hosts at L2 that they bill on that are part of a big Vlan/L3/SVI interface that has tons of customers. I've seen these configs where folks have hundreds of "secondary" ip addresses setup where any customer can steal other customer IPs in addition to lack of anti spoofing. It's slop and it's tolerated.

Re: Identifying Airtel middleboxes that censor HTTPS traffic

#98

Post by Spivak »

Dylan16807 wrote: post #93
PowerBar wrote: post #82

Earlier quoted context omitted.

That would still rely on A) some kind of secret that only the server knows that the client can verify in order to ensure it's not trading nonces with the MITM. B) A way for the client to ensure that the nonce isn't being passed through a second tcpcrypt session between the MITM and the server with the connection being in cleartext between the 2 tcpcrypt streams. Currently the best supported method of implementing bot…

> which means you may as well use TLS Even if you don't authenticate at all, it makes it much more expensive to intercept all these connections. And TLS lacks a way to automatically apply it to all connections. Also I don't understand what scenario you're outlining with B.

Client Evil Middlebox Real Web Server

Client establishes a tcpcrypt session with what it thinks is Real Web Server but is actually Evil Middlebox replaying the request to the server and the response back to the client.

Re: Identifying Airtel middleboxes that censor HTTPS traffic

#99

Post by ev1 »

kitteh wrote: post #69
walrus01 wrote: post #37

On a meta level, this is one of the reasons why I tell every junior/entry level person I encounter in the ISP business the following: Ethics is important in network engineering. You can and should refuse to do things that cause measurable harm to the Internet. You should understand why certain things are bad, and should make a conscious choice not to aid and abet them. It is regretful that organizations like NANOG, R…

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.

Re: Identifying Airtel middleboxes that censor HTTPS traffic

#100

Post by Dylan16807 »

Spivak wrote: post #98
Dylan16807 wrote: post #93

Earlier quoted context omitted.

> which means you may as well use TLS Even if you don't authenticate at all, it makes it much more expensive to intercept all these connections. And TLS lacks a way to automatically apply it to all connections. Also I don't understand what scenario you're outlining with B.

Client Evil Middlebox Real Web Server Client establishes a tcpcrypt session with what it thinks is Real Web Server but is actually Evil Middlebox replaying the request to the server and the response back to the client.

Oh so A and B are describing the same scenario, okay.
Post reply on HN