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.
As long as the ISPs retain monopoly positions, they will be able to do as they please (or as the NSA pleases to make them do).
And once there is healthy competition among them, there will be no need for the rest of us to legislate every minutiae of their behavior.
In Soviet Washington the swamp drains you.
if someone is selling "internet access" at x throughput rate.... that should mean something.
if someone wants to sell http-only access, fine. But you can't call it "internet access".
THL phish sticks
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.
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.
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"
The log matches a Cisco firewall attempting to block malware and such being sent out.
It replaces all unknown / unsupported smtp commands with XXXXXX.
http://www.cisco.com/c/en/us/t...
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.
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.
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.
Agree. A good article would explain how it happens, such as on Cisco gear and how it may or may not be deliberate and would explain what you can do about it, e.g. use a VPN service.
I should use this sig to advertise my book ISBN-13 : 978-1501515132.
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"
What someone should probably come up with is something between https and http.. that being signed payloads over http... for stuff that is non critical and available via cdn, it would be nice if some of these systems could be used to cache results... the payload could be signed with the private key (used on https), and have that signature added to the header... this way signed http objects could be used via https, without the warnings... the content matches the signature.... edge caching systems can still be used (if they respect the header).. maybe use httpsd as the protocol (http + signed data) and fallback to https if there isn't a signature.
Michael J. Ryan - tracker1.info
Disclaimer: I am a senior network engineer at a large regional ISP.
/24 subnets. In egregious cases, entire netblock allocations.
Transparent proxying, particularly on smtp is unfortunately commonly applied to residential connectivity, and there's little that can be done about it (short of blocking it entirely, which is what a lot of ISPs do).
When Joe User's windows machine gets infected and starts launching spam at the universe, if we don't catch it quick enough, it results in blocks. Sometimes if the infection is big, the blocks can happen to entire
Usually, the transparent proxy is employed to limit the damage (number of IPs) that may be blocked in the event of a compromise. In this case, the proxy *should* support encryption, that part is inexcusable, however, we have to do something to protect our network from you guys.
They block encryption they are violating the telecommunication laws. And so they are not a carrier anymore.
If you mean "common carrier" then the truth is that they never where one.
Maybe we should be looking at the origins of the "common carrier" concept, and learn how they apply to the current situation. A number of historians have written on this topic, and the history definitely applies to our modern network.
Part of the explanation of how "common carrier" arose is in the well-known phrase "kill the messenger". Centuries ago, this was a very real problem. It wasn't unusual for a prince (or other powerful personage) to respond to the receipt of a message he didn't like by punishing the poor fellow who delivered it. The carrier services replied to this in about the only way they could: They opened and read the messages, and if they thought the recipient would react by harming their carrier, they would "edit" the message. And when dealing with a recipient who had a bad history, they'd often sell the message's content to the enemies of the sender or receiver.
Eventually the smarter princes figured out that a reliable message service was worth more than the temporary enjoyment they got from torturing or killing the messenger. So some of them got together with the message services, and worked out an agreement: If a sender and receiver had both signed on with a message company, they could send "sealed" messages, which the message carriers would promise to deliver unopened. But this would only apply if the sender and receiver had both promised not to damage the carriers employees or equipment, etc., etc.
This worked out to the advantage of the princes who joined in such agreements, so the practice spread, and became known (in English) by the phrase "common carrier".
It's easy to see how this all might apply to our current topic. The ISPs are "carriers", but not "common carriers". They have a record of opening and reading our communications, and selling the contents to "enemies" like marketers and government agencies. We're now engaged in collecting evidence about this behavior, and publishing it openly. We should make it clear that, as long as the ISPs continue acting in such perfidious ways, we will continue to work to expose their behavior to the general public, including people they views as their enemies (or "competitors";-).
The parallels to the original situation aren't exact, but we might benefit by knowing the history and trying to find a similar solution that can work today.
Those who do study history are doomed to stand helplessly by while everyone else repeats it.