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.
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"
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.
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.