Slashdot Mirror
ISPs Violating Net Neutrality To Block Encryption
Dupple writes One of the most frequent refrains from the big broadband players and their friends who are fighting against net neutrality rules is that there's no evidence that ISPs have been abusing a lack of net neutrality rules in the past, so why would they start now? That does ignore multiple instances of violations in the past, but in combing through the comments submitted to the FCC concerning net neutrality, we came across one very interesting one that actually makes some rather stunning revelations about the ways in which ISPs are currently violating net neutrality/open internet principles in a way designed to block encryption and thus make everyone a lot less secure.
When it detects the STARTTLS command being sent from the client to the server, the mobile wireless provider modifies the command to âoeXXXXXXXX.â The server does not understand this command and therefore sends an error message to the client.
This smells like a transparent proxy for mail, in a similar manner is providers have been doing transparent proxying for a long time. This does not necessarily have anything to do with DPI and selectively modifying server's responses to client requests.
The whole article is written by folks who clearly have no idea about how the internet works.
I'm not a complete idiot... Some parts are missing.
This was discussed when we were writing the 802.11i security specs. If an attacker can selectively DoS the link/network/whatever when security is enabled, you can fool the user to conclude the security is the problem and turn it off, whereupon everything starts to work.
There is a collision of two principles
1) Silently drop bad packets.
2) Let the user know something bad is happening.
These are opposing goals. In the case of this attack, we want #2, because we know they have evil intent and plaintext is not ok and we need the user to not turn off TLS.
In other cases, like front door attacks (as opposed to MITM), #1 is the way.
This is why designing a good security protocol is hard and TLS still does the wrong thing at the wrong time.
I should use this sig to advertise my book ISBN-13 : 978-1501515132.
> The whole article is written by folks who clearly have no idea about how the internet works.
No. It is written by someone who thinks he knows how it is supposed to work and not how it actually is setup. I had the same thought about transparent proxy however... his final assessment is SPOT ON.
The user, who is paying for internet access, is attempting to connect to a remote machine and, having that connection HIJACKED by a transparent proxy.
If I send a TCP SYN to w.x.y.z, then, as a paying fucking customer, I want that SYN packet to be delivered to w.x.y.z and responded to by the same. There is absolutely no scenario where I want someone else intercepting the traffic and doing something else instead.
In short, the author of the article shouldn't need to know those details because they are all the same to him. End result is, his connection is being tampered with, and he is not recieving the service he paid for.
"I opened my eyes, and everything went dark again"
Time Warner is just as predatory and absurd. When you subscribe to their service, you'll receive almost weekly reminders to "bundle" your service together with cable TV and phone. Opting out from this advertising is almost impossible As a cable internet user, when you set up your open source router to block ICMP traffic and recurse your own DNS, you'll be instantly branded as abberant. IRC and VPN traffic ive found also trigger this reaction. Time Warner DNS servers will then redirect to a page accusing you of sending unwanted traffic. If you want to continue using Time Warner DNS you'll need to complete the electronic equivalent of an apology and sign up for an email address. You'll then be presented with their software and the DHCP assigned DNS servers will begin responding normally again. I returned to my own setup almost immediately after being forced into this.
Eventually my DNS recursor and irc client stopped functioning entirely, so i was forced to tunnel this traffic over to my VPS and the phonecalls started about my "unwanted" traffic. Explaining why you're doing this is pointless, but the calls are harmless so long as you pay the bills on time. In the age of cutthroat capitalism you're supposed to subscribe, bundle, consume, and repeat. My experience with Verizon was just as draconian with the exception that they also block all SMTP traffic and, should you null-route their advertising CDN used to inject targeted content, they become very interactive. Customer service will call you within a day asking to set up a service appointment for a connectivity problem theyve "detected."
Good people go to bed earlier.
This is why I think that the Netflix debacle amounts to a bait-and-switch on the part of the ISPs. If they advertise a connection to the 'Internet' at a given speed, then fail to deliver on that speed when the party on the other end has provided the necessary capacity, they are committing straight-up false advertising.
Isn't the end result the same?
Yes, and I totally agree with you. But this article is written by a journalist, not a techie. It's kind of like watching a Hollywood hacking scene.
I'm not a complete idiot... Some parts are missing.
Isn't the end result the same?
If a transparent proxy changes the TLS messages, it's filtering encrypted traffic so it's a MITM attack.
Still evil.
Yea, but this is nothing new. We'd like our ISPs to be 100% transparent but they are not. This has nothing to do with net neutrality. And their example of Verizon? That's not net neutrality. Netflix went to a peer without consulting Verizon, that is not how things are done. Verizon refused to be forced into that agreement. Yes, the FCC should address peering agreements, but they have absolutely nothing to do with net neutrality. Netflix had their bandwidth in the wrong place, hoping to force Verizon to move as well. It didn't work.
This entire article is just fluff designed to play on tech junkies fears. Net Neutrality should be codified into law, but neither of these issues are good examples of anything related to it. In fact, I'd agree that all of the issues talked about should be addressed by the FCC but their only relation to one another is that they involve "The internet"
Google "250-XXXXXXXA asa cisco starttls" and you'll find this is almost certainly an ASA preventing TLS as configured on the device. Since it doesn't want TLS traffic, the config is to just mangle the packets. Well known effect, been around for years (5+). The FW admin needs to correctly deploy fixup, allow TLS or simply not inspect esmtp. Simple fix, documented in Cisco doc 118550, among many other places.
You beat me to it. That's the first thing that popped into my head, too. This (for some inexplicable reason known only to Cisco) is the *default* behavior of ASA and PIX firewalls, so really it probably just means that someone that didn't know what they were doing threw a firewall in the mix somewhere. It's an easy fix, but requires messing with policy-maps, which inexperienced admins often find confusing.