13 ms·

ISPs Removing Their Customers' Email Encryption

333 points by erkose 12y ago

eksith 12y ago
Before the conspiracy theories start, I think this has less to do with mass-surveillance and more to do with stopping spam. As hinted : "Some firewalls, including Cisco's PIX/ASA firewall do this in order to monitor for spam originating from within their network and prevent it from being sent." When faced with a large volume, companies usually aim for the quickest fix in lieu of the best. And I couldn't help notice the bigger problem here : "Adoption of PGP has been slow because of its highly technical interface and difficult key management." When non-technical people are involved, the number of technical people who dismiss or downlplay this offhand is getting annoying. In fact, just the other day, the replies to this : https://twitter.com/SwiftOnSecurity/status/530818824036040704 https://twitter.com/SwiftOnSecurity/status/53081882403604070... Surely, there's a simpler way to manage keys and send/receive encrypted email with PGP or something better?
- leeoniya 12y ago
  you don't need conspiracy theories to put forth that disabling encryption (for whatever reason) enables dragnet/any surveillance by whichever parties have access to the transmission medium. the NSA will be happy to collect your unencrypted data regardless of whether they had any part in disabling the encryption.
- revelation 12y ago
  No conspiracy theories here, just utterly baffled at the fact that a communications provider would happily tamper with user data that he has zero reason (and technical justification) to access or change. And then to strip STARTTLS? That's the nuclear meltdown scenario of incompetence and recklessness. I guess this is another moment where people can tell us how theres too much regulation governing internet providers, after apparently a vast majority of providers can't even deliver payload unchanged. It must be tedious to keep defending an industry that can't provide the most basic of services.
  - rakoo 12y ago
    He just told you there _is_ a reason to do this: stop said ISP's users from sending spam. In the best case scenario, the ISP analyzes each email and drop them when their spamminess is too high. That's a legitimate concern for the ISP. Now _of course_ doing this will be a massive problem for privacy, but again, user's privacy comes after a functioning network for the ISP.
    - couchand 12y ago
      I'd argue that spammy e-mails are fine as long as you don't send too many of them. That's easy enough to track without breaking encryption. But it also makes it difficult to distinguish the officially "non-spam" yet still awfully spammy marketing automation that makes the ISPs boatloads of money, so I can see their tradeoff.
      - cm2187 12y ago
        I find these attacks outrageous and an absolute disdain for the protection of their customers but I wouldn't go as far as justifying spam. To be honest I am less shocked by the fact that the ISP do this than by the fact that it is even possible. Email is broken in so many levels.
    - revelation 12y ago
      It's not the job of the ISP to do that. Full stop.
- josho 12y ago
  This is the lamest approach to fighting spam. A better approach is for the ISP to block outgoing port 25 from their network, and force their users to use their mail relay that requires authorization. Any accounts that are caught spamming can then simply be terminated as customers. This approach is also quite common.
  - bsder 12y ago
    This is the lamest approach to network security. Now I can't reach MY email server which sits in a colo on port 25. So, now I have to put my mail server on port 80 just so I can get out of the network. Some of us don't trust the email servers run by the ISP.
    - brongondwana 12y ago
      https://www.ietf.org/rfc/rfc2476.txt https://www.ietf.org/rfc/rfc2476.txt December 1998 It's hardly your ISP's fault that you are 16 years behind best practice.
      - nitrogen 12y ago
        https://www.ietf.org/rfc/rfc2476.txt https://www.ietf.org/rfc/rfc2476.txt December 1998 It's hardly your ISP's fault that you are 16 years behind best practice. Could you be so kind as to point to the relevant section of RFC2476?
        tedunangst 12y ago
        > Port 587 is reserved for email message submission as specified in this document.
      - bsder 12y ago
        It is my ISP's fault for BLOCKING THOSE PORTS. And, since I don't really have a choice of ISP, I can't change that. Some of us live in the real world where we wind up having to do things like put mail servers on port 80 or 25 because that port doesn't get blocked. Thanks for playing.
- higherpurpose 12y ago
  Why would I want that if I have Gmail? Also I wouldn't trust Cisco's arguments in such situations. Cisco is the one that invented "lawful intercept"/backdoors in routers.
- devicenull 12y ago
  This is also the default behavior for ASAs, so it's really just not bothering to configure them. Probably because email works, so why screw with it?
- drdaeman 12y ago
  Sorry, but I honestly believe that "oh PGP is so hard for non techies, but those evil technical people ignore this important issue" is a myth. Unless we're talking about command-line gpg application, hah. Take Enigmail for example. It's nearly as non-technical as possible, with key IDs being the only "technical" thing that's visible in the key list. Key generation just asks you for account to use and expiry date. Encryption is a single checkbox. And the rest of the features are mostly behind "Advanced..." buttons and aren't necessary for the most basic operation. If you insist on the contrary, please do some concrete examples where it's a "highly technical interface". There are a lot of issues with PGP adoption, yet most important are two: 1) popular MUA developers just don't give a fuck about crypto 2) too many users use webmail where PGP support is generally a kludge at best 3) "noone does that anyway so why bother" attitude. The other issues are too minor compared to those three.
  - toyg 12y ago
    Item 2 I think is the real killer. Nobody "normal" even uses MUAs anymore; GMail effectively killed that world. They use Outlook at work, where the configuration is up to their system administrator so they don't have to know anything, and then they go home and use GMail and again it's literally zero config. Back in the 90s, when people were actually setting up MUAs at home, they had to know about options etc; at that time, crypto was a bit difficult to implement and servers didn't really support it anyway, but still there was a slim chance that users would actually have to bother looking at "email preferences". That window is over. Now nobody knows anything about email and they are not expected to, so there is no chance they'll ever get to that finally-mature Enigmail screen.
    - drdaeman 12y ago
      <rant> 2 boils down to issue 1 and is blocked by issue 3. Web-based MUAs are still software. They could support PGP and/or S/MIME just fine. All what's necessary is to provide an API and browser plugin (so the website won't have _any_ access to plaintexts and keys) implementation. Like some sort of secure <textarea> that's completely out of website's control (except for basic visual styling and some hinting like what's to show as recipient selection) and only sends an event when writing's done and encrypted message is ready. Not trivial, but well possible. Given that Google is also a browser vendor and it's not unusual to them to push for features based on their product demands - certainly possible. But, nope. No big player on the market seem to care about providing user with proper cryptographic protection. The one with user in actual control instead of "oh, crypto's scary and we won't allow you to be scared - we'll manage everything for you, trust us, we'll handle your data good". Just look at the state of X.509 certificate management in any browser or email client - contrary to most PGP plugins, it's real obscure highly technical UI hidden beneath 4-6 mouse clicks, that hadn't any significant changes since '90s. So, we're still stuck with passwords instead of certificates. And S/MIME failed. And that's because most don't care any much (if at any) about the issue and even if they do they seem to be perfectly satisfied with "your communications are secure with bank-grade encryption blah blah blah"-type marketing speak. </rant>
delinka 12y ago
"...the flag indicating that a server supports STARTTLS is not itself encrypted..." I'm thinking signatures would have been a nice start.
- deleted 12y ago
  [deleted]
- brongondwana 12y ago
  Exactly. This fuzzy thinking in security is really frustrating me with the supposed security experts talking in this space. I was at Inbox Love a couple of weeks ago, listening to Ladar Levison talking about security, and he gave an example which conflated encryption with digital signatures, saying that the lack of encryption in his incoming email would allow people to send him executables which were unknown viruses. I actually raised my hand and said "surely digital signatures confirming the sender are really what's needed" and he replied that if it was encrypted, the MITM wouldn't know what was being sent to modify it. For real. As if the attacker can't just replace the whole email with something else encrypted to your public key and containing a virus. I lost a lot of respect for his security credentials in that moment, and I've lost a lot of respect for the EFF reading this posting. Not a _single_ mention of password theft, which is by far the highest risk to most users of having STARTTLS stripped. The ability for their email to be read over the backbone is bad, but the ability for hackers to get into their email and randomly delete or modify it is far more insidious. (plus the ability to use the email account to trigger password resets on third party services and all sorts of other exciting stuff you can do once you own somebody's email account)
  - throwawayaway 12y ago
    You know what you are right. I've bookmarked your post. I think you should make a "Applications" style blog post and submit it.
feld 12y ago
Easy solution: don't permit STARTTLS. Only allow email clients to connect over 993 and 465 using end to end SSL. That's what Fastmail does and I now understand why.
- spindritf 12y ago
  You're thinking of end clients. This is server to server communication and Fastmail supports STARTTLS of course. $ dig mx fastmail.com +short 10 in1-smtp.messagingengine.com. 20 in2-smtp.messagingengine.com. $ telnet in2-smtp.messagingengine.com. 25 Trying 82.221.106.241... Connected to in2-smtp.messagingengine.com. Escape character is '^]'. 220 tlxc1.messagingengine.com ESMTP . No UCE permitted. ehlo my.hostname 250-tlxc1.messagingengine.com 250-PIPELINING 250-SIZE 73000000 250-STARTTLS 250-ENHANCEDSTATUSCODES 250 8BITMIME
  - kijin 12y ago
    The article is about end clients on residential and/or business lines. There is no reason for client-to-server communication to rely on STARTTLS on port 25.
    - zurn 12y ago
      There's also no reason to discount server-to-server SMTP on residential or business lines. Especially since this is part of the larger net neutrality discussion.
      - feld 12y ago
        I worked at an ISP and no, net neutrality aside, SMTP on residential is bad bad bad. It should be permitted only at the customer's request, but probably won't fix the fact that their subnet is on a global spam blacklist.
        zurn 12y ago
        The point of NN is that the ISP shouldn't get to make that decision. Even "allow on request" is very problematic because it's a slippery slope. Many people run SMTP at home mostly to receive mail, because the ISP is legally obligated to retain mail logs for law enforcement etc. (EU data retention law)
josho 12y ago
Why is mail so broken? We send so much confidential information over email, yet have no reliable way to secure the information. We insist on https, so why are we ok with the current lame security around mail? Folks go out and get S/MIME setup, it's not ideal, but a start at least.
- atmosx 12y ago
  I'm no expert but it's most likely that like FTP, SMTP was NOT designed for the internet. It was designed for LANs or MANs. Security was not one of the core features. Same goes with many old protocols... But that's expected the drama is when new protocols are designed with the same flaws.
  - josho 12y ago
    Yup, I get that. Same can be said of http--so we solved that problem and created https. I just don't get why folks like IBM, Microsoft, et al never bothered to push secure email standards. I'm surprised their customers never pushed them to do it. SMTP with starttls is not secure because as an end user I have no idea if my mail is getting sent securely.
    - throwawayaway 12y ago
      You have to go back to the export controls thing in the nineties to understand that: http://www.ussrback.com/crypto/nsa/lotus.notes.nsa.backdoor.txt http://www.ussrback.com/crypto/nsa/lotus.notes.nsa.backdoor....
- dredmorbius 12y ago
  There were people thinking about security in the 1970s, but the proposals were quashed. A comment from this past August from Karl Auerbach, who was there: I worked on TCP/IP security systems back in the 1970's. In fact one of the threads that led to IP being peeled off from the then monolithic TCP was done on my blackboard at SDC in 1974. The reason we did that was to insert a security/encryption protocol over the packet layer - if it sounds like DNSSEC it should. But in 1974. But it was on a project done for "the government" so it never saw the public light of day. And: We made a huge mistake back in the 1970s when we failed to require a mandatory packet security layer between IP and the protocols over it. (We knew even then that we needed it - and had existence proofs of running code - but the gov't wouldn't let those who knew out into the wild to evangelize the concept. So in some sense the problem we have today is do to excessive closure by certain governmental authorities. Even today I am not at all sure what I can say about this stuff. (He's still under some security prohbitions). https://plus.google.com/106435630686948313794/posts/i4KmivYfXrN https://plus.google.com/106435630686948313794/posts/i4KmivYf...
Someone1234 12y ago
Unfortunately STARTTLS is broken beyond repair. STARTTLS is sent via the unprotected SMTP channel. The biggest problem with this isn't the lack of encryption, but more the lack of MitM protections. Imagine if when you wanted to connect to your bank over HTTPS you first had to send a HTTP request which asks permission to "upgrade" to HTTPS. Obviously any bad guy worth their salt is going to intercept that unprotected HTTP traffic, strip out the STARTTLS, and then leave you using the HTTP channel they can monitor or alter. So while, yes, in this case ISPs are likely "MitM"-ing their own traffic (which by definition isn't a MitM), it still leaves you open to bad guys on your side of the connection (e.g. the insecure WiFi problem). But even if ISPs weren't someone else could be.
- spindritf 12y ago
  Imagine if when you wanted to connect to your bank over HTTPS you first had to send a HTTP request which asks permission to "upgrade" to HTTPS. This actually happens a lot. Most people most of the time don't painstakingly type in h-t-t-p-s-:-/-/... but rather just the domain name and the server on the other end returns a (plaintext) redirect to https. Which is why sslstrip works so well. Sure, we have bookmarks, HSTS, tell people to look for a lock icon in the address bar but it's far from being a solved problem.
  - iancarroll 12y ago
    HSTS preloads fixes this problem on modern browsers. Google literally has a site where you can add your site to Chrome's list (which Mozilla clones) in a few weeks. If you're using other browsers, the problem still exists but a large majority is covered by this.
    - dublinben 12y ago
      There's only 500 sites on that list. None of the largest banks in the US are even included. This problem is hardly solved.
      - iancarroll 12y ago
plg 12y ago
i can haz gnupg?
- chuso 12y ago
  AFAIK, GnuPG and S/MIME only encrypt message body, but not its headers such as sender, receipt, date, subject, ...
  - plg 12y ago
    Yes that's true
    - riking 12y ago
      ... email account passwords ...
higherpurpose 12y ago
Ok, maybe I can live with the excuse that NSA is forcing the carriers' hands at giving them data, but actively helping NSA break people's encryption? What the hell.
- eli 12y ago
  NSA?
- hadoukenio 12y ago
  Yeah, this smells like it was by design.
willvarfar 12y ago
If, say, Thunderbird is configured to use STARTTLS to talk to the IMAP and SMTP servers, can this attack strip it or will Thunderbird refuse to connect to an unencrypted server?
- asutherland 12y ago
  In very old versions of Thunderbird (pre-mercurial), there was an option akin to "TLS, if available" which would be vulnerable. But Thunderbird has not offered it as an option for new accounts for quite some time.
iolsantr 12y ago
At least nobody thinks MITM attacks are only of concern to big corps, militaries and paranoiacs now.
- cm2187 12y ago
  And with mobile and wifi everywhere this is even likely to become a direct annoyance for consumers
kijin 12y ago
This is why I never use STARTTLS on port 25 or 587 when connecting to my mail server. For me, it's 465 or GTFO. I understand the need for backward compatibility in server-to-server mail transport, but there is absolutely no need for client-to-server mail submission to rely on a hack like STARTTLS. Whoever decided to deprecate STMPS on port 465 made a big mistake. That was back in 1998, when most people didn't fully grasp the dangers of unencrypted communication. I think SMTPS should be reinstated as a standard for mail submission, and mail services should stop encouraging their customers to move to STARTTLS. That way, you won't have to worry about your mail client's undocumented behavior when a STARTTLS negotiation fails.
- mike-cardwell 12y ago
  I'm not aware of any mail clients which (when configured to use encryption), will downgrade to not use encryption for any particular reason, when using mail submission port 587. If you are, tell us what they are so we can issue bug reports. If you can't, then what the hell are you talking about?
  - kijin 12y ago
    > what the hell are you talking about? Old example: https://news.ycombinator.com/item?id=8593115 https://news.ycombinator.com/item?id=8593115 Current example: K-9 Mail has two options for TLS: "TLS (if available)" and "TLS (always)". If you choose the first option, K-9 will transparently downgrade to unencrypted connections. Even worse, some ISPs will happily instruct users to select the first option if they're having trouble with configuration. For most people, "better compatibility" sounds like a pretty convincing excuse. Which is probably why this stupid option exists in the first place.
    - mike-cardwell 12y ago
      People who configure their clients to use encryption optionally, will find that their clients, use encryption optionally. This is not evidence that 465 is more secure than 587. This is evidence that some clients come with strange options.
G3E9 12y ago
The lack of HTTPS when using Comcast's XFINITY web mail is still beyond me. HTTPS is used when logging in, however everything else after that prompt is over basic HTTP (session IDs, inbox data, message data, contacts list, etc). I do not communicate much with my provided Comcast email, but I know others who tie a lot of services to it. Until Comcast provides standard web security, they endanger their customers as well as whoever else involved (paying Comcast or not). Careful what you share with user@comcast.net.
dangrossman 12y ago
I haven't been able to send e-mails when connected to T-Mobile for, oh, a year at least? My e-mail provider (Rackspace) only supports STARTTLS and SSL/TLS, and T-Mobile appears to break the authentication no matter which I choose. I can receive e-mail, but not send it on 465 or 993. As soon as I get home and switch to wifi, everything in my outbox gets sent. It's mighty annoying.
- rahimnathwani 12y ago
  993 is for IMAP, not SMTP. Try 587.
  - dangrossman 12y ago
    My mistake, just a typo. The app fills in the port itself depending on what authentication mode is chosen. It's 465/587.
- junto 12y ago
  I wasted a bit of time yesterday trying to get a .NET application to send email using SSL/TLS via Rackspace. It turns out that .NET System.Net.Mail doesn't support implicit SSL, only explicit SSL. You'd think that Microsoft would have solved that by now. The reasoning: This is not considered a bug, it’s a feature request. There are two types of SSL authentication for SMTP, and we only support one (by design) – Explicit SSL http://www.systemnetmail.com/faq/5.3.aspx http://www.systemnetmail.com/faq/5.3.aspx
Animats 12y ago
This might be illegal under the anti-circumvention provisions of section 1201 of the the Digital Millennium Copyright Act. See: "http://copyright.gov/title17/92chap12.html" http://copyright.gov/title17/92chap12.html" "(1)(A) No person shall circumvent a technological measure that effectively controls access to a work protected under this title." That's one of the sections the RIAA and MPAA like, and it's written to favor the copyright holder. It seems to apply here. - Is your email copyrighted? Yes, under the "born copyrighted" provisions of the Copyright Term Extension Act. - Was it protected by a "technological measure"? Yes. - Was that technical measure circumvented? Yes. - Can you bring a suit yourself? Yes. - What are the damages? Minimum of $200 per circumvention. - Can they be aggregated? Yes.
- tedunangst 12y ago
  Did your ISP make an illegal copy of your email?
  - Dylan16807 12y ago
    The DMCA is so biased that it doesn't matter.
    - Animats 12y ago
      That's the beauty of it. It's hard to waive the anti-circumvention provisions of the DMCA. The law says "no person shall circumvent", not "no person shall circumvent without permission". I just sent a note on this to the EFF.
  - DanBC 12y ago
    They don't need to make a copy to fall foul of the anti-circumvention parts of the law. See also unlocking phones to any carrier where no copying was involved. https://www.eff.org/deeplinks/2009/04/dmca-hearings-phone- https://www.eff.org/deeplinks/2009/04/dmca-hearings-phone-
    - tedunangst 12y ago
giancarlostoro 12y ago
I'm surprised nobody is working on making PGP simpler to use. Living in fantasy land where we trust servers to never be compromised is always ridiculous to me. If you really want your privacy invest in tools that simplify PGP use, forget trusting a server, I thought we learned from events like heartbleed?
- LeoPanthera 12y ago
  > I'm surprised nobody is working on making PGP simpler to use. https://keybase.io https://keybase.io
  - TillE 12y ago
    Key exchange is a small part of the difficulty in using GPG. Go install Enigmail and count the myriad ways in which the UX could be vastly simpler and clearer, starting by just changing some stupid defaults.
  - annnnd 12y ago
    Thanks for the link! Looks interesting, though it is far from easy-to-use (for vast majority of users).
igonvalue 12y ago
Can someone explain exactly how this works, and how an end-user might figure out that this was happening in real time?
deleted 12y ago
[deleted]
mike-cardwell 12y ago
My mobile provider (T-Mobile in the UK), used to send spoofed RST packets back to you if you connected to something on port 465, disrupting the TCP connection. They also used to do that if you connected on port 587, but only if, and not until, you sent "STARTTLS" down the wire. I wrote about it here: https://grepular.com/Punching_through_The_Great_Firewall_of_TMobile https://grepular.com/Punching_through_The_Great_Firewall_of_... You could only send mail if you disabled encryption or used a VPN. They didn't discriminate, they even did this if you were connecting to GMails mail submission service.
rikkus 12y ago
To raise awareness of this and force the ISPs' hands, perhaps it would be best to use the media's own trope and cry about ISPs 'hacking email'. Whether or not that's the correct technical term isn't really an issue; it is valid under the current common use of the term.

333 points by erkose 12y ago

Before the conspiracy theories start, I think this has less to do with mass-surveillance and more to do with stopping spam. As hinted : "Some firewalls, including Cisco's PIX/ASA firewall do this in order to monitor for spam originating from within their network and prevent it from being sent." When faced with a large volume, companies usually aim for the quickest fix in lieu of the best. And I couldn't help notice the bigger problem here : "Adoption of PGP has been slow because of its highly technical interface and difficult key management." When non-technical people are involved, the number of technical people who dismiss or downlplay this offhand is getting annoying. In fact, just the other day, the replies to this : https://twitter.com/SwiftOnSecurity/status/530818824036040704 https://twitter.com/SwiftOnSecurity/status/53081882403604070... Surely, there's a simpler way to manage keys and send/receive encrypted email with PGP or something better?

leeoniya 12y ago
you don't need conspiracy theories to put forth that disabling encryption (for whatever reason) enables dragnet/any surveillance by whichever parties have access to the transmission medium. the NSA will be happy to collect your unencrypted data regardless of whether they had any part in disabling the encryption.
revelation 12y ago
No conspiracy theories here, just utterly baffled at the fact that a communications provider would happily tamper with user data that he has zero reason (and technical justification) to access or change. And then to strip STARTTLS? That's the nuclear meltdown scenario of incompetence and recklessness. I guess this is another moment where people can tell us how theres too much regulation governing internet providers, after apparently a vast majority of providers can't even deliver payload unchanged. It must be tedious to keep defending an industry that can't provide the most basic of services.
- rakoo 12y ago
  He just told you there _is_ a reason to do this: stop said ISP's users from sending spam. In the best case scenario, the ISP analyzes each email and drop them when their spamminess is too high. That's a legitimate concern for the ISP. Now _of course_ doing this will be a massive problem for privacy, but again, user's privacy comes after a functioning network for the ISP.
  - couchand 12y ago
    I'd argue that spammy e-mails are fine as long as you don't send too many of them. That's easy enough to track without breaking encryption. But it also makes it difficult to distinguish the officially "non-spam" yet still awfully spammy marketing automation that makes the ISPs boatloads of money, so I can see their tradeoff.
    - cm2187 12y ago
      I find these attacks outrageous and an absolute disdain for the protection of their customers but I wouldn't go as far as justifying spam. To be honest I am less shocked by the fact that the ISP do this than by the fact that it is even possible. Email is broken in so many levels.
  - revelation 12y ago
    It's not the job of the ISP to do that. Full stop.
josho 12y ago
This is the lamest approach to fighting spam. A better approach is for the ISP to block outgoing port 25 from their network, and force their users to use their mail relay that requires authorization. Any accounts that are caught spamming can then simply be terminated as customers. This approach is also quite common.
- bsder 12y ago
  This is the lamest approach to network security. Now I can't reach MY email server which sits in a colo on port 25. So, now I have to put my mail server on port 80 just so I can get out of the network. Some of us don't trust the email servers run by the ISP.
  - brongondwana 12y ago
    https://www.ietf.org/rfc/rfc2476.txt https://www.ietf.org/rfc/rfc2476.txt December 1998 It's hardly your ISP's fault that you are 16 years behind best practice.
    - nitrogen 12y ago
      https://www.ietf.org/rfc/rfc2476.txt https://www.ietf.org/rfc/rfc2476.txt December 1998 It's hardly your ISP's fault that you are 16 years behind best practice. Could you be so kind as to point to the relevant section of RFC2476?
      - tedunangst 12y ago
        > Port 587 is reserved for email message submission as specified in this document.
    - bsder 12y ago
      It is my ISP's fault for BLOCKING THOSE PORTS. And, since I don't really have a choice of ISP, I can't change that. Some of us live in the real world where we wind up having to do things like put mail servers on port 80 or 25 because that port doesn't get blocked. Thanks for playing.
higherpurpose 12y ago
Why would I want that if I have Gmail? Also I wouldn't trust Cisco's arguments in such situations. Cisco is the one that invented "lawful intercept"/backdoors in routers.
devicenull 12y ago
This is also the default behavior for ASAs, so it's really just not bothering to configure them. Probably because email works, so why screw with it?
drdaeman 12y ago
Sorry, but I honestly believe that "oh PGP is so hard for non techies, but those evil technical people ignore this important issue" is a myth. Unless we're talking about command-line gpg application, hah. Take Enigmail for example. It's nearly as non-technical as possible, with key IDs being the only "technical" thing that's visible in the key list. Key generation just asks you for account to use and expiry date. Encryption is a single checkbox. And the rest of the features are mostly behind "Advanced..." buttons and aren't necessary for the most basic operation. If you insist on the contrary, please do some concrete examples where it's a "highly technical interface". There are a lot of issues with PGP adoption, yet most important are two: 1) popular MUA developers just don't give a fuck about crypto 2) too many users use webmail where PGP support is generally a kludge at best 3) "noone does that anyway so why bother" attitude. The other issues are too minor compared to those three.
- toyg 12y ago
  Item 2 I think is the real killer. Nobody "normal" even uses MUAs anymore; GMail effectively killed that world. They use Outlook at work, where the configuration is up to their system administrator so they don't have to know anything, and then they go home and use GMail and again it's literally zero config. Back in the 90s, when people were actually setting up MUAs at home, they had to know about options etc; at that time, crypto was a bit difficult to implement and servers didn't really support it anyway, but still there was a slim chance that users would actually have to bother looking at "email preferences". That window is over. Now nobody knows anything about email and they are not expected to, so there is no chance they'll ever get to that finally-mature Enigmail screen.
  - drdaeman 12y ago
    <rant> 2 boils down to issue 1 and is blocked by issue 3. Web-based MUAs are still software. They could support PGP and/or S/MIME just fine. All what's necessary is to provide an API and browser plugin (so the website won't have _any_ access to plaintexts and keys) implementation. Like some sort of secure <textarea> that's completely out of website's control (except for basic visual styling and some hinting like what's to show as recipient selection) and only sends an event when writing's done and encrypted message is ready. Not trivial, but well possible. Given that Google is also a browser vendor and it's not unusual to them to push for features based on their product demands - certainly possible. But, nope. No big player on the market seem to care about providing user with proper cryptographic protection. The one with user in actual control instead of "oh, crypto's scary and we won't allow you to be scared - we'll manage everything for you, trust us, we'll handle your data good". Just look at the state of X.509 certificate management in any browser or email client - contrary to most PGP plugins, it's real obscure highly technical UI hidden beneath 4-6 mouse clicks, that hadn't any significant changes since '90s. So, we're still stuck with passwords instead of certificates. And S/MIME failed. And that's because most don't care any much (if at any) about the issue and even if they do they seem to be perfectly satisfied with "your communications are secure with bank-grade encryption blah blah blah"-type marketing speak. </rant>

delinka 12y ago

"...the flag indicating that a server supports STARTTLS is not itself encrypted..." I'm thinking signatures would have been a nice start.

deleted 12y ago
[deleted]
brongondwana 12y ago
Exactly. This fuzzy thinking in security is really frustrating me with the supposed security experts talking in this space. I was at Inbox Love a couple of weeks ago, listening to Ladar Levison talking about security, and he gave an example which conflated encryption with digital signatures, saying that the lack of encryption in his incoming email would allow people to send him executables which were unknown viruses. I actually raised my hand and said "surely digital signatures confirming the sender are really what's needed" and he replied that if it was encrypted, the MITM wouldn't know what was being sent to modify it. For real. As if the attacker can't just replace the whole email with something else encrypted to your public key and containing a virus. I lost a lot of respect for his security credentials in that moment, and I've lost a lot of respect for the EFF reading this posting. Not a _single_ mention of password theft, which is by far the highest risk to most users of having STARTTLS stripped. The ability for their email to be read over the backbone is bad, but the ability for hackers to get into their email and randomly delete or modify it is far more insidious. (plus the ability to use the email account to trigger password resets on third party services and all sorts of other exciting stuff you can do once you own somebody's email account)
- throwawayaway 12y ago
  You know what you are right. I've bookmarked your post. I think you should make a "Applications" style blog post and submit it.

feld 12y ago

Easy solution: don't permit STARTTLS. Only allow email clients to connect over 993 and 465 using end to end SSL. That's what Fastmail does and I now understand why.

spindritf 12y ago
You're thinking of end clients. This is server to server communication and Fastmail supports STARTTLS of course. $ dig mx fastmail.com +short 10 in1-smtp.messagingengine.com. 20 in2-smtp.messagingengine.com. $ telnet in2-smtp.messagingengine.com. 25 Trying 82.221.106.241... Connected to in2-smtp.messagingengine.com. Escape character is '^]'. 220 tlxc1.messagingengine.com ESMTP . No UCE permitted. ehlo my.hostname 250-tlxc1.messagingengine.com 250-PIPELINING 250-SIZE 73000000 250-STARTTLS 250-ENHANCEDSTATUSCODES 250 8BITMIME
- kijin 12y ago
  The article is about end clients on residential and/or business lines. There is no reason for client-to-server communication to rely on STARTTLS on port 25.
  - zurn 12y ago
    There's also no reason to discount server-to-server SMTP on residential or business lines. Especially since this is part of the larger net neutrality discussion.
    - feld 12y ago
      I worked at an ISP and no, net neutrality aside, SMTP on residential is bad bad bad. It should be permitted only at the customer's request, but probably won't fix the fact that their subnet is on a global spam blacklist.
      - zurn 12y ago
        The point of NN is that the ISP shouldn't get to make that decision. Even "allow on request" is very problematic because it's a slippery slope. Many people run SMTP at home mostly to receive mail, because the ISP is legally obligated to retain mail logs for law enforcement etc. (EU data retention law)

josho 12y ago

Why is mail so broken? We send so much confidential information over email, yet have no reliable way to secure the information. We insist on https, so why are we ok with the current lame security around mail? Folks go out and get S/MIME setup, it's not ideal, but a start at least.

atmosx 12y ago
I'm no expert but it's most likely that like FTP, SMTP was NOT designed for the internet. It was designed for LANs or MANs. Security was not one of the core features. Same goes with many old protocols... But that's expected the drama is when new protocols are designed with the same flaws.
- josho 12y ago
  Yup, I get that. Same can be said of http--so we solved that problem and created https. I just don't get why folks like IBM, Microsoft, et al never bothered to push secure email standards. I'm surprised their customers never pushed them to do it. SMTP with starttls is not secure because as an end user I have no idea if my mail is getting sent securely.
  - throwawayaway 12y ago
    You have to go back to the export controls thing in the nineties to understand that: http://www.ussrback.com/crypto/nsa/lotus.notes.nsa.backdoor.txt http://www.ussrback.com/crypto/nsa/lotus.notes.nsa.backdoor....
dredmorbius 12y ago
There were people thinking about security in the 1970s, but the proposals were quashed. A comment from this past August from Karl Auerbach, who was there: I worked on TCP/IP security systems back in the 1970's. In fact one of the threads that led to IP being peeled off from the then monolithic TCP was done on my blackboard at SDC in 1974. The reason we did that was to insert a security/encryption protocol over the packet layer - if it sounds like DNSSEC it should. But in 1974. But it was on a project done for "the government" so it never saw the public light of day. And: We made a huge mistake back in the 1970s when we failed to require a mandatory packet security layer between IP and the protocols over it. (We knew even then that we needed it - and had existence proofs of running code - but the gov't wouldn't let those who knew out into the wild to evangelize the concept. So in some sense the problem we have today is do to excessive closure by certain governmental authorities. Even today I am not at all sure what I can say about this stuff. (He's still under some security prohbitions). https://plus.google.com/106435630686948313794/posts/i4KmivYfXrN https://plus.google.com/106435630686948313794/posts/i4KmivYf...

Someone1234 12y ago

Unfortunately STARTTLS is broken beyond repair. STARTTLS is sent via the unprotected SMTP channel. The biggest problem with this isn't the lack of encryption, but more the lack of MitM protections. Imagine if when you wanted to connect to your bank over HTTPS you first had to send a HTTP request which asks permission to "upgrade" to HTTPS. Obviously any bad guy worth their salt is going to intercept that unprotected HTTP traffic, strip out the STARTTLS, and then leave you using the HTTP channel they can monitor or alter. So while, yes, in this case ISPs are likely "MitM"-ing their own traffic (which by definition isn't a MitM), it still leaves you open to bad guys on your side of the connection (e.g. the insecure WiFi problem). But even if ISPs weren't someone else could be.

spindritf 12y ago
Imagine if when you wanted to connect to your bank over HTTPS you first had to send a HTTP request which asks permission to "upgrade" to HTTPS. This actually happens a lot. Most people most of the time don't painstakingly type in h-t-t-p-s-:-/-/... but rather just the domain name and the server on the other end returns a (plaintext) redirect to https. Which is why sslstrip works so well. Sure, we have bookmarks, HSTS, tell people to look for a lock icon in the address bar but it's far from being a solved problem.
- iancarroll 12y ago
  HSTS preloads fixes this problem on modern browsers. Google literally has a site where you can add your site to Chrome's list (which Mozilla clones) in a few weeks. If you're using other browsers, the problem still exists but a large majority is covered by this.
  - dublinben 12y ago
    There's only 500 sites on that list. None of the largest banks in the US are even included. This problem is hardly solved.
    - iancarroll 12y ago

plg 12y ago

i can haz gnupg?

chuso 12y ago
AFAIK, GnuPG and S/MIME only encrypt message body, but not its headers such as sender, receipt, date, subject, ...
- plg 12y ago
  Yes that's true
  - riking 12y ago
    ... email account passwords ...

higherpurpose 12y ago

Ok, maybe I can live with the excuse that NSA is forcing the carriers' hands at giving them data, but actively helping NSA break people's encryption? What the hell.

eli 12y ago
NSA?
hadoukenio 12y ago
Yeah, this smells like it was by design.

willvarfar 12y ago

If, say, Thunderbird is configured to use STARTTLS to talk to the IMAP and SMTP servers, can this attack strip it or will Thunderbird refuse to connect to an unencrypted server?

asutherland 12y ago
In very old versions of Thunderbird (pre-mercurial), there was an option akin to "TLS, if available" which would be vulnerable. But Thunderbird has not offered it as an option for new accounts for quite some time.

iolsantr 12y ago

At least nobody thinks MITM attacks are only of concern to big corps, militaries and paranoiacs now.

cm2187 12y ago
And with mobile and wifi everywhere this is even likely to become a direct annoyance for consumers

kijin 12y ago

This is why I never use STARTTLS on port 25 or 587 when connecting to my mail server. For me, it's 465 or GTFO. I understand the need for backward compatibility in server-to-server mail transport, but there is absolutely no need for client-to-server mail submission to rely on a hack like STARTTLS. Whoever decided to deprecate STMPS on port 465 made a big mistake. That was back in 1998, when most people didn't fully grasp the dangers of unencrypted communication. I think SMTPS should be reinstated as a standard for mail submission, and mail services should stop encouraging their customers to move to STARTTLS. That way, you won't have to worry about your mail client's undocumented behavior when a STARTTLS negotiation fails.

mike-cardwell 12y ago
I'm not aware of any mail clients which (when configured to use encryption), will downgrade to not use encryption for any particular reason, when using mail submission port 587. If you are, tell us what they are so we can issue bug reports. If you can't, then what the hell are you talking about?
- kijin 12y ago
  > what the hell are you talking about? Old example: https://news.ycombinator.com/item?id=8593115 https://news.ycombinator.com/item?id=8593115 Current example: K-9 Mail has two options for TLS: "TLS (if available)" and "TLS (always)". If you choose the first option, K-9 will transparently downgrade to unencrypted connections. Even worse, some ISPs will happily instruct users to select the first option if they're having trouble with configuration. For most people, "better compatibility" sounds like a pretty convincing excuse. Which is probably why this stupid option exists in the first place.
  - mike-cardwell 12y ago
    People who configure their clients to use encryption optionally, will find that their clients, use encryption optionally. This is not evidence that 465 is more secure than 587. This is evidence that some clients come with strange options.

G3E9 12y ago

The lack of HTTPS when using Comcast's XFINITY web mail is still beyond me. HTTPS is used when logging in, however everything else after that prompt is over basic HTTP (session IDs, inbox data, message data, contacts list, etc). I do not communicate much with my provided Comcast email, but I know others who tie a lot of services to it. Until Comcast provides standard web security, they endanger their customers as well as whoever else involved (paying Comcast or not). Careful what you share with user@comcast.net.

dangrossman 12y ago

I haven't been able to send e-mails when connected to T-Mobile for, oh, a year at least? My e-mail provider (Rackspace) only supports STARTTLS and SSL/TLS, and T-Mobile appears to break the authentication no matter which I choose. I can receive e-mail, but not send it on 465 or 993. As soon as I get home and switch to wifi, everything in my outbox gets sent. It's mighty annoying.

rahimnathwani 12y ago
993 is for IMAP, not SMTP. Try 587.
- dangrossman 12y ago
  My mistake, just a typo. The app fills in the port itself depending on what authentication mode is chosen. It's 465/587.
junto 12y ago
I wasted a bit of time yesterday trying to get a .NET application to send email using SSL/TLS via Rackspace. It turns out that .NET System.Net.Mail doesn't support implicit SSL, only explicit SSL. You'd think that Microsoft would have solved that by now. The reasoning: This is not considered a bug, it’s a feature request. There are two types of SSL authentication for SMTP, and we only support one (by design) – Explicit SSL http://www.systemnetmail.com/faq/5.3.aspx http://www.systemnetmail.com/faq/5.3.aspx

Animats 12y ago

This might be illegal under the anti-circumvention provisions of section 1201 of the the Digital Millennium Copyright Act. See: "http://copyright.gov/title17/92chap12.html" http://copyright.gov/title17/92chap12.html" "(1)(A) No person shall circumvent a technological measure that effectively controls access to a work protected under this title." That's one of the sections the RIAA and MPAA like, and it's written to favor the copyright holder. It seems to apply here. - Is your email copyrighted? Yes, under the "born copyrighted" provisions of the Copyright Term Extension Act. - Was it protected by a "technological measure"? Yes. - Was that technical measure circumvented? Yes. - Can you bring a suit yourself? Yes. - What are the damages? Minimum of $200 per circumvention. - Can they be aggregated? Yes.

tedunangst 12y ago
Did your ISP make an illegal copy of your email?
- Dylan16807 12y ago
  The DMCA is so biased that it doesn't matter.
  - Animats 12y ago
    That's the beauty of it. It's hard to waive the anti-circumvention provisions of the DMCA. The law says "no person shall circumvent", not "no person shall circumvent without permission". I just sent a note on this to the EFF.
- DanBC 12y ago
  They don't need to make a copy to fall foul of the anti-circumvention parts of the law. See also unlocking phones to any carrier where no copying was involved. https://www.eff.org/deeplinks/2009/04/dmca-hearings-phone- https://www.eff.org/deeplinks/2009/04/dmca-hearings-phone-
  - tedunangst 12y ago

giancarlostoro 12y ago

I'm surprised nobody is working on making PGP simpler to use. Living in fantasy land where we trust servers to never be compromised is always ridiculous to me. If you really want your privacy invest in tools that simplify PGP use, forget trusting a server, I thought we learned from events like heartbleed?

LeoPanthera 12y ago
> I'm surprised nobody is working on making PGP simpler to use. https://keybase.io https://keybase.io
- TillE 12y ago
  Key exchange is a small part of the difficulty in using GPG. Go install Enigmail and count the myriad ways in which the UX could be vastly simpler and clearer, starting by just changing some stupid defaults.
- annnnd 12y ago
  Thanks for the link! Looks interesting, though it is far from easy-to-use (for vast majority of users).

igonvalue 12y ago

Can someone explain exactly how this works, and how an end-user might figure out that this was happening in real time?

deleted 12y ago

[deleted]

mike-cardwell 12y ago

My mobile provider (T-Mobile in the UK), used to send spoofed RST packets back to you if you connected to something on port 465, disrupting the TCP connection. They also used to do that if you connected on port 587, but only if, and not until, you sent "STARTTLS" down the wire. I wrote about it here: https://grepular.com/Punching_through_The_Great_Firewall_of_TMobile https://grepular.com/Punching_through_The_Great_Firewall_of_... You could only send mail if you disabled encryption or used a VPN. They didn't discriminate, they even did this if you were connecting to GMails mail submission service.

rikkus 12y ago

To raise awareness of this and force the ISPs' hands, perhaps it would be best to use the media's own trope and cry about ISPs 'hacking email'. Whether or not that's the correct technical term isn't really an issue; it is valid under the current common use of the term.