back to article ISPs are stripping encryption from netizens' email – EFF

Some ISPs are removing encryption from customers' connections to email servers – threatening the privacy of their communications – claims civil-liberties group the Electronic Frontier Foundation. Incidents in the US and Thailand over recent months have seen service providers intercepting their customers' data to strip a …

  1. Mark 85

    One does wonder... or at least should wonder.

    Is it laziness or incompetence that the ISP's do this? Or something more sinister?

    1. Anonymous Coward
      Anonymous Coward

      Re: One does wonder... or at least should wonder.

      Do you really have to guess?

    2. mw22

      Re: One does wonder... or at least should wonder.

      Not as black-and-white as it seems.

      What the ISP's are more than likely actually doing is intercepting and then sending on the email. If you loom at the headers from one of these messages you more than likely wont see the IP of the server that's actually been configured in the mail client. Outbound mail will go from client to their ISP then onto recipient server.

      This (because of the way spam blacklists work is actually a good thing). It centralizes all mail out from their network, allows the ISP to block spam and prevents their IP's from being blacklisted. It ensures that other customers of the ISP can send mail without blacklist bounce backs. ISP's will have 1000's of users infected with malware that are part of a botnet sending spam. This prevents that.

      This is not a huge problem for clear text emails, aside from the fact that there will be no record of the email on whatever sending mail server the client is configured to use, but when TLS is used you hit a problem.

      The intercepting server at the ISP cannot use TLS, because the client will typically be configured to connect to a specific hostname, which will have a specific SSL cert, which the intercepting server cannot fake.

      ISP's need to protect their IP ranges from blacklisting, but if clients can connect to any server and issue STARTTLS then the ISP connot intercept spam.

      What is needed is a way to differentiate between mail being submitted to a sending server, and mail being submitted to the MX of the recipient server. This is not a simple problem to solve.

      Typically, mail going to via a sending server will use SMTP AUTH but if I remember my SMTP correctly when STARTTLS is used SMTP AUTH takes place after the connection is encrypted so there is no way for the ISP to tell.

      Something like using port 587 to the sending server (as the recipient MX typically won't be listening on this) may be an option, but you'd then need to start issuing errors to all clients that tried to use STARTTLS on port 25 rather than actually accepting and sending on the email...

      Something needs to change, it could be the protocol spec to somehow differentiate the emails to sending servers from ones to recipient servers (how is far from clear though - you don't want auth going on before STARTTLS...) or this could be the first step in the death of blacklists if everything moves to encryption... But the current state seems more like an attempt to protect customers and minimise support calls than anything malicious...

      1. Shannon Jacobs

        Re: One does wonder... or at least should wonder.

        Stopping spam is a piss poor excuse, but considering the poverty of the EFF, maybe it's as good a reason as any?

        If the ISPs and email providers actually wanted to greatly reduce the spam, then they would go after the spammers' business models. Hint: Filtering is now just a minor cost in the spammers' business models. The main effect of filtering is to increase the value of the spam that slips through. "Hey, this must be a REAL Nigerian prince if the email didn't get filtered!"

        Tired of flogging the dead horse, but one more time. The big email providers should provide better anti-spammer tools so volunteers could help break the spammers' business models. We should have the tools to attack ALL of the spammers infrastructure, pursue ALL of the spammers' accomplices, and protect and defend ALL of the spammers' victims. Not just the suckers who feed the spammers' scams, but even the corporate victims whose reputations and customers are victimized.

        Arbitrary example that Gmail could offer, if they wanted to. Imagine a "Fight spam" button that would analyze the spam and ask you about the email addresses in it. If you identified the address as a probable spammer dropbox, then it should be blocked before the spammer can get any sucker replies. Obviously Gmail can nuke their own dropboxes, but they can even deal with remote dropboxes in a very simple way. They can measure how long the dropbox exists, and if that provider is too slow in responding, well then the google could just slow down the email. (Actually in keeping with their increasing EVIL these days.) Small email provider can't provide 24/7 support? No problem. Google could provide an admin for that purpose with detailed reports on any actions taken and why.

        1. Charles 9

          Re: One does wonder... or at least should wonder.

          "If the ISPs and email providers actually wanted to greatly reduce the spam, then they would go after the spammers' business models."

          How do they do that when many spammers are now employing botnets to make their e-mails look like they're coming from someone else. IOW, how do you trace the botmaster? Especially if they're based in a hostile country?

        2. ecofeco Silver badge

          Re: One does wonder... or at least should wonder.

          "Arbitrary example that Gmail could offer, if they wanted to. Imagine a "Fight spam" button that would analyze the spam and ask you about the email addresses in it. If you identified the address as a probable spammer dropbox, then it should be blocked before the spammer can get any sucker replies"

          They already do. There is button right at the top with an octagon and an exclamation mark that is for reporting spam. In its benign mode, it flags all future email of that type and puts in the spam folder. In its more advanced mode, it even offers an unscribe button and a very large warning that the email may be malicious.

          It works quite well.

        3. Anonymous Coward
          Anonymous Coward

          Re: One does wonder... or at least should wonder.

          AFAIK, Google already uses user feedback to feed its spam filters, and to be honest this works quite well most of the time. I see very little spam in my Gmail inbox.

          The problem with proactive destination blocking is that too many false positives will soon become very painful for Google and its users. Having already managed and dealt with blacklisted email servers, I often wonder why anyone would still want to run their own corporate email server, unless they absolutely had to for security or insurance reasons. Commercial cloud based SaaS email solutions shift a lot of the security and maintenance burden directly to the service provider for a relatively small cost. And they don't prevent customers from using their own end-to-end encryption solutions for extra email security.

      2. P. Lee

        Re: One does wonder... or at least should wonder.

        Most people running email clients will be forwarding to their ISP email servers anyway, not running SMTP servers which connect directly to the destination SMTP server. If they are running direct to end-points, its a VPN and the ISP should stay out of the conversation.

    3. Fatman

      Re: One does wonder... or at least should wonder.

      Or something more sinister?

      One could suppose that it may have something to do with governments and their attempts to spy upon internet users.

  2. M Gale

    Time to do it all in the client then?

    Can't exactly "strip encryption" easily when the only thing the ISP gets is uy&*5r*%76f*^%fIYTFR8I&TFi78%^FI&6r(I&^tf*(^ri7R8765rUI%E7£7%^FikY&^TGFjytgcvKU<yg.....

    1. Preston Munchensonton

      Re: Time to do it all in the client then?

      Protecting the application payload is fine and dandy, but you may want to read the discuss on page 2 about the lack of protection for metadata/header info unless using TLS with SMTP.

    2. DNTP

      Re: Time to do it all in the client then?

      Well you see anything like that which the ISP can only see as gibberish they obviously can't resell to advertising partners. So there is no profit motive for them to pass on that message, therefore it must be spam. It's your duty as a customer to generate a profitable content profile for the people that you pay stupid amounts of money to, don't you know.

  3. Gordon 10

    Pedant alert

    It's more a case of the isp's not applying encryption in the first place than stripping existing encryption.

    The flag is what's getting stripped but that's not encrypted in the first place.

    1. Velv

      Re: Pedant alert

      No, it's more a case of ISPs deliberately preventing an encrypted channel from being formed between the two servers so that the subsequent communication is unencrypted.

  4. ZSn

    Never recommended

    I looked in STARTTLS a while ago, and the advice even then was: 'don't'. A lot of clients setting up STARTTLS fall back to unencrypted silently on errors so you don't know that you're at risk. The advice was that to use explicit TLS on the relevant ports (993 etc). While the actually stripping by the ISP is deplorable the issues with STARTTLS were already known.

  5. foxyshadis

    Given that most client-facing services that use STARTTLS (or POP/IMAP/SMTP in general, these days) require some random other port anyway, it isn't really that transparent to the client. It's more of a bolt-on for lazy server admins, not clients, and it's the businesses that should move to connection-based TLS instead.

    It seems odd to argue to drop it for PGP, since they each mitigate completely different attacks.

  6. Matt Piechota

    I'm rather confused by this article, mainly from the lack of details. Are they saying that ISPs are truly stripping the connection as it goes through (as in modifying the packets to force STARTTLS to fail), or the much more "normal" situation where you can ensure the connection between you and your ISP's SMTP gateway all you like, but that gateway is free to turn around and send that data to the destination mail server in the clear? It's very odd to think of STARTTLS as "encrypting email" since all it's doing is encryption the channel.

    1. Dan 55 Silver badge

      The paper indicates the ISP replaces the string STARTTLS with XXXXXXXA in the server's EHLO capabilities list so the client might decide to abort the connection because it thinks the server can't do STARTTLS or continue the connection but without encryption.

      Any STARTTLS command sent by the client to destination server is also fiddled with so the server doesn't understand it.

      This goes for any SMTP server, not just the ISP's mail gateway.

      Seems like a lot of trouble to go through to save on support calls when it could make the client drop the connection with an error. I'm going to go with malice on this one.

  7. Anonymous Coward


    I was always taught that email is about as secure as sending a postcard - every one who wants to can read it along the way.

    1. Nuno trancoso

      Re: Meh!!

      Not quite, and the point being made.

      TLS would protect you from sniffing in transport, you don't get assurances from sniffing at the endpoint. PGP (or any other form of content encryption) will protect your content from both transport and endpoint sniffing, but leaves the metadata in the clear.

      Still, as far as i'm concerned, content encryption is really the only way to go. Endpoints already proven to be less than concerned about end user privacy, and they are even required to "play ball" with the powers that be in certain places. Most of them bastions of "democracy and civil rights". Yeah right...

      Worst case scenario with content encryption is that said powers that be get to know who sent something to whom. Subject can be total nonsense as far as you think of it.

      Maybe it's time to bring back the 1990's (80's?) "terrorist/plane/bomb/whatever" email junk content till they give up the ghost. Make so much noise that any signal you might extract is so costly it's unsustainable.

      1. tom dial Silver badge

        Re: Meh!!

        It is true that various democratic governments require production of metadata under various circumstances, and may take notice if you encrypt the body (and, of course, the true subject). Numerous others, arguably less democratic, restrict encryption to government approved methods, require government issued licenses to use it, or forbid it completely. Those governments almost certainly also collect the metadata.

    2. Anonymous Coward
      Anonymous Coward

      Re: Meh!!

      You have the correct attitude. Given the routes that packets can take, one should never make a presumption of confidentiality.

  8. Anonymous Coward
    Anonymous Coward

    S/MIME or PGP

    Advising its use is all well and good but I've found it a pain in the arse to implement with no end of problems in Thunderbird with Enigmail. Seems to always complain about something or other and prevent the simple click to send.

    1. ZSn

      Re: S/MIME or PGP

      Funny enough I find Enigmail remarkably easy to use with Thunderbird. However I'm using it on Linux, perhaps you're using it on windows? The only issue I sometimes have is that I have multiple accounts with their own PGP and s/mime certificates, and with S/MIME it very occasionally signs an E_mail with the wrong certificate.

      1. Mark 65

        Re: S/MIME or PGP

        I think this only serves to highlight the point though - it simply isn't at the straightforward, easy to use, and reliable level that you'd want it to be. Hence all our emails are no longer ours.

  9. choleric

    Google has been using STARTTLS on its servers since Gmail was launched. Which was in 2004 not 2013. And unless the channel is secure it won't allow you to login, thereby preserving the secrecy of your password.

    Also, most well run email servers refuse to accept email from residential broadband IP addresses, and some ISPs block outgoing TCP port 25 altogether, so I'm not entirely sure what the fuss is all about here. There are only a very limited number of situations in which this "attack" is actually viable.

    Which leads me to ask: what were they after?

    1. Synonymous Howard


      In my experience of running a mail server on my own home broadband connection for over 10 years is that the only mail servers which actively refuse connections are the ones for … so no great loss there (although my transport config routes those via my ISP instead).

      But it would really not surprising me if some ISPs are using their deep packet inspection technologies (which they use for traffic shaping and QoS) to dynamically alter SMTP traffic to strip out capabilities from server responses (mine probably does not based on my evidence) or force all web traffic through their own proxy servers (if mine is doing that then it is configured not to add any Proxy headers).

      I agree with the EFF though … use TLS/SSL whenever possible but also consider SMIME/PGPing the content. I've worked with x509v3 certs for over 10 years and it is still a pig to get software clients to use them properly or easily.

  10. msknight

    I'm affected by this

    My ISP for my e-mail is in the US. I'm in the UK. I had to remove StartTLS from my e-mail negotiation packets a few weeks ago. Haven't got to the bottom of it yet ... and until I do, I'm not naming anyone until I've got facts to back it up with ... but I'm not a happy bunny, I can tell you that much.

  11. JimmyPage Silver badge

    Sigh, kids again ?

    If anyone is *relying* on the STARTTLS to provide encryption, then they are (a) thick, or (b) so young as to not know the history of email systems and how a lot of features are optionally-supported extensions to the RFCs.

    For myself, if I didn't encrypt it, then it's not encrypted, and would have been treated as such in terms of content.

  12. Anonymous Coward
    Anonymous Coward

    STARTTLS is broken

    This shows exactly why you should use good old fashion way of doing e-mail connection encryption than this newer STARTTLS nonsense that IETF is pushing. Namely, for sending use port 465 (SMTPS), for reading use 995 (for POP3S) or 993 (for IMAPS).

    And yeah, I know that most of those ports are considered "deprecated" but it still doesn't take away the fact that it works better than this STARTTLS bullshit.

    Optional encryption (STARTTLS) was a totally brain-dead idea from the beginning and even IETF knows this. Take a look of "9. Security Considerations" from

    It clearly shows that MTM is possible with STARTTLS and this is exactly whats happened here!

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like