Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

First of all, this isn't a MITM attack, it is simply policy enforcement at the DNS layer.

Secondly, imagine sharing a bus with someone pulling down tens of gigs of files from Google Drive over a shared cellular or satellite connection. They are watching out for everyones experience, not just yours. If you need to get work done, they don't prevent you from bringing your own dedicated connectivity.



> First of all, this isn't a MITM attack, it is simply policy enforcement at the DNS layer.

The way it seems to me, they are intercepting outgoing DNS requests that should be queried against Google's DNS servers, since I had "8.8.8.8" and "8.8.4.4" in my /etc/resolv.conf.

Is that not correct?

> Secondly, imagine sharing a bus with someone pulling down tens of gigs of files from Google Drive over a shared cellular or satellite connection.

The solution to that would be to throttle speeds or bandwidth for each connected device, rather than block all access to specific domains. In my case, I just needed to read a static text document (a "Google Doc").


> Is that not correct?

Calling it an "attack" is disingenuous and sensationalist.

> The solution to that would be to throttle speeds or bandwidth for each connected device

That is a pretty slippery slope. You are escalating from blocking some DNS records to doing deep packet inspection of all traffic. You also have no idea what the operating requirements are (maybe they don't have {financial,computational,power} budget to do it your way?).

Again, bring your own connectivity and you get to make the rules. Use someone else's bandwidth, and they make the rules.


You, sir, are quite wrong. Traffic shaping, counting packets per user in the bus, is not deep packet inpection. Intercepting port 53 and replying on behalf of the real owner of the destination ip is seep packet inspection.

Also, blocking a site that sometimes does and sometimes doesn't use a lot of bandwidth, instead of just blocking all uses of lots of bandwidth by measuring it in a destination-agnostic way, is clearly the worse option.

Finally, rules and restrictions on technological devices and connectivity are retarded world-round. Your personal gadgets, your home internet connection, your phone's internet connection, all have ridiculous restrictions that no self-respecting technically savvy person follows (although most don't realize all the things they do that are against the "terms of service"). I don't get too worked up about them anymore, just systematically work around any I run into, just like any sane technically proficient person.


You are correct. I misread his suggestion as rate limiting specific flows, not flat per device rate limiting.


Even then, looking at the TCP/UDP headers to balance traffic is not deep inspection. Pretending to be a server and injecting yourself is both deep inspection and MITM.


your reasonable response reminds me that my tone is excessively harsh... sorry :)


> That is a pretty slippery slope. You are escalating from blocking some DNS records to doing deep packet inspection of all traffic. You also have no idea what the operating requirements are (maybe they don't have {financial,computational,power} budget to do it your way?).

Wait, what? If they have cheaper hardware and can't invest in more now, that certainly is an issue, but traffic shaping per device does not require deep packet inspection.


No. That's -your- solution. Not their solution. They -choose- to block access, which is their right.

Perhaps they should have managed that process better / more transparently.

But you should dial back the entitlement. This "I just needed"..., and then there's the "Well, I'm going to get around it anyway, since it's obviously blocked".


> But you should dial back the entitlement.

Not that you're completely wrong, but he is most likely paying to be there. If the company advertised the WiFi as part of the deal, and he paid for it, I'd say he is at least a little entitled to it.


Seems like a general way to reduce bandwidth consumption, but there are probably better ways then a fake 404 page?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: