Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
×
Communications Encryption Your Rights Online

ISPs Violating Net Neutrality To Block Encryption 149

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.
This discussion has been archived. No new comments can be posted.

ISPs Violating Net Neutrality To Block Encryption

Comments Filter:
  • No Carriers (Score:2, Insightful)

    by Anonymous Coward

    They block encryption they are violating the telecommunication laws. And so they are not a carrier anymore.

    • Re: (Score:3, Interesting)

      by sabri ( 584428 )
      I call bullshit without more evidence. From the article:

      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.

      • Re:No Carriers (Score:5, Insightful)

        by TechyImmigrant ( 175943 ) on Tuesday October 14, 2014 @01:06PM (#48141991) Homepage Journal

        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.

        • Re:No Carriers (Score:5, Interesting)

          by sabri ( 584428 ) on Tuesday October 14, 2014 @01:40PM (#48142307)

          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.

          • Re:No Carriers (Score:5, Informative)

            by TechyImmigrant ( 175943 ) on Tuesday October 14, 2014 @01:51PM (#48142419) Homepage Journal

            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.

          • by aztracker1 ( 702135 ) on Tuesday October 14, 2014 @02:05PM (#48142525) Homepage
            So that means I won't be getting a BJ during my tryout to be an underground super elite hacker dude?
          • by uncqual ( 836337 )

            It's kind of like watching a Hollywood hacking scene.

            Speak for yourself. The password cracking programs I use display all the passwords as they are checked (unfortunately, I've been unsuccessful at cracking passwords in keyspaces exceeding 5 alpha numeric characters - I think I need a monitor with a faster response time).

          • Re:No Carriers (Score:4, Informative)

            by Jane Q. Public ( 1010737 ) on Tuesday October 14, 2014 @05:15PM (#48144293)
            What's really weird is this claim in OP:

            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?

            Since when? Comcast routinely throttled P2P and other traffic until the FCC forced them to stop, a couple of years ago.

            Their method was to send fake reset packets. The only way they could do that is via deep packet inspection and intentionally messing with your "private" communication.

          • by rtb61 ( 674572 )

            Except of course the journalist is simply extracting that part of the information from a submission to the Federal Communications Commission by a company seeking to promote net neutrality. So youch, a company (name not yet reported) accused of directly intercepting and interfering with a customers communications in order to be able to intercept or block the contents depending upon the sending software and it's controls. You would know that if you actually read the article but of course you could be working

        • Re:No Carriers (Score:5, Interesting)

          by Charliemopps ( 1157495 ) on Tuesday October 14, 2014 @01:54PM (#48142443)

          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"

          • by Cyberax ( 705495 )
            "That is not how things are done."? WTF? Level3 (Netflix's network) was ready to provide additional interconnections with Verizon. That's HOW things are done, not by extortion of end-users.
        • by tjlee ( 1695968 )
          It's no longer transparent if it changes the traffic it is proxying...
      • Re:No Carriers (Score:5, Interesting)

        by TheCarp ( 96830 ) <sjc.carpanet@net> on Tuesday October 14, 2014 @01:17PM (#48142091) Homepage

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

        • by sabri ( 584428 )

          End result is, his connection is being tampered with, and he is not recieving the service he paid for.

          True that, and I fully agree. BUT: the article suggests something far more evil than the evidence provided suggests, and that's what annoys me.

          And like I said, transparent proxying has been done for a long time, and is actually undergoing a phase of renewed youth thanks to CDN/TIC solutions like PeerApp [peerapp.com] and this Brocade/Bluecoat solution [brocade.com].

          • Re:No Carriers (Score:5, Insightful)

            by aztracker1 ( 702135 ) on Tuesday October 14, 2014 @02:11PM (#48142585) Homepage
            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.
            • by sabri ( 584428 )

              What someone should probably come up with is something between https and http.. that being signed payloads over http

              I like that idea. Why not write a standard? :)

          • by sjames ( 1099 )

            Actually, no. TFA said that the client's communication was overwritten with something else and that is exactly what happened. He didn't claim any particular mechanism in use.

            Transparent proxying and DPI are equally evil. Either way, what you send is not what the peer of the connection receives and vice-versa.

        • Re:No Carriers (Score:5, Informative)

          by DamnOregonian ( 963763 ) on Tuesday October 14, 2014 @02:52PM (#48142963)
          Disclaimer: I am a senior network engineer at a large regional ISP.

          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 /24 subnets. In egregious cases, entire netblock allocations.

          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.
          • Uh, why not just block outgoing port 25? Do you have a reason for leaving it open to non-business customers?
            • Um, maybe because non-business customers use SMTP?

              • by icebike ( 68054 )

                This is a case of the client side trying to connect on port 25 then switch to SSL.

                On the foot note of Page 8, they acknowledge that the proper way, and the way most modern clients do this, is to connect
                to on port 465 with SMTPS, rather than on port 25, and then switch.

                Golden Frog presented no evidence that they tried this same provider with a properly configured mail client.
                So while it sounds all nasty, it may just be the carrier enforcing a better security method than connecting insecurely
                and then changing

              • Port 465 is for encrypted SMTP, and port 587 is for message submission. Port 25 is for server communications. No consumer grade line should allow outgoing port 25 unless you request to be white-listed and pass a technical competence test, you know, like knowing that non-business customers should not be using SMTP over port 25.
          • by jonwil ( 467024 )

            Does your ISP tell your customers that they do this kind of proxying and why? If you tell customers that you need to do it to stop SPAM on your networks, people will be less likely to shoot off at the mouth and say "hey, ISPs are blocking encryption so they can spy on all my emails" or whatever as in the tech-dirt article.

            • Yes, it's in the T's and C's.
              Has been for every ISP we've acquired and merged with, as well.

              We also tell them how to use submission ports to get around it.
      • by eth1 ( 94901 )

        I call bullshit without more evidence. From the article:

        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.

        Worse, TFA only gives ONE example, then goes on to say, "...monitoring the responses from the email server in issue."

        This seems to imply that not all email servers have a problem. Given that the symptoms (*****-ing out the SMTP banner, and blocking STARTTLS) are the exact behavior of a default protocol inspection config on a Cisco ASA or PIX firewall, I'm guessing that it's a major overreaction to the way the firewall in front of the destination email server is configured, and nothing to do with the ISP at

      • by sjames ( 1099 )

        It doesn't matter if the attack is DPI or MITM, it's still an attack.

        • by icebike ( 68054 )

          Seems to me its more of a denial than an attack.

          They want you to only connect outgoing SMTPS connections on 465. Golden Frog never even tested that, even after showing in a footnote that this was "possible" (their wording, I suspect they didn't want to admit it is the preferred way). Tempest Teapot.

          • by sjames ( 1099 )

            They want you to only connect outgoing SMTPS connections on 465.

            Were that true, they would block outbound connections to port 25, not intercept them and use dirty proxy tricks to get the client to not use encryption.

            • by icebike ( 68054 )

              I don't disagree that is what they should have done.

              But I suppose they have to allow for some sites that don't support ssl/tls.
              It seems very ham-handed, and easily detectable.

              Still, Golden Frog should have Named and Shamed, instead of protecting the guilty.

              I've run into hotels that wouldn't allow smtps or secure imaps connections over their wifi.
              I checked out, and filled out the complaint form, and mailed to corporate headquarters. (I was pissed).
              I've never stepped foot in that chain since.

      • by suutar ( 1860506 )

        I seem to be misunderstanding as well. How exactly do they modify the command without DPI?

      • Look at the odd XXX replacements. Why overwrite commands with garbage? That's obvious: In order to maintain byte positions, and thus TCP sequence numbers, allowing for it to be done via DPI rather than (more expensive and noticeable) conventional proxying.

        If I had to speculate why, I'd wonder if they want to block encryption in order to monitor emails for advertising purposes, or possibly have been given some form of secret 'tell no-one' warrant that demands they disable encryption because some unspecified

    • They never were.

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

      • Re:No Carriers (Score:5, Insightful)

        by jc42 ( 318812 ) on Tuesday October 14, 2014 @03:41PM (#48143443) Homepage Journal

        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.

        • by jd ( 1658 )

          So the take-home message is that if you don't want Comcast to cut your head off, you don't send them any messages until they sign up to the agreement.

        • by Wolfrider ( 856 )

          --I wish I had mod points; you deserve that +5 Informative / Insightful ;-)

  • by mi ( 197448 ) <slashdot-2017q4@virtual-estates.net> on Tuesday October 14, 2014 @01:01PM (#48141923) Homepage Journal

    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.

    • Re: (Score:2, Insightful)

      by Anonymous Coward

      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.

      Bullshit.

      Once they have competition, they'll just form a cartel to collectively screw us all over.

      If you think competition gets rid of the natural urge of corporations to act like assholes ... you're fucking deluded.

      Human nature is such that if you decide you no longer need legislation, they'll just start doing it again.

      I don't believe for a moment they're ever going to be

      • And if you started you own company, would you be the same asshole your competition is being? Apparently so.

        • And if you started you own company, would you be the same asshole your competition is being? Apparently so.

          No, if he started his own company, which he could do today, he'd find out that it costs a lot of money to overbuild an existing infrastructure and then compete for every customer with the existing services. He'll probably figure out that the return on investment will be negative for at least the first five years, perhaps longer, so if he's not a company the size of Google he's not going to last.

          He'll get the fun of negotiating for a franchise agreement with his municipality, paying low wage workers to str

      • Competition brings out the least in people.

        If you measure yourself against the world, you'll always have room to improve.

        If you measure yourself against other men, if you're the best, you'll never reach your potential.

        And, because your peers have motivation to celebrate your failures, rather than your successes, you'll actually be fighting those who should be benefiting from your achievements.

        On a personal level... dealing with competitive people is too tiresome to bear. Nothing they have to offer is worth

        • And that post explains the Olympics, art, and literature. And virtually every other endeavor where one compares their work to another's.

          What BS.

          A thing measured improves.

          True competitors don't slow down when they reach the top. They never give their competition a chance to catch up.

          Your peers are your competition . Your customers, clients, or fans are your audience. Your peers are not your judge, your audience is. Listening to your competitors for advice is fraught with peril.

          You need not deal with com

          • Comparing Internet service in the US to other nations is mostly pointless.
             
            Do you get how amusing that is, given the context?

      • by mi ( 197448 ) <slashdot-2017q4@virtual-estates.net> on Tuesday October 14, 2014 @03:30PM (#48143337) Homepage Journal

        Once they have competition, they'll just form a cartel to collectively screw us all over.

        Does not happen with restaurateurs, car-makers, nor even the cellular-service providers. Why would it happen with the ISPs?

        I don't believe for a moment they're ever going to be anything except for self serving douchebags. Competition won't change that.

        People will be looking out for themselves, that much is true. Competition, however, will make providing better service the most profitable course of action.

        You guys who think the free market solves problems are pretty fucking deluded.

        For all the problems with the free market, nothing humanity has tried works better...

    • by atfrase ( 879806 ) on Tuesday October 14, 2014 @02:21PM (#48142685)

      I think this hints at the fundamental disagreement between people's thoughts on "net neutrality."

      Some folks think business is business and should be able to do whatever it wants, probably because they have money or some other vested interest in the current telecommunications behemoths, so they want the maximum return on that investment no matter who gets screwed in the process.

      Other folks (like you) see a problem with the current arrangement, and believe that the solution is to create more competition so that the telecom industry "regulates itself." In principle I agree, but I think that's just not possible in this case.

      The rest of us believe that telecom is, was, and (for the foreseeable future) always will be a *natural* monopoly. You can't have meaningful competition for building roads and sewers and power grids, in part because those things cost so much money that it is effectively impossible for a new player to enter the market, and in part because our cities would be a mess if we had to deal with multiple parallel networks of these kinds of infrastructural utilities. Telecom has exactly the same issues; no matter how data transmission technology evolves (in the foreseeable future), be it telephone wires, coaxial cables, fiber optics, or whatever is next, it will always be vastly more efficient for a single entity to install and manage that physical data network, at least at the local level. There just can not be meaningful local competition in data transmission services (which includes telephone, television, internet, etc). So the solution for telecom is exactly the same as it is for water, sewer, roads, etc: allow one entity to run it, but regulate them heavily as a public utility.

      The problem we're facing now is "how to get there from here." We should have made this transition decades ago, but for a variety of reasons didn't, and so now those telecom monopolies have been allowed to remain private for too long and grow to enormous size. Wrangling them back into a public utility arrangement is the only sustainable path forward, but it will also be extremely politically difficult.

      • by mi ( 197448 ) <slashdot-2017q4@virtual-estates.net> on Tuesday October 14, 2014 @04:03PM (#48143703) Homepage Journal

        The rest of us believe that telecom is, was, and (for the foreseeable future) always will be a *natural* monopoly

        Natural monopoly is a myth [mises.org]. A myth very convenient for and thus perpetuated by the government officials of various levels as it gives them undue power [wired.com], but a myth nonetheless.

        You can't have meaningful competition for building roads and sewers and power grids

        Yes, you can. Tokyo has competing subway lines — why can't New York City? Your GPS is likely to show you several options for any route of appreciable lengths — why can't those different roads be privately-owned and compete?

        For example, to leave New York you have many options (most of them requiring payment on top of the taxes) — why can't those bridges and tunnels be privately owned and compete with each other? Maybe, their new owners will consider high traffic a profit opportunity, rather than a burdensome nuisance — and seek to attract more drivers by innovation of both toll-collection and road-maintenance... I dunno, it works for supermarkets... Heck, some private (and disgustingly profit-driven) concern may even undertake building a new tunnel (or a bridge)...

        it will always be vastly more efficient for a single entity to install and manage that physical data network, at least at the local level

        Really? Why not? In the 20ie we had competing telephone companies — each running its own wires to buildings. Today Google is laying down its own fiber — to much rejoicing on this very site — and AT&T is planning its own alternative [theverge.com], despite your claims of it being "inefficient". Various markets have competing coax-cable providers [streeteasy.com] already. The actual cable-laying is just a (small) part of providing Internet service... Though in theory a monopoly ought to be easier — and thus cheaper — to operate (in any market), in practice any benefit is quickly consumed by the inevitable arrogance of such providers and the concomitant drop of quality and rising end-user prices (any wins in the monopoly provider's costs are compensated for by their fattening up the profit-margins).

        We should have made this transition decades ago, but for a variety of reasons didn't

        Oh, it is not a "variety" of reasons — but a single one: our government followed that myth of "natural monopolies" [columbia.edu] and granted cable-TV providers monopoly rights [cato.org] in their respective markets. That law was rescinded in the mid-1990ies, but the damage was done...

    • 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).

      I'm hopeful that wireless speeds will continue to increase and become more reliable. If I can connect with my neighbors, and they can connect with their neighbors and so on, we have the beginnings of a decentralised network. The sooner the companies relying on monopolistic control of wired internet access become irrelevant, the better.

    • Only one rule is needed. I believe this rule could be made by the FCC without any new legislation:

      Rule #1: If you fuck with packets, block ports, prioritize any type of traffic over another, or do anything except providing the contracted bandwidth, you may not call your service "Internet". You may not use this word in advertising, in contracts or any communications. We call this "Truth in advertising."

      You will be allowed to use the term An Obnoxious Laughingstock, or its acronym.

  • by gandhi_2 ( 1108023 ) on Tuesday October 14, 2014 @01:02PM (#48141933) Homepage

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

    • by Dega704 ( 1454673 ) on Tuesday October 14, 2014 @01:32PM (#48142247)
      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.
    • by Shatrat ( 855151 ) on Tuesday October 14, 2014 @01:36PM (#48142279)

      I believe this is spot on. I also think that services stuck behind a NAT should not be sold as 'Internet' either. This seems like a perfect stick for the FCC to keep ISPs in line with. Do whatever you want, but if your product is inferior we won't let you advertise it as 'Internet'

      • There exist more people than IPv4 addresses. This means that by your definition, some people just can't be on the IPv4 Internet. Is it honest to call a service that provides routable IPv6 but NATted IPv4 "Internet"?
    • by Ken_g6 ( 775014 )

      And then all the companies will rename their consumer plans, at the very least, "web" or "data" like the mobile companies do. And practically nobody will notice or care.

  • by TechyImmigrant ( 175943 ) on Tuesday October 14, 2014 @01:03PM (#48141957) Homepage Journal

    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.

    • by wkk2 ( 808881 )

      Mail servers can be configured to not offer login unless starttls is used. That should prevent a plain text connection. That still leaves open the issue of mitm with certificates that the client shouldn't trust. Are there any email clients that lock starttls to a specific certificate or warn that the certificate suddenly changed?

      • Mail.app on OS X always warn me about weird certificates. It happens when I'm on a client that tries to inspect SSL packets with stupid MiTM methods.

      • We need the equivalent of HSTS [wikipedia.org] but for SMTP. Maybe it replies with a "250-ALWAYSTLS" to EHLO, and clients and other servers cache the fact that "server foo.example.com always wants TLS". Then those clients can warn users when their messages can't be delivered according to the recipient server's TLS policy.

        This would be so easy if we had DNSSEC or an alternative equivalent, so that you could publish something like an MX record but with added content like "always use an encrypted connection" (perhaps replacin

  • by Reverant ( 581129 ) on Tuesday October 14, 2014 @01:26PM (#48142193) Homepage
    Vodafone here in Europe is also blocking TLS when sending emails through their broadband services. They do so only when port 25 is used; they don't in other cases. My theory is that they want to be able to scan the emails for viruses and/or spam, and block the connection/notify the customer to avoid unpleasant bill suprises. At least that's what my optimistic POV wants to see.
  • Comment removed (Score:5, Interesting)

    by account_deleted ( 4530225 ) on Tuesday October 14, 2014 @01:31PM (#48142233)
    Comment removed based on user account deletion
  • by Dredd13 ( 14750 ) <dredd@megacity.org> on Tuesday October 14, 2014 @01:32PM (#48142249) Homepage

    When the original article cites as its first example of network tinkering the already thoroughly debunked "faster Netflix through my VPN" video, the level of technical credibility to the article is already set at "abysmal". There's no argument that the VPN tunnel was faster (obviously), but the alleged reason (which many sites, including this fine establishment, got on the bandwagon for, even though they should know better) was horseshit.

    Second, the article demonstrates the problem with a connection to tcp/25. Unless the customer is running a mail *server* on their residential ISP line, they should be connecting to tcp/587. The wireless provider in question here is absolutely within their bounds to say "they don't want you running an SMTP MTA on the wifi", but that running a normal MUA is fine. Is there any evidence that this problem also exists for connections to tcp/587?

    • When the original article cites as its first example of network tinkering the already thoroughly debunked "faster Netflix through my VPN" video, the level of technical credibility to the article is already set at "abysmal". There's no argument that the VPN tunnel was faster (obviously), but the alleged reason (which many sites, including this fine establishment, got on the bandwagon for, even though they should know better) was horseshit.

      It's really quite simple. If you have a download speed topping out far lower than your maximum and you then connect through a VPN and get more available bandwidth then there is a rabbit away somewhere. Netflix have already now paid up anyway to get rid of this 'issue' for their users, so that debunks this bit of dog shit.

      Second, the article demonstrates the problem with a connection to tcp/25. Unless the customer is running a mail *server* on their residential ISP line, they should be connecting to tcp/587. The wireless provider in question here is absolutely within their bounds to say "they don't want you running an SMTP MTA on the wifi", but that running a normal MUA is fine. Is there any evidence that this problem also exists for connections to tcp/587?

      Connecting to something on port 25 and allowing inbound connections to something you have running on port 25 are two entirely different things. If you don't know that then you really don't

      • by Dredd13 ( 14750 )

        It's really quite simple. If you have a download speed topping out far lower than your maximum and you then connect through a VPN and get more available bandwidth then there is a rabbit away somewhere. Netflix have already now paid up anyway to get rid of this 'issue' for their users, so that debunks this bit of dog shit.

        It means you've routed out your ISP through a peering point that isn't Level3, and that the peering point between your VPN provider and L3 is less saturated than your ISPs. That's all it pr

      • You have no idea how the Internet works. It's not a LAN.
        No AS connects to every other AS. For any ISP, you can find a VPN that is going to have better connectivity to *some* AS (higher speeds).
        It's ok that you're ignorant, but you should at least recognize it and not try to speak as if you know what you're talking about.
  • Cisco ASA (Score:5, Informative)

    by backtick ( 2376 ) on Tuesday October 14, 2014 @01:37PM (#48142285) Homepage Journal

    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.

    • by Anonymous Coward

      I'm glad someone beat me to it. As soon as I saw the banner, in the article, I said 'Cisco SMTP fixup strikes again'.

      This is folks attributing to malice what is really incompetence. Cisco turns SMTP fixup on by default, and it breaks ESMTP (I'm not sure if it's still true, more recent code versions may have finally done the sane thing and turned it off by default, but it's obviously turned on by the wireless ISP in Golden Frog's example).

      This is a total non-story

    • Re:Cisco ASA (Score:5, Interesting)

      by eth1 ( 94901 ) on Tuesday October 14, 2014 @02:10PM (#48142575)

      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.

      • by rwyoder ( 759998 )

        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.

        Groan.
        At a former job we were having mysterious DNS problems.
        I finally discovered an ASA was the problem.
        The boneheaded thing was defaulting to dropping any DNS packet with the EDNS0 option enabled.
        EDNS0 had been around for *five* years, and we were running the latest firmware.
        If a fw vendor can't be bothered to keep up with the protocol standards, they shouldn't be interfering with the application layer.

    • Re:Cisco ASA (Score:5, Insightful)

      by segedunum ( 883035 ) on Tuesday October 14, 2014 @02:35PM (#48142821)
      I can't mod you up any further, but yer, you're spot on. This is actually the default behaviour of a lot of routers. It might look like malice but in this case it could very well be complete laziness and a lack of awareness. Typical ISP in other words.
  • by kevmatic ( 1133523 ) on Tuesday October 14, 2014 @01:58PM (#48142471)

    It used to be that my sister couldn't connect to Efnet using her 4g on her phone. I helped her bypass it by finding a server with SSL support and encrypting the connection to Efnet.

    A few months ago, this quit working too. I was puzzled- how did Verizon know it was IRC traffic? The port was a standard HTTP port...

    She found that turning SSL back OFF made the problem go away- she can get on IRC just fine now. It seems they no longer block IRC but block SSL? I didn't really investigate further, but this seems to explain it.

  • by Drakonblayde ( 871676 ) on Tuesday October 14, 2014 @02:11PM (#48142591)

    Is that techdirt did virtually no research on the issue, they just passed along what Golden Frog said in their filing.

    Which brings me to the *really* scary part.

    A company which provides VPN service should reasonably expect to have a clue when it comes to network operations.

    Not only did this company not have the chops to figure out that 'someone may have incorrectly configured a firewall!', oh no. They decided to compound their inadequacy by including it in a filing to the god damn FCC.

    So many levels of failure involved in this.

    • Not only did this company not have the chops to figure out that 'someone may have incorrectly configured a firewall!', oh no. They decided to compound their inadequacy by including it in a filing to the god damn FCC.

      Yes, they should be experts in gear they may not themselves be using. They should also not complain to the government office responsible for receiving complaints about such things, because ISPs always do such things as honest mistakes and not as predatory rent seekers.

  • Common firewalls do exactly what was described in a default configuration.

    I'm not saying the ISP couldn't be doing it intentionally, but it's not valid as an automatic conclusion without confirmation.

    There's a firewall on one end or the other manipulating traffic.

    ISPs commonly block or filter port 25 as a spam prevention measure.

    It's not a network neutrality violation, because the port is blocked regardless of what app or service is using it.

    Also, you can likely use port 587 and it will probably work

  • This article is full of hyperbole

    This is scary. If ISPs are actively trying to block the use of encryption, it shows how they might seek to block the use of VPNs and other important security protection measures, leaving all of us less safe.

    This article and the write up are misrepresenting what's happening. You're trying to talk to an SMTP server, not the whole Internet. For some reason the SMTP server isn't supporting STARTTLS which is dumb, stupid and down right naive. They don't mention which broadband carrier but it would be nice to know so we could all do a Nelson and go "ha! ha!" The simple answer is allow them to fix their problem or just use another SMTP service that respects your transmission priva

    • by Qzukk ( 229616 )

      For some reason the SMTP server isn't supporting STARTTLS which is dumb, stupid and down right naive

      The SMTP server supports XXXXXXXX just fine. It's just that mysteriously whenever you send the XXXXXXXX command through this particular ISP, it replaces the XXXXXXXX command with X characters before the server receives the packet.

      This is a standard feature of Cisco gear (I had a PIX back in the early '00s that had this on by default), though I've never had a good explanation as to why. I definitely have no

      • it says " ISPs violating net neutrality to block encryption." It's t-mobs smtp services on t-mobs network, was this happening to GMAIL and Yahoo or any other SMTP services using the same network? No? Then this whole article is FUD. You suspect t-mobile but if it's not why not identify the culprit in the article so we can say that this is fucked up or just plain misconfiguration?

        • by Qzukk ( 229616 )

          was this happening to GMAIL and Yahoo or any other SMTP services using the same network? No?

          I've never seen an ISP with a mailserver apps.______.com? (I suppose if you were right and it only affected the ISPs own server, that hostname alone could help identify the company involved)

          My T-Mobile UK link clearly indicated that T-Mobile UK had been doing it to every SMTP server:

          "This isn't just for my mail server, I experienced the same problems using smtp.gmail.com as well," said Cardwell.

          and additiona

          • Well Cardwell also complained about this back in 2012 as well. http://www.zdnet.com/t-mobile-... [zdnet.com] So it seems that t-Mobile UK is the culprit here and should be thoroughly smacked upside the head. The article I linked indicated that they do this for "contractual" and "Fair-use" reasons. It's stupid so I'd find another carrier.

  • If you have problems with your local internet (or cable) service provider, there is only one correct audience for your complaint. Competition is regulated LOCALLY, just like wars are handled NATIONALLY and family budgeting is a DOMESTIC issue. The FCC advises at https://www.fcc.gov/guides/cab [fcc.gov]... to direct complaints to local franchising authorities.

    For example, with Comcast, they are required to plainly put this contact information on your bill. See for example this bill http://comcastbills.com/Compar [comcastbills.com]... Th

A morsel of genuine history is a thing so rare as to be always valuable. -- Thomas Jefferson

Working...